While editing a text SynCase updates the case of the text's words to the case of corresponding keywords in TSE's syntax hiliting definitions.

This is especially useful when editing TSE's own macro language, which is rich in cased words.

The current version of Syncase has 2 big weaknesses:

• The macro language's syntax hiliting definitions (file sal.syn) are overwritten by every TSE update.
• The extension still assumes that Semware properly maintains TSE's Help and that it can extract new keywords from it. In practice this has not been true since 2005.

My time limitations makes me want an as simple solution as possible.

Therefore the plan that I am looking into is:

• Simply delete the old functionality that checks for keywords in TSE's Help.
• After a TSE update:
  • TSE itself already made a backup of relevant .syn files in a new "bak…" directory.
  • Compare the old and new .syn file:
    Add the user's keyword definitions back.
    Delete keyword definitions that the user deleted.
    Note that completely new definitions are not deleted.
    To achieve all of the above a .syn file's unused "KeyWords10" section will be used to store user-deleted keywords and .syn-file related SynCase settings. A SynCase setting will be a keyword with the format "!SynCase!" + setting_name + "!" + setting_value. For now I foresee only one such setting. The "!" will sort the setting(s) to the top and clarify what the "KeyWords10" section is used by.
  • With SynCase.s I will distribute my own up-to-date sal.syn file, that is also to be stored in TSE's "mac" directory, which will trigger a similar merge with the user's sal.syn file in the "synhi" directory.
    This will initialize first-time SynCase use and allows users to get my updates.
  
  

UniConv

This is a possible future project.

The Unicode extension already lets us convert ASCII, ANSI, and Unicode to each other interactively, but sometimes I need a non-interactive version.

UniConv would non-interactively convert a file to a file or a buffer to a buffer.

A file would be treated as binary input.
For a buffer it would depend on TSE's binary status for the buffer.

Without a shred of evidence I have a tiny hope that a file-based conversion could be faster. That would be icing on the cake.

English

This is a possible future project.

I have come to find Sammy's TSE English syntax hiliting file a delight for catching spelling errors in .txt files.

I now would love to have a TSE extension with these additional features:

• A cleaned-up syntax hiliting file to start from.
  The current file is pleasantly complete, but also contains a lot of weird words.
• Better hiliting of numbers and punctuation marks.
• An easy way to add a not-yet-hilited word from a text to the syntax hiliting.
• A way to also apply English hiliting to comments in programming languages.
  Mixed syntax hiliting will be a hard problem, which might require a separate future project and extension.

DirList → Test → DirList → Unibrowse → Remote editing

One thing is leading to another, again.

Initially I just wanted to implement remote editing for the HTTP(S) and SSH protocols.

However, remote filenames can contain Unicode characters too, and TSE does not natively support them. So I researched if it would make sense to make the new functionality part of the existing UniBrowse extension, which for one handles local filenames that possibly contain Unicode characters. My conclusion is that it does. The Unibrowse extension also implements browsing directories and files that are extended with alternate data streams. In examining the UniBrowse extension I was confronted with my earlier design choice to implement listing and accessing "Unicode names" and alternate data streams with Dos commands instead of Windows APIs. Some googling to revisit that decision this time turned up Windows APIs that do not seem too hard. Using Windows APIs would speed up Unibrowse immensly and make it a lot more robust. Before committing to a big tool like UniBrowse, it makes sense to first try these new APIs in a limited tool like DirList. And before that an even more limited test macro to just test if using these APIs from TSE actually works.

So here I currently am, updating DirList, to maybe later write a test macro testing Windows file APIs, to maybe later rewrite DirList to use them, to maybe later rewrite UniBrowse to use them, and to maybe eventually extend UniBrowse with remote editing capabilities.

So basically I am contemplating rewriting another core part of the editor using its macro language, this time its file browsing. I am aware of the absurdity.

ViewFindsHi

This is a possible future project.

Syntax highlight the View Finds list.

A TSE extension should be able to do this. The biggest hurdle would be multi-line comments. Which is unfortunate, because hiliting comments and not-comments as such would also be the extension's greatest benefit!

Base64

This is a possible future project.

I needed and created a quick & dirty version of a tool that can convert a base64-encoded text to readable text.

It "works", but is currently so user-unfriendly, that I do not consider it publishable. To do.

UniDraw

This is a possible future project.

Linux TSE and Windows GUI TSE gave us the ANSI character set, which gained us language compatipilty between at least 14 languages, but lost us line drawing capability.

Unicode supports line drawing, and the Unicode and Uniview extensions give TSE Unicode compatibility, but there is no tool yet that uses the Unicode character set for line drawing.

UniDraw could be that tool.

UniClip

This is a possible future project.

Copying and pasting Unicode text from and to the Windows clipboard is already possible with the Unicode extension. However, this functionality needs its own extension, provisionally called UniWinClip or UniClip. The main reason is that the Unicode extension is currently too big for debugging.

A secondary goal would be to add the capability to paste the Windows clipboard as a column block. There are two known ways to do this. One is by giving the tool a parameter to do so. The other is by doing a column block paste from the Windows clipboard if the text contains a marked column block, because this is what Visual Studio and VSCode do. The second way might need to be optional.

A tertiary goal would be to reproduce TSE's capability to reliably copy column blocks between TSE sessions.

UniView v2

This is a possible future project.

Two major improvements might be possible:

• It might be possible to get rid of UniView's flickering line updates by using TSE's HookDisplay() command.
• It should mostly be possible to make UniView work for the current line too.
  However, this implies taking over the backspace, delete, tab and horizontal cursor keys to compensate for one displayed Unicode character being implemented by multiple underlying bytes.
  I am not going to implement the tab key at first, and maybe not at all. It will be really hard to implement given all its configuration options and macro implementations.

These two improvements would again bring TSE major steps closer to being a full Unicode editor.

I do not plan to solve these issues:

• Misaligned tab positions after a non-ANSI character.
• A column block that only partially contains a non-ANSI character.
• Sorting on non-ANSI characters.

UniCode Suite

This is a possible future project.

There already is a group of separately distributed extensions to make TSE more compatible with Unicode.

It would be nice to be able to distribute these as a coherent bundle.

(I have renamed the "Edit2" tool to "UniBrowse" in anticipation of this project.)

SmoothScroll

This is a possible future project.

In creating the Uniview extension I noticed how the parameters of the Windows TextOut API might be used to implement smooth scrolling in TSE.

Smooth scrolling will probably not integrate optimally with TSE, but one day I would like to try it anyway to see if this works in principle, just for the fun of it.

This tool will open the link under the cursor.

A link can be a web address or a fully qualified file name.

I have started to use it to great effect, but unfortunately it is not ready for publication and public use yet.

FastStrFind v2

This is a possible future project.

TSE's StrFind() and StrReplace() functions are actually built-in macros. They insert the "haystack" parameter into a temporary buffer and then use lFind() and lReplace(). The intermidiate use of a temporary buffer causes significant performance overhead.

Enter my FastStrFind() v1, which does not use a temporary buffer when the caller does not provide the "w" or "x" option.

I am pondering two next versions for FastStrFind:

• StrFind has the bug, that if a not-loaded file is current, then it loads it.
  It would be easy to immunize FastStrFind against that bug.
  I will first wait to see whether Semware fixes StrFind() and StrReplace() in the next TSE release.
• Implementing the "w" and "x" options.
  Honestly this would probably be a counterproductive goal, because a macro implementation will probably be way slower than TSE's built-in implementation.
  One excuse would be, that it would be an interesting programming challenge to implement regular expressions as a macro.