Re: Rationale for aligning data on even bytes in a Unix shell file?

On 5/8/2025 9:26 PM, Lawrence D'Oliveiro wrote:

On Thu, 8 May 2025 18:50:33 -0500, BGB wrote:
 

But, I don't bother with C1 control codes, as they are unused ...

 Mostly true. But I think terminal emulators do interpret CSI as equivalent
to ESC followed by “[”.
 

Possibly, though generally, ESC+[ is used IME.
Also creates uncertainty, as AFAIK the terminals traditionally operate on raw bytes regarding ANSI commands, whereas if the terminal interface is UTF-8, a CSI (as a 2-byte encoding) would not be equivalent to 0x9B (if encoded as a single byte).
...

In some contexts, may or may not also have ANSI escape sequences, though
generally no text editors deal with or make use of ANSI escapes.

 Editors (and other apps) running in “full-screen” mode within a terminal
emulator would use them to control the display.

Doesn't mean you couldn't use a subset for formatting control. As for how a terminal based text-editor would deal with them, I don't know.
I was thinking here more of a GUI based editor or pseudo-word processor; where Text + ANSI codes could, in theory, serve a similar role to the RTF format, although more as extended text rather than a sort of markup language (though, modern word processors typically use XML internally, as opposed to the more unusual markup scheme that RTF had used).
Sometimes, it would also be nice if there was a sort of a standalone graphical viewer/editor that used MediaWiki or Markdown or AsciiDoc or similar.
Well, looks like there is a standalone AsciiDoc editor at least...
Now, why is it a 300MB download (and bigger once installed)?... Modern coding practices I guess...
Unless it has a whole lot of graphics and sound or similar, this seems like around 1000x larger than it should be for what it sounds like it is.
One could almost pose it as a challenge:
Write AsciiDoc viewer and editor, but keep it as a single EXE that is under 1MB (well, and more preferably, under 300K, *).
*: Though, allowing for dynamically linked MSVCRT on Windows, as the default static-linked MSVCRT is has also gotten needlessly large at this point (well, and combined with MSVC's bloated code generation; but, allowing for 1MB does at least compensate for these issues...).
Well, or the challenge of old-times, people trying to keep everything in under 64K or so.
...