Ecma-48 proposed styling controls update updated & math expression representation proposal update

[Kent Karlsson]

Well, ”curses” was a solution for last century’s problems.
1)     Covers just very limited functionality, no parameters.
2)     Approximately the same functionality for all.
3)     But different manufacturers, or different models, had different controls to invoke each function. “Curses” did help in that context.
But with ECMA-48, the popularity of xterm (and derivatives), and the obsolescence of physical terminals by the use of terminal emulators, that solution is already obsolete. It is hard to see that it would have any future, since it is so limiting.

/Kent K

> 11 jan. 2024 kl. 11:35 skrev Giacomo Catenazzi <cate at cateee.net>:
> 
> On 9 Jan 2024 23:12, Kent Karlsson wrote:
> (...)
> 
> Let's skip a lot of *details*.
> 
>>> 
>>> But how do you input the formatting?
>> For output to a terminal emulator from a program, the source program would have string constants for control sequences or parts thereof, just like done now.
>> For a styling enhanced plain text editor one should be able to select a text portion, and then use a menu or keyboard shortcut to select a styling, as it is done in just about any modern text editor. There is no need for an end user to see the styling codes. Using something like HTML syntax would have terrible consequences in that it is hard to tell content from controls. For HTML for instance one MUST use < for <, so that it is not taken as start of a “tag”. That is absolutely nothing you want to see for a terminal, nor for a styling enhanced plain text editor.
> 
> I dislike this part, and I think it is the main problem.
> 
> Note: I'm actively fighting the use of "string constants" for CSI, in programs. Note: maybe we have a different interpretation.
> 
> For emulators I want that they uses libraries or at least they check terminal capabilities and they issues formatting codes (CSI, from ECMA-48 or common usage which are de-facto standards).
> 
> Every terminal emulator is different, and users want to use it also differently (so changing the settings). A programmer should not make a choice for me.
> 
> Do a program want to print on console? I'm ok that it may write some warnings in colours (but often they fails: they assume a background colour (and please: it is my choice!)), if I want to write to a log file, no CSI codes.
> 
> Hard coded formatting code are bad (and BTW html strongly discourage them, for reason: we learn from past).
> 
> And now I stop with the first rant.
> 
> 
> HTML (and LaTeX) can format text according the medium, and HTML is responsive. I find no good way to do it with ECMA-48 style. We can ask the size of the screen, or get a signal when it changes, but there is not real support on emulators: rendering is performed by programs (e.g. using dialog, or directly with curses library). Could you find a good way to display in a sensible way tables with different terminal widths (starting from 40 or less columns?). It is not code we want in most (or any) terminal emulator.
> 
> But also in an editor...I feel that programmers must transform it in html/css, do the rendering with existing libraries (which they are huge), and render it as text + CSI.
> 
> 
> What problem are you solving? Real case problem. The more I look the proposal, the more I think other tools are much easier and simpler.
> 
> Note: HTML with years solved many problems (also considering colour blind people, printing, etc.). Note: HTML as technology, not what we got from web (but so, possibly you should implement your proposal in that way: you just convert CSI to html (DOM), and lets' display it): so we have a real case to look. (and there are already libraries that do it, but without your extension proposal).
> 
> Your proposal is in any case doesn't maintain plain text: CSI sequences have punctuation, letters and numbers. So there is no much differences of text in elements and tags in HTML: a program/person which want the plain text, e.g. for copy/past, must do a lot of work removing formatting. In modern html is easy.
> 
> 
> I find it would have been  nice idea if we were in 1990s (and so an alternative of HTML), but now we have good designs, so do not let's to duplicate the huge work HTML did in past). For a practical point (if I need to implement it): just a filter to a DOM engine (which at the end would be a subset of existing HTML engines) and a rendering (which trend go in direction of HTML like formatting API for different graphical environment).
> 
> 
> And in any case, you should start at a higher layer: show programs, and if it is useful emulators and editors will adopt it. Or like tmux (so a sort of filter, and IIRC in past some *extensions*, e.g. the UTF-8 where done first as filter between user and terminal emulator.
> 
>    cate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240111/40646cbb/attachment-0001.htm>