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

On Fri, 9 May 2025 12:50:10 -0500, BGB wrote:

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.

Actually, several other C1 controls are also defined as equivalents to
sequences beginning with ESC.

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).

Yeah, I just checked KDE Konsole, and it doesn’t interpret 0x9B (CSI) as
equivalent to 0x1B followed by “[”.

I suppose I should check if changing the encoding makes any difference to
this ...

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).

There’s an old thing called “sixel graphics”, which DEC invented back in
the day. I found out KDE Konsole supports it! I think some other terminal
emulators do, too. There is a libsixel library that allows converting
image formats. You only get 256 colours maximum, but that is still
potentially quite useful.

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.

    pandoc -f markdown -t pdf «infile» | okular - &