v4.50.31

[S.E. Mitchell]

--------------------------------------------------------------------------------
06 Oct 2026 4.50.31
--------------------------------------------------------------------------------
For Windows:
https://semware.com/files/tse-pro-install/tse-setup-4.50.31.zip
For Linux:
https://semware.com/files/tse-pro-install/tse-linux-4.50.31.tgz
https://semware.com/files/tse-pro-install/tse-linux-4.50.31.zip

bindcmds.si:
fixed bug in SetWindowWidth(n)
It was returning:

return (Query(WindowRows) <> orig_cols)

but should return:

return (Query(WindowCols) <> orig_cols)

Thanks to Stein Oiestad for the fix.

bind.si
if (i in 1..5)
if i == 6
AddLine("", about_buf)
endif
Can never be 6!

Thanks to Stein Oiestad for the report.

In internal file manager processing,

This horrible code:

string proc remove_last_dir(string dir0)
integer p
string dir[_MAX_PATH_] = dir0

if isDirSeparator(dir[Length(dir)])
dir = DelStr(dir, Length(dir), 1)
endif

p = Length(dir)
while p > 0 and (not isDirSeparator(dir[p])) and dir[p] <> ':'
p = p - 1
endwhile

if p
dir = dir[1..p]
endif
return (dir)
end

proc previous_dir()
Set(PickFilePath,
AddTrailingSlash(
remove_last_dir(
SplitPath(Query(PickFilePath), _DRIVE_|_PATH_))) +
GetNameExt(Query(PickFilePath)))
EndProcess(-1)
end

Was replaced with this:

proc previous_dir()
string s[PATHLEN]

s = GetDrivePath(Query(PickFilePath))
s = RemoveTrailingSlash(s)
s = GetDrivePath(s)
Set(PickFilePath, s + GetNameExt(Query(PickFilePath)))

EndProcess(-1)
end

Clang found a couple of possible problems in buffer handling,
changed out a couple of memcpy's to memmove.

Changed sketchy code for EndFile() handling that did not work
correctly under Clang/GCC/MSVC.

Fixed speed search bug in gcc/clang versions - cause was
bitfields, as their storage representation is implementation
defined.

Tightened up function declarations, added const for passed
strings in several places.

Reworked ExpandPath (again). Thankfully sanity covers this
pretty heavily, and it still passes.

Reworked FindFirstFile() and FindNextFile() - work hard to _not_
return the so-called short name if at all possible.

Did the same GetOpenFilename().

You can now load:
\Windows\System32\drivers\etc\hosts
again. Thanks to Sean Sliwinski for the report.

Added History to the read() in compile.MergeDataFile read().
Thanks to Knud van Eeden for the suggestion.

Sum now catches overflow. thanks to Guy Rouillier for the
report.

--------------------------------------------------------------------------------

[Carlo Hogeveen]

I have 36 macros in my Macro AutoLoad List.
According to TSE's appendix with technical specifications
https://ecarlo.nl/tse/files/TseHelp.html#appendix_a%3a__technical_specifications
"A maximum of 60 external Compiled Macro files may be loaded at any one time."
As of TSE v4.50.31 only the first 30 of my autoloaded macros are loaded.
The rest are silently omitted.
☹
Carlo

[S.E. Mitchell]

Hmmm. Testing this. I put 46 macros in my tseload.dat. But it only
loaded 38 of them.
No idea what is going on. No changes were made in the files I think
are relevant.
I will investigate.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/semware/000501dd55a5%24b067f270%241137d750%24%40ecarlo.nl.

[S.E. Mitchell]

I found what was stopping mine: the unicode macro.
If I remove it, it loads ~80 macros without any issues.
If I leave the unicode macro in, it doesn't load anything after that :(
So, for me at least, something in .31 is causing problems with the
unicode macro.
Here is what I loaded:

+---- Execute Macro -[x]+
¦ WRAPTHISLINE
¦ WRAP-LONG-LINES ¦
¦ WININFO2 ¦
¦ WININFO ¦
¦ WHERE ¦
¦ VMATCH ¦
¦ VIEWFINDS ¦
¦ VIDEO ¦
¦ VID2 ¦
¦ VID ¦
¦ VERTICAL-HILITE ¦
¦ UNLOADBINARY ¦
¦ UNIQ-DEL ¦
¦ TSESHELL ¦
¦ TETRIS ¦
¦ TAGS ¦
¦ SYNHIUTL ¦
¦ STATUS ¦
¦ STATE ¦
¦ SSL ¦
¦ SQLPLUS ¦
¦ SQL-IN ¦
¦ SPELLCHK ¦
¦ SORTED-UNIQ ¦
¦ SORT-FILELIST ¦
¦ SORT-BY-LENGTH ¦
¦ SORT ¦
¦ SHOWKEY ¦
¦ SHOWCURR ¦
¦ SHELLHERE ¦
¦ SHELLEXE ¦
¦ SETDIRTOFILE ¦
¦ SANITY2 ¦
¦ SANITY1 ¦
¦ REVERSE-STRING ¦
¦ RENAMEBUFFER-AND-FILE ¦
¦ QUOTE-BLOCK ¦
¦ QUOTE-BLOCK-COMMA ¦
¦ QCP ¦
¦ PRIMES ¦
¦ POTPOURR ¦
¦ NLINES ¦
¦ MERGE-LOADED-FILES ¦
¦ MATRIX2 ¦
¦ MATRIX ¦
¦ MATCH ¦
¦ MAC-SANITY ¦
¦ LOWERFN ¦
¦ LOADED_FILES_INFO ¦
¦ LISTOPEN ¦
¦ LINUX_INI_SUPPORT ¦
¦ HILITE-FIND ¦
¦ GREP ¦
¦ FRED ¦
¦ FOO ¦
¦ FNCOMP ¦
¦ FIX-VMS-FILELIST ¦
¦ FIX-TSV ¦
¦ FIX-CSV ¦
¦ FINDDUP ¦
¦ FIND-NOT-IN ¦
¦ F ¦
¦ EXPR ¦
¦ EXPAND1 ¦
¦ EXECUTE ¦
¦ EXECB ¦
¦ ERROR ¦
¦ DEBUG ¦
¦ CV2ORG ¦
¦ CUAMARK ¦
¦ COMPILE ¦
¦ COLUMN-MODE ¦
¦ CMPFILES ¦
¦ CHKCHG ¦
¦ BUG ¦
¦ BUFFERS ¦
¦ BLOCKSTAT ¦
¦ BACKUP ¦
¦ AUTOSAVE ¦
¦ AUTO-FN ¦
¦ TSESTART
+-----------------------+

[Carlo Hogeveen]

Not quite.
If I move the Unicode macro up to 4th place, then I can only autoload 22 macros instead of 30.
If I remove the Unicode macro, which auto-purges at least one depending maco, then only 19 macros are autoloaded.
The Unicode macro is a behemoth.
It feels like a size problem to me.

Carlo

-----Original Message-----
From: sem...@googlegroups.com <sem...@googlegroups.com> On Behalf Of S.E. Mitchell
Sent: Tuesday, October 6, 2026 10:42 PM
To: sem...@googlegroups.com
Subject: Re: [TSE] v4.50.31 - Fewer macros autoloadable

I found what was stopping mine: the unicode macro.
If I remove it, it loads ~80 macros without any issues.
If I leave the unicode macro in, it doesn't load anything after that :(
So, for me at least, something in .31 is causing problems with the
unicode macro.
Here is what I loaded:

...

[S.E. Mitchell]

> The Unicode macro is a behemoth.

Yep, it is the 3rd largest macro I'm aware of.
Both iconfig and isocalendar are larger; isocalendar is 8000 bytes larger.
I'll add isocalendar to my tseload.dat, and see what that does.
(later)
No change - it loaded without problems.
I'm not sure what I could have changed that would cause this problem.
Would you mind zipping up your 36 macros and the "worst" version of
your tseload.dat—for example, the worst version meaning the fewest
macros loaded - so I can see if I can figure out what is going on?

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/semware/000201dd55d4%24fbf0e880%24f3d2b980%24%40ecarlo.nl.

[Carlo Hogeveen]

> Reworked FindFirstFile() and FindNextFile() - work hard to _not_
> return the so-called short name if at all possible.
> Did the same GetOpenFilename().

Much better!

However, when using TSE's File Open menu, the following real letters in a filename are replaced by other letters instead of replacing the name by its short name, making the file not editable:
"𝕒" -> "5R" instead of a short name.
"ɐ" -> "P" instead of a short name.
"ş" -> "_" instead of a short name.
This was tested in Windows GUI TSE with Windows code page 850.
I received an email from my bank yesterday, signed by someone with an "ş" in his name, so that example is not contrived.

Carlo

[S.E. Mitchell]

What are the ascii values of those chars?
Would it be possible for you to send me a zip of those files -
removing anything private of course - so I can try that here?

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/semware/000c01dd55da%2452fa9bd0%24f8efd370%24%40ecarlo.nl.

[Carlo Hogeveen]

From the Linux-specific read.me.linux file:

> Stopped using buffered stdio for screen output.
> Now everything is manually buffered, and written to stdout via
> the low level write().

This is interesting to me.
My "partially failed", if there is such a thing, attempts to make the mouse work in the Linux TSE among other things had a problem with Linux TSE's screen buffering.
Based on the above I might revisit those attempts one day.

Carlo

[Carlo Hogeveen]

> What are the ascii values of those chars?

None, they are not even ANSI characters.

> Would it be possible for you to send me a zip of those files so I can try that here?

Now at version v3:
https://ecarlo.nl/tse/DemosAndTests.html#TestableUnicodeFilenames

Carlo

[knud van eeden]

1. Is ASCII always 1 byte per character? Yes.

Yes, standard ASCII is always stored as 1 byte per character in computer memory. 

===

2. Is ANSI always 1 byte per character? No.

No, Microsoft Windows "ANSI" code pages use either 1 or 2 bytes per character depending on the specific language code page.

While Western European code pages (like Windows-1252) are strictly 1 byte per character, 

East Asian code pages (such as Shift-JIS for Japanese or GBK for Chinese) use multi-byte character sets (MBCS) where a single character can take 1 or 2 bytes.

=> Note: Contemplating about Zhong Zhao's Chinese character filenames issue ...

===

3. Is UTF-8 always 1 byte per character? No.

No, UTF-8 is not always 1 byte per character; it is a variable-length encoding that uses anywhere from 1 to 4 bytes per Unicode code point.

===

4. Is UNICODE always 1 byte per character? No.

Byte Length by Encoding Type

* UTF-8: Uses 1 to 4 bytes per character. Standard English letters and

         numbers use 1 byte (making it backward-compatible with ASCII),

         while accented letters, non-Latin scripts, and emojis use 2 to

         4 bytes.

* UTF-16: Uses 2 or 4 bytes per character. Most common characters take 2

          bytes, while rare or specialized characters use a 4-byte

          surrogate pair.

* UTF-32: Consistently uses 4 bytes (32 bits) for every single

          character.

===

Conclusion: 

===

A. From multi-byte filename to short 8.3 filename:

ALWAYS using the short filename 8.3 notation should be a general solution in my opinion at this moment, because then any

multibyte filename is always mapped to its SAME 8.3 notation (which TSE for sure can read).

===

B. From multi-byte filename to short 8.3 filename:

The other way around, that is saving an 8.3 filename back to its original multi-byte file name is also possible, because the operating system (e.g. Microsoft Windows) knows the exact mapping from 8.3 and its cousin multi-byte filename.

===

As stating an issue could be that that 8.3 filename does not exist, but there should be APIs available to check that I guess.

===

[asking 'Google AI mode']

> Is this reasoning correct?

===

Yes, your technical reasoning about character encodings (ASCII, ANSI, UTF-8, and Unicode) is 100% correct. Your conclusion regarding how Windows handles short 8.3 filenames is also functionally sound, but it contains a few critical caveats you should consider.

Here is a breakdown of why your encoding logic is solid, followed by a direct analysis of your 8.3 filename solution.

---

Encoding Checklist Evaluation

• ASCII (1 Byte): Correct. It only defines 128 characters, fitting perfectly into 7 bits (padded to 1 byte in memory).
• ANSI / MBCS (1 or 2 Bytes): Correct. Windows code pages like Windows-1252 are 1 byte, but double-byte character sets (DBCS) like Shift-JIS or GBK use 1 or 2 bytes.
• UTF-8 (1 to 4 Bytes): Correct. It dynamically scales based on the complexity of the character.
• Unicode (Variable): Correct. Unicode is the mapping standard, while UTF-8, UTF-16, and UTF-32 are the byte implementations.

---

Analysis of Your 8.3 Filename Solution

Your idea to use 8.3 short filenames (SFN) to bypass multi-byte compatibility issues (such as Chinese character paths causing errors in older programs or TSE) is a classic, battle-tested workaround. Windows internally tracks a mapping between the Long Filename (LFN) and its 8.3 short counterpart.

However, relying on this introduces a few specific risks in modern environments:

Direct Comparison: Pros vs. Cons of the 8.3 Solution

Advantages	Risks & Disadvantages
Guaranteed ASCII: The 8.3 filename contains only standard ASCII characters (letters, numbers, tildes ~), eliminating multi-byte parsing crashes.	8.3 Can Be Disabled: Modern Windows installations (especially on fast SSDs or Windows Server) often have 8.3 name generation disabled globally to improve performance.
OS-Level Mapping: The Windows file system (NTFS) natively maintains the link between the short and long names.	Name Collision: If you have files named ZhongZhaoReport1.txt and ZhongZhaoReport2.txt, their 8.3 names will conflict and become ZHONGZ~1.TXT and ZHONGZ~2.TXT. The mapping is not purely deterministic based on the text alone.
API Supported: Windows provides native APIs to convert back and forth cleanly.	No Short Name for Short Names: If a filename is already short and contains only valid characters, it doesn’t get a distinct "short name format"—it just is what it is.

---

Addressing Your Final Point: Checking Availability

You correctly anticipated that an 8.3 filename might not exist. Windows provides native APIs to handle this exact check and transformation:

• To get the 8.3 path: Use the Windows API GetShortPathName. If 8.3 generation is disabled on that drive, this function will simply fail or return the long path unchanged (which leaves the multi-byte characters intact and won't solve your issue).
• To get the original path back: Use the Windows API GetLongPathName. The OS will instantly map the 8.3 string back to the full multi-byte Chinese character path.

To ensure this solution works for your specific problem, let me know:

• Is this workaround for an older legacy application, a specific command-line tool, or a script?
• Do you have control over the Windows environment where this runs (to check if 8.3 filename generation is enabled)?

I can give you the exact command or code snippet to verify if your target system supports 8.3 names.

===

Applying the 8.3 short filename (SFN) workaround for The Semware Editor (TSE Pro) is a brilliant and highly effective solution.

Because TSE Pro is a classic, ultra-fast programmer's editor originally rooted in the 16-bit and 32-bit Windows eras, it expects standard single-byte ANSI/ASCII strings when interacting with the Windows API to load or save files. When Windows hands it a path containing multi-byte Chinese characters (such as Zhong Zhao's files), TSE's internal filename parsers break. [1, 2, 3]

Using the 8.3 naming convention strips away the multi-byte characters entirely and substitutes them with basic, safe ASCII text (like ZHONGZ~1.TXT), allowing TSE to cleanly open, edit, and save the file without crashing. [4]

To implement this safely and seamlessly for TSE, consider these final implementation tips:

1. Ensure 8.3 Generation is Globally Enabled

Because modern Windows installations often turn off 8.3 name generation by default to speed up SSD performance, you must verify that Windows is actually creating these short names for Zhong Zhao's files. [4]

• Open an Administrative Command Prompt and run:

  fsutil 8dot3name query C:
  

• If it returns that 8.3 name creation is disabled, you can force Windows to enable it for that drive using:

  fsutil 8dot3name set C: 0
  

  (Note: Enabline it will only apply to new files. For existing multi-byte files, you may need to briefly rename them or move them to a new folder to trigger Windows into generating their short 8.3 aliases). [5]

2. Verify with a Quick Test

Before writing an automation macro, you can manually verify if the 8.3 path works seamlessly with TSE. Open a command prompt, navigate to the folder with the Chinese filenames, and type:

dir /x

This will print the hidden 8.3 short names side-by-side with the long Chinese names. Try passing that exact short name to TSE via your command line (e.g., gset.exe ZHONGZ~1.TXT). It should open flawlessly. [6]

3. Automating it in TSE (The Macro Solution)

If you are launching files into TSE from an external script (like Python, a batch file, or a file manager), you can use the Windows API call GetShortPathName to instantly convert the multi-byte string into the 8.3 ASCII path before handing it to TSE.

When TSE saves the file, Windows natively intercepts the ZHONGZ~1.TXT name and writes the data straight back into the original multi-byte long filename without TSE ever needing to understand Unicode. [4]

Are you launching these files into TSE via an external script/batch file, or are you trying to write a TSE macro (.mac) using the internal SAL language to fix this from within the editor?

[1] https://jpsoft.com

[2] https://en.wikipedia.org

[3] https://github.com

[4] https://en.wikipedia.org

[5] https://helgeklein.com

[6] https://www.invicti.com

---

===

my 2 dollars.

with friendly greetings

Knud van Eeden

[Carlo Hogeveen]

Sammy:

>> What are the ascii values of those chars?

Me:

> None, they are not even ANSI characters.

Sorry, that was a lousy answer.
Let me teach you how to fish.

If you have a character in a text, then you can copy it to the search field of the website https://unicode-explorer.com/ to find out its Unicode code point and name, and how to type it.
For example, searching there for "ş" returns "latin small letter s with cedilla".

If you have (a part of) a character's Unicode name, then you can google more about its encodings, for example at the website "compart".
Google "website:compart s cedilla".

Beware:
Websites like compart tell you the character's UTF-16BE encoding, while Windows APIs use UTF-16LE character encoding.
Both refer to "UTF-16" without being specific. ☹
Just switch around the bytes for Windows' "UTF-16".
For example, compart tells you ş's UTF-16 encoding is 0x015F, while Windows uses 0x5F01.

And a fun one.
If you do not have the character in a computer document, but you do know what it looks like, then you can draw it at the website https://shapecatcher.com/ .
I just tried it again, and the search timed-out, but I have successfully used it in the past.

Of course, there is also the solution of installing the Unicode and Status extensions in TSE.
These let you copy Unicode characters to and from TSE, show you the name of the cursor's character in the margin, and lets you search for a character's code point and name (parts) in a shrink-as-you-type list.

Carlo

[zhong zhao]

I just test v4.50.31 on Win10, it can not list correctly and open those filename or path include chinese character.

[knud van eeden]

Workaround for now?: Type 'dir /x', note the short name and use that short name instead in TSE to load that file.

Yahoo Mail: Search, Organize, Conquer

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/96eadf2a-0f2f-4d3d-a6b0-f4170e8b5c28n%40googlegroups.com.

[zhong zhao]

Attached test.cpp for reference.

[zhong zhao]

Attached test.rar is d:\tmp\汉字.txt compressed.

[knud van eeden]

Open an Administrative Command Prompt and run:
fsutil 8dot3name query C:
If it returns that 8.3 name creation is disabled, you can force Windows to enable it for that drive using:
fsutil 8dot3name set C: 0
(Note: Enabline it will only apply to new files. For existing multi-byte files, you may need to briefly rename them or move them to a new folder to trigger Windows into generating their short 8.3 aliases). [5]

Yahoo Mail: Search, Organize, Conquer

To view this discussion visit https://groups.google.com/d/msgid/semware/0490a420-d9f5-4576-b339-e0c602dd195bn%40googlegroups.com.

[S.E. Mitchell]

Are you using TSE's old file open dialogs or the Windows file open dialog?

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/96eadf2a-0f2f-4d3d-a6b0-f4170e8b5c28n%40googlegroups.com.

[S.E. Mitchell]

Would it be possible for you to update the files in the .zip, such that each file has a different length?
Many of them do, but there are 5 "The letter ..." files are 72 bytes, and 3 "The letter ..." files are 73 bytes.

It would also be great if all the "The letter" files were grouped together, if that makes sense.

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/001e01dd55df%2424f46f90%246edd4eb0%24%40ecarlo.nl.

[Carlo Hogeveen]

> Would it be possible for you to update the files in the .zip, such that each file has a different length?
> Many of them do, but there are 5 "The letter ..." files are 72 bytes, and 3 "The letter ..." files are 73 bytes.
> It would also be great if all the "The letter" files were grouped together, if that makes sense.

You can use a "dir /x" to get a file's short and long name side by side.
I think that is sufficient for now?

I definitely think there should be a way to see a shortened file's long name from inside TSE.
Probably my next project.

Carlo