> On May 13, 2025, at 14:20, Aram Hăvărneanu <[email protected]> wrote: > > 5. Add enough ANSI terminal sequences support to win(1) such that > workarounds are no longer necessary for common CLI software (git(1), > grep(2), etc). ... > 13. Some sort of minimal markup support. Perhaps with colors. Not > arbitrary colors, just four or five predetermined colors that > Acme programs could make use of (for example I'd like to see colors > in my diffs). This should be done by a third party process writing > in acme(4), acme(1) should not implement native markdown support > or anything like that.
It seems to be a core design principle that /dev/text is _only_ text. This purism has been espoused in other contexts: for example the Arcan author is another who apparently doesn’t like that writing a terminal requires a complex state machine which is apt to have bugs: https://arcan-fe.com/2017/07/12/the-dawn-of-a-new-command-line-interface/ (and other such articles). There’s some quote I remember seeing somewhere about every Unix terminal (and even Linux itself, since the kernel started out as a terminal emulator) having an ASR-33 at its heart: such an anachronism, such an ad-hoc standard from the electromechanical days, surely we could do better if we started from scratch. But you know, where do you draw the line: even a space character has an effect on alignment of the next character, and we don’t call it evil. A line feed moves the cursor too! What about a tab? What about a vertical tab then? What is FF good for nowadays? If we don’t like using most of the control codes, why are we wasting so much space at the beginning of the ASCII table with them? But at least a control code is only one byte... Could we use them better for just a few more cases, without having to write a state machine for multi-byte escape sequences? But if we start using a few for styling or defining text spans, maybe pretty soon it’s not enough codes anymore. A core idea that comes out of the Xanadu project is that assuming you can reliably make references to spans of text, in spite of text getting edited over time (changes that you want to track actually), then you can use those links for everything: for two-way hyperlinks stored separately, for transclusions, and perhaps even for tagging text spans with styles. The set of links is then a bit like a fully-normalized database schema: assume that some records already exist, and make a new table just to link the keys in one table to the keys of another. But being able to make unchanging references to changing text is a tall order. So I would like to apply this principle to that: /dev/text should stay as it is, and we need a way to apply styling to spans of text within the window. So we need a way to define the start and the end of the span, in spite of any editing that occurs. (There would be some edge cases, just as in any word processor: if you put the cursor at the beginning or end of a styled span and start typing, does it get the span's styling applied or not? You can argue about which way is more correct; but this does not stop anyone from writing word processors that deal with it one way or another.) If you insert a newline somewhere in the window, maybe all the spans referring to lines below that will need updating, or can we be more clever than that somehow? I’ve been prototyping an application that works that way: I have a device that serves up a 9p filesystem that contains (among other things) a plain text file and a separate spans file, and I modified tail to use draw to render colored text spans rather than just outputting the text itself. (And then developed a more complex client program that renders some application-specific widgets around the colored text.) I think what I’m doing should work, but it’s buggy in practice: tail normally has to read character-by-character backwards from the end of the file to find the line breaks, and now my version has to further assume that the last span at the end of the spans file applies to that last line that was found (thus defining the line number for that line even though we have not counted all the lines in the whole file), and stay in sync (iterating backwards and then forwards again) from there on, even as both files change. (My device actually stores the text in something like a ring buffer, but I’m trying to preserve the illusion that the text and spans both keep growing indefinitely, forward from where it was at the time that a particular client opens both files.) So maybe that difficulty illustrates why people like to mix formatting into their text in such a myriad of ways (terminal codes, HTML, markdown or whatever): either way you are doing multiplexing, but the more explicitly the spans are mapped to the text, the more robust it will be. FWIW I will be at iwp9 and can probably do a demo if it still works well enough at that time. What I would like to do next is modify rio’s window to have a /dev/text.meta/spans file alongside /dev/text, and be able to write to the spans file in case some non-default formatting is desired. Probably each span will just specify a numeric semantic, and then I’ll have a lookup table in another file to map those numbers to specific fonts and colors (so styling is modifiable dynamically). And each time you go back and modify history, your edits will have a different semantic automatically (and thus appear in a different color). So that’s for color and font support. But one experiment I was also thinking of trying with what we have already: if all you want is full control of one screen-full of text, can you open /dev/text, get the file offset at that time, write your first screen-full, and then each time you update you can just seek back to that offset and overwrite it with the next screen-full, or even make incremental modifications? I didn’t try it yet… but maybe monochrome curses-like UIs are possible that way? Maybe I should try to write a top that way, unless somebody already did it. I wondered if acme supports graphics (using draw) like the underlying window does: no, it does not, but I suspect that was something that could have eventually happened. I also wondered how easy it is to make splitters with sub-windows of text (each with a tagline field at the top) like acme does, in my own program. It seems that’s quite a bit of work too: it’s not all library code. Probably we could make it easier. I wanted sub-windows in this toy application that I’m writing though, so I cheated and used Nuklear for now. > 8. Add support for space-based indentation. Disgusting, but necessary > (I patched my acme to support this, but it still requires manual > activation, should be automatic). What kind of changes? > 14. Elastic tab support, or some better way of dealing with tabular > data. Yes! But I think that code belongs in the window, not acme. I want to be able to pipe tab-separated tables to the terminal anytime and have them lined up. Typewriters made better use of the tab key than most terminals do (except you had to set up the tab stops in advance: you shouldn’t have to do that on a computer). It should become so commonplace that even ls -l can use tabs to line up columns, and if you cat a source file, of course you get indentation looking the same as it does in an editor (if it doesn’t already). And I think adding this feature is probably easy compared to the text-spans stuff I was describing above. > 16. No settings, no options, no themes, no syntax highlighting, no > keyboard based interface (the mouse is king). I wouldn’t break the mouse usage, but actually I want to use the keyboard more. Sorry. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-Md3c9d0fe2113241d51ac4ddb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
