6 ms·

> These days I try to do all my programming atop a simple canvas I can draw pixels on. Why?

by volemo 1y ago

akkartik 1y ago
Terminals are full of hacks. For example, in my terminal project linked above the Readme says this: "Backspace is known to not work in some configurations. As a workaround, typing ctrl-h tends to work in those situations." (https://git.sr.ht/~akkartik/teliva#known-issues https://git.sr.ht/~akkartik/teliva#known-issues) This is a problem with every TUI out there built using ncurses. "What escape code does your terminal emit for backspace?" is a completely artificial problem at this point. There are good reasons to deal with the terminal: I need programs built for it, or I need to interface with programs built for it. Programs that deal with 1D streams of bytes for stdin and stdout are simpler in text mode. But for anything else, I try to avoid it.
- ayrtondesozzla 1y ago
  Sorry for jumping off topic but I came across mu recently - looks very interesting! Hope to try it out properly when I get a moment
  - akkartik 1y ago
    Thank you! Hit me up any time.
alpaca128 1y ago
Not GP but the terminal is inefficient and limiting for input and UI. For one you cannot detect key-up and key-down events, only a full key press. The press of multiple (non-modifier) keys at once can't be recognized either. Also there are some quirks, like in many terminals your application cannot distinguish between the Tab key and Ctrl-I as they look the same. But in some (e.g. Alacritty) it can work, so now if you have two different keybindings for Tab & Ctrl-I your program will behave differently in different terminals. If you want to do anything that's not printing unformatted text right where the cursor is, you need to print out control sequences that tell the terminal where to move the cursor or format the upcoming text. So you build weird strings, print them out and then the terminal has to parse the string to know what to do. As you can imagine this is kind of slow. If you accidentally print a line that's too long it might break and shift the rest of the UI. That's not too bad because it's a monospaced font, so you only have to count the unicode symbols (not bytes)...until you realize chinese symbols are rendered twice as wide. Text is weird and in the terminal there is nothing but text. But to be fair it's still a lot simpler than proportional fonts and a lot of fun, but I definitely understand why someone would decide to just throw pixels on a canvas and not deal with the historical quirks.
- miki123211 1y ago
  And to make matters worse, unlike a GUI, the terminal doesn't provide any semantic information about the content it displays to the OS. This is a problem for accessibility software, screen readers, UI automation, voice control etc. If you want a screen reader to announce that a menu option is selected, you need some way to signal to the OS that there's a menu open, that some text is a menu option, and that the option has the "selected" state. All serious GUI frameworks let you do this (and mostly do it automatically for native controls), so does the web. TUIs do not (and currently can not) do this. While this is not really a problem for shells or simple Unix utilities, as they just output text which you can read with a screen reader just fine, it gets really annoying with complicated, terminal-based UIs. The modern AI coding agents are very prominent examples of how not to do this right.
  - vidarh 1y ago
    TUI's could be made do this relatively easily. "All" you need is to pick an escape sequence to assign a semantic label to the following span of text, and have the terminal use whatever OS mechanism to make that available to assistive tech. Of course, that doesn't help unless/until at least one prominent terminal actually does it and a few major terminal applications adds support for it.
- vidarh 1y ago
  I think there's lots of scope for improvements to terminals, but I feel like this is more a question of "nobody has asked for it". There's been plenty of recent innovation in terminals (e.g. support for a variety of new types of underlines to enable "squigglies" for error reporting is an example; new image support is another), and adding a code to enable more detailed key reporting the same way we have upgraded mouse event reporting over the years wouldn't be hard, and these things tends to spread quickly. With respect to "accidentally printing a line that's too long", you can turn off auto-wrap in any terminal that supports DECAWM (\033[?7h / \033[?7l ). That it's "kinda slow" really shouldn't be an issue - it was fast enough for hardware a magnitude slower than today. Parsing it requires a fairly simple state machine. If can't keep up with VT100/ANSI escape sequences, your parser is doing something very wrong. The difficulty of unicode is fair enough, and sadly largely unavoidable, but that part is even worse in a GUI; the solution there is to use code to measure the rendered string, and it's not much harder to get that right for terminals either. It'd be nice if unicode had done this in a nicer way (e.g. indicated it in the encoding). For my own terminal, I'm toying with the idea of allowing proportional text with an escape code, and make use of it in my editor. If I do, it'll be strictly limited: Indicate a start and end column where the text is proportional, and leave it to the application to specify a font and figure out the width itself. Worst case scenario would be that you send the escape, and the editor doesn't get an escape acknowledging it has been enabled back, and falls back on monospaced text and keeps working fine in a regular terminal. This way, evolving terminal capabilities can be done fairly easily with backwards compatibility.

> These days I try to do all my programming atop a simple canvas I can draw pixels on. Why?

by volemo 1y ago

> These days I try to do all my programming atop a simple canvas I can draw pixels on. Why?

Terminals are full of hacks. For example, in my terminal project linked above the Readme says this: "Backspace is known to not work in some configurations. As a workaround, typing ctrl-h tends to work in those situations." (https://git.sr.ht/~akkartik/teliva#known-issues https://git.sr.ht/~akkartik/teliva#known-issues) This is a problem with every TUI out there built using ncurses. "What escape code does your terminal emit for backspace?" is a completely artificial problem at this point. There are good reasons to deal with the terminal: I need programs built for it, or I need to interface with programs built for it. Programs that deal with 1D streams of bytes for stdin and stdout are simpler in text mode. But for anything else, I try to avoid it.

ayrtondesozzla 1y ago
Sorry for jumping off topic but I came across mu recently - looks very interesting! Hope to try it out properly when I get a moment
- akkartik 1y ago
  Thank you! Hit me up any time.

alpaca128 1y ago

Not GP but the terminal is inefficient and limiting for input and UI. For one you cannot detect key-up and key-down events, only a full key press. The press of multiple (non-modifier) keys at once can't be recognized either. Also there are some quirks, like in many terminals your application cannot distinguish between the Tab key and Ctrl-I as they look the same. But in some (e.g. Alacritty) it can work, so now if you have two different keybindings for Tab & Ctrl-I your program will behave differently in different terminals. If you want to do anything that's not printing unformatted text right where the cursor is, you need to print out control sequences that tell the terminal where to move the cursor or format the upcoming text. So you build weird strings, print them out and then the terminal has to parse the string to know what to do. As you can imagine this is kind of slow. If you accidentally print a line that's too long it might break and shift the rest of the UI. That's not too bad because it's a monospaced font, so you only have to count the unicode symbols (not bytes)...until you realize chinese symbols are rendered twice as wide. Text is weird and in the terminal there is nothing but text. But to be fair it's still a lot simpler than proportional fonts and a lot of fun, but I definitely understand why someone would decide to just throw pixels on a canvas and not deal with the historical quirks.

miki123211 1y ago
And to make matters worse, unlike a GUI, the terminal doesn't provide any semantic information about the content it displays to the OS. This is a problem for accessibility software, screen readers, UI automation, voice control etc. If you want a screen reader to announce that a menu option is selected, you need some way to signal to the OS that there's a menu open, that some text is a menu option, and that the option has the "selected" state. All serious GUI frameworks let you do this (and mostly do it automatically for native controls), so does the web. TUIs do not (and currently can not) do this. While this is not really a problem for shells or simple Unix utilities, as they just output text which you can read with a screen reader just fine, it gets really annoying with complicated, terminal-based UIs. The modern AI coding agents are very prominent examples of how not to do this right.
- vidarh 1y ago
  TUI's could be made do this relatively easily. "All" you need is to pick an escape sequence to assign a semantic label to the following span of text, and have the terminal use whatever OS mechanism to make that available to assistive tech. Of course, that doesn't help unless/until at least one prominent terminal actually does it and a few major terminal applications adds support for it.
vidarh 1y ago
I think there's lots of scope for improvements to terminals, but I feel like this is more a question of "nobody has asked for it". There's been plenty of recent innovation in terminals (e.g. support for a variety of new types of underlines to enable "squigglies" for error reporting is an example; new image support is another), and adding a code to enable more detailed key reporting the same way we have upgraded mouse event reporting over the years wouldn't be hard, and these things tends to spread quickly. With respect to "accidentally printing a line that's too long", you can turn off auto-wrap in any terminal that supports DECAWM (\033[?7h / \033[?7l ). That it's "kinda slow" really shouldn't be an issue - it was fast enough for hardware a magnitude slower than today. Parsing it requires a fairly simple state machine. If can't keep up with VT100/ANSI escape sequences, your parser is doing something very wrong. The difficulty of unicode is fair enough, and sadly largely unavoidable, but that part is even worse in a GUI; the solution there is to use code to measure the rendered string, and it's not much harder to get that right for terminals either. It'd be nice if unicode had done this in a nicer way (e.g. indicated it in the encoding). For my own terminal, I'm toying with the idea of allowing proportional text with an escape code, and make use of it in my editor. If I do, it'll be strictly limited: Indicate a start and end column where the text is proportional, and leave it to the application to specify a font and figure out the width itself. Worst case scenario would be that you send the escape, and the editor doesn't get an escape acknowledging it has been enabled back, and falls back on monospaced text and keeps working fine in a regular terminal. This way, evolving terminal capabilities can be done fairly easily with backwards compatibility.