In Development
Requires a not too old and not too simple Linux terminal.
Tested with WSL v2, Putty, and on a Ubuntu Desktop.
This extension supports mouse clicking and scrolling in Linux TSE.
BUT:
-
It only works in sufficiently advanced Linux terminals.
You will simply have to test for yourself whether it works in your Linux terminal(s).
If it does not work, using the mouse typically invokes TSE's Help, or ignores a few keystrokes, or inserts some random characters into the text. -
Even if it works, it has some minor flaws.
A known one is, that after scrolling it scrolls an extra line at the next key stroke. - It does not distinguish other mouse buttons than wheel and not-wheel yet.
-
It disables TSE's <F1> key. 😟
You yourself will have to define an alternate key for TSE's Help or use the menu. - For mouse scrolling you need to explicitly define <WheelDown> and <WheelUp> keys in you .ui file or a loaded macro.
- It disables the terminal's right-mouse-click capability to paste the Windows clipboard into a Linux terminal. 😢
v0.3
Works in almost all menus,
provided that the Linux TSE version is at least v4.50rc24.
Fixes random characters leaking into text.
v0.4
For mouse scrolling it now requires you to explicitly
define <WheelDown> and <WheelUp> keys
in your .ui file or a loaded macro.
The benefit is, that mouse scrolling now works in combination
with other macros that query these keys.
This considered extension will replace, change and extend TSE's WordWrap functionality.
Summary of main differences with TSE's wordwrapping:
- A paragraph can also be indicated by an indented first line, a bullet point, an enumerator, a multi-line comment, a block of consecutive single-line comments, and HTML tags.
- Wordwrap scope and state is maintaned per buffer.
- Default wordwrapping is OFF.
- When turned ON it keeps wrapping the current paragraph, and turns OFF again when the cursor leaves it.
- A broader scope can be specified by the user, but then other paragraphs in the same buffer only start being wordwrapped when the user changes them.
- Right margin "0" means "the window width".
The following more detaild points are considered:
- The type of wordwrapping will depend on whether the type of the current buffer is a "text buffer" or a "program/data buffer".
- Here a "text buffer" means a buffer with an extension for which no comment-syntaxhiliting is defined, and all other buffers are of type "program/data buffer".
-
For a "program/data buffer":
- Wordwrapping is default off.
-
The user can toggle wordwrapping between these two values:
- Off: No wordwrapping is done.
- On: If the cursor is in a wordwrappable block, then the block is wordwrapped and keeps being wordwrapped until the cursor leaves the block.
- A wordwrappable block is a multi-line comment, a block of consecutive single-line comments, or text between HTML tags.
- Instead of "On" the extension could show the type of wordwrappable block it recognizes.
-
For a "text buffer":
- Wordwrapping is default off, unless persistence "File" applies.
-
The user can cycle wordwrapping through these persistences:
- None: No wordwrapping is done.
- Paragraph: The current paragraph is wordwrapped and keeps being wordwrapped until the cursor leaves the paragraph.
- Buffer: As "Paragraph" plus the same for other paragraphs in this buffer. For switched-to paragraphs wordwrapping starts when the user makes a change.
- File: As "Buffer" plus for this file it persists across TSE sessions.
-
Wordwrapping will honor TSE's left and right margin
settings.
When the right margin is 0, wordwrapping will use the width of the editing window.
-
A paragraph is a piece of text in a "text buffer" delimited by:
- An empty line.
- An indented line at the start of the paragraph.
- The start of a bullet point.
- The end of a bullet point.
- Bullet points can have levels: A bullet point can contain bullet points.
-
Wordwrapping "text between HTML tags" will only be done for
text between tags that contains no other tags,
other than a few excepted tags.
Such excepted tags: <strong>, <em>, <br>.
<br> will act as a wordwrap delimiter.
Text between <pre> tags will not be wordwrapped. - The extension will show TSE's "W" indicator in the status bar when a block or paragraph is actively being wordwrapped.
-
Probably: Recognize other tag extensions than ".html" and ".htm".
It is not uncommon to encounter .xml files where the whole file is in 1 line. While the xml structure would need to be reformatted by another program, it might become this program's task to wrap the lines inside tags. - Maybe: If the "Status" extension is installed, then it could (optionally) be made to show which type of wordwrapping is active.
- Maybe: Change the background color for an actively being wordwrapped paragraph or block.
Notes:
-
Semware and I mainly use a "-" as a bullet point.
Other seen bullet points are "*", "+" and "ú".
The "ú" is shown as a bullet ("∙") in some OEM character sets. TSE's Help is shown using the system's OEM character set.
In Windows GUI TSE's ANSI character set, characters 149 ("•") and 176 ("°") could be bullet characters too. - I use bullet points inside comments, so it makes sense to me that there they should be wordwrapped too.
- The text of the "Expr" macro has two different occurrences of when to ignore "bullet points".
-
Examples of how to wordwrap bullet points.
Not like this:
Groceries: - The red laundry detergent
but like this:
Groceries:
- The red laundry detergent
And not like this:
Groceries:
- The red laundry
detergent
but like this:
Groceries:
- The red laundry
detergent
(Are my clothes real? Do I want to find out and take the red laundry detergent, or belay my suspicions and take the blue one?) -
I would like to recognize and support enumerators.
For example "1", "1.1", "a.", "a}", "(1)", etc.
But probably not ones that use roman numerals.
Note that enumerators either have their own line or prefix the first line of a paragraph.
Enumerators impact wordwrapping in 2 ways:
An enumerator is a paragraph delimiter.
If an enumerator prefixes the first line of a paragraph, then it counts as whitespace regarding its paragraph's indentation. -
Importing and exporting wrapped text.
Text is wrapped per paragraph.
Paragraph recognition differs between TSE and Word, for example.
In TSE a paragraph is recognized by a blank line or by an indented or outdented first line. This is an existing setting.
In Word a paragraph is recognized by "the enter key".
If you copy a text from Word to TSE, then each Word paragraph becomes a single line.
This implies, that also functions are required to wrap/unwrap a buffer or block of text that was/will be imported/exported from/to some other applications.
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.
SynCase updates the case of a text's words to the case of keywords in TSE's syntax hiliting definitions.
SynCase v8's additional goals:
- Make TSE updates not overwrite SynCase's syntax hiliting and casing.
- Make TSE's syntax hiliting and casing more easily maintainable thru text files.
- Optionally make those text files automatically updatable from "<language>.syncase_defaults" files downloaded from my website.
- Remove the capability to set non-keywords to upper or lower case.
Mock-up of new SynCase menu:
+------------------------------------------------------------+
|Actions |
| Help |
| Case the whole current buffer |
|------------------------------------------------------------|
|Settings |
| Language [ SAL]|
| Should its .syncase file |
| Duplicate TSE's syntax hiliting definitions [Yes]|
| Case the language's keywords [Yes]|
| Should its .syncase_defaults file |
| Add new keywords to the .syncase file [Yes]|
| Update existing keywords in the .syncase file [Yes]|
| Renove obsolete keywords from the .syncase file [Yes]|
| Itself be updated [ Automatically]|
| Show its settings log file ... |
+------------------------------------------------------------+
Linux TSE v4.50 rc 18 upwards (not expandable).
"DirList41" is the development version of the future "DirList" v4.1.
New so far:
-
In Windows DirList is now default independent of its environment's language settings.
This is achieved by retrieving link targets with Windows functions instead of dir commands.
This is a major step forward, even if it did create new loose ends.
Example loose ends:
- Link targets starting with weird prefixes.
- The Windows functions and the dir command each do not retrieve some of the other's details. The now default Windows functions do not retrieve some details of the link type. So I will still have to apply the dir command too for those languages for which the dir output can be interpreted. -
Gained a small but significant speed optimization by optimizing BigInt.
The access status column is now an access error column. Therefore when there is no error, "ok" is replaced by "-". When sorting this sorts all access errors together.
The "no link" indicator was changed from "." to "-". It subjectively looks better, and "-" is in my TSE WordSet, which helps accessing the column.
DirList's speed was increased again by only retrieving link targets for the link types that have them: junctions and symbolic links.
The --alllinktargets parameter generates the old list.
The --folowlinks parameter makes DirList list the child objects of directory links again. This is not recommended. -
Links are no longer followed.
This greatly reduces the run time and list size, and linked subdirectories are no longer counted multiple times in a common parent's directory size.
The following of links will later become a non-default option. - The link type column was condensed to be smaller.
- The column for TSE accessility is now a string indicating a reason.
- A link indicator (Linux) or type (Windows) column was added. Windows has a lot of link types.
- Windows: For junctions and symbolic links the link type and the link's target is now shown. It is shown between square brackets after the name, like "dir /al" does.
Still todo for DirList v4.1:
- Lots of (hopefully small) loose ends.
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 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.
eHelp
Because TSE's Help has not been properly maintained since TSE 4.4 was released in 2005, I want to be able to add my own notes to TSE's Help or even edit a copy of it, to enable others to do the same, and to provide a way to easily exchange them.
!!! Extending TSE's Help with eHelp is still in development !!!
I strongly advise against installing eHelp. It works badly, and is not going to be improved upon any time soon.
- (15 Oct 2023) eHelp is now a low-priority project.
- (15 Oct 2023) Blog about implementing TSE's extended Help.
-
(23 Mar 2023, v0.22)
eHelp.zip
Installation and update:-
Extract the eHelp.zip file to TSE's root directory,
including extracting subdirectories to subdirectories.
If your extract-tool did so, it will immediately place eHelp.zip's 6 files in their correct 3 subdirectories.
Otherwise read the installation instructions in eHelp.s on how to do this yourself. - Open "mac\eHelp.s", and compile and execute it.
- <Escape> the configuration menu.
- Done!
- To check: Go to TSE's Help, look up AbandonEditor(), and for example use <Alt N> and <Alt P> to switch between .ehelp files.
- A tsehelp.ehelp copy of TSE's built-in Help is generated and kept up-to-date automatically.
-
The top left corner of a Help screen shows
- no name if TSE's built-in Help is shown,
- "tsehelp" if the eHelp copy of TSE's built-in help is shown,
- otherwise the name of the .ehelp file that is shown.
- If a topic occurs in multiple .ehelp files, then you can switch between .ehelp files with these keys: <Alt GreyCursorLeft>, <Alt GreyCursorRight>, <Alt CursorLeft>, <Alt CursorRight>, <Alt P>, <Alt N>.
- Currently tsehelp_eCarlo.ehelp makes this possible for about 159 topics.
- You can create and edit your own tsehelp_<name>.ehelp text files, and configure eHelp to use them.
- During editing .ehelp files will be syntax hilited, and their line-drawing, shadow, and block characters will be shown.
- Saving a .ehelp file syntax checks it, still roughly.
Read the blog for status and plans.
-
Extract the eHelp.zip file to TSE's root directory,
including extracting subdirectories to subdirectories.
- (3 Sep 2022) Preliminary brainstorm about extending TSE's Help.
I welcome suggestions and criticisms!
