💾 Archived View for bbs.geminispace.org › s › Geminispace › 17477 captured on 2024-06-16 at 15:14:35. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
gemini://ecs.d2evs.net/posts/2024-05-27-terminals-bad.gmi
In the above link you will find what I believe to be a completely counterproductive and silly approach to thinking about terminals and ASCII.
1. List a set of problems in an unserious way.
2. Propose a vague solution (paraphrase: "something other than a terminal").
This approach to text will lead to the following behavior: Not taking the terminal seriously, and not solving problems for the terminal. Or, waiting for the fancy new solution to arrive. (It will never arrive.) Need I remind anyone that the Gemini protocol was designed with the terminal in mind?
The terminal is not an old and foolish technology which harbors endless problems that were solved years ago by smarter people working with proportional width fonts.
If the terminal sucks, its because its text-tooling has seen very little innovation in the past 40 years, after everyone "smart" abandoned it as a display for windows and proportoinal width fonts. And we all know where those "smart" people led us: right into the ditch.
I view the terminal as a WEAPON. ASCII is a weapon. It's up to us to hone these weapons and make our alternative to the dying overworld real and meaningful.
Mocking the terminal and providing no real solutions has no part to play in this. If 20 people took the terminal seriously as a /modern/ display, we could start a revolution. Anyone with even the slightest curiousity and insight can see the terminal poses great opportunities for innovation. I posted some ideas on this matter just a minutes ago in s/ascii_art. Geminispace is a great testbed for these innovations. The alternative is to continue to be a slave to big tech and their proprietary proportional fonts, the vast infrastructure required to sustain it, and the entire dystopian ID and AI plot sprung upon us to access it.
ASCII is the only universal format, and therefore the only democratic format. I believe it is also a revolutionary format.
We should be fighting for more ASCII and more terminal, however great the burden of technical debt may be. That debt is a gift bestowed to us.
May 30 · 2 weeks ago · 👍 mozz
I remember when the Mac came out. It was so tempting, but simultaneously, as a coder, I felt tight handcuffs regarding interaction with the user. I bought into it for a while, but Apple basically started a government-like bureaucracy that consumed people's minds, programming time, and CPU power at rates competing with US debt. I've wasted so many years learning and making work useless, stupid tech!
Yes, there is rarely a good reason to leave the terminal, and even then, to deal with a horrible GUI framework is just not necessary.
ASCII is the only universal format
What about languages that rely on non ascii characters? How democratic is a system which not only prioritizes English but literally doesn't support characters which we don't use?
I think all terminals handle Unicode.
This is incredibly narrow minded, as satch pointed out. ASCII is so incredibly limited.
The terminal further is not a weapon, it's just a tool, like any gui tool. Both have been used for decent stuff and both have been used for not. This isn't a war, sheesh.
The terminal is not very democratic if your native language is written right to left and has letters that don't fit in a single 'column' (incompatible with the idea of a monospace font)
👽 TKurtBond · May 31 at 16:33:
The Oberon System devevoped by Niklaus Wirth used a text based graphical user interface (supporting multiple fonts) that allowed the the user to add menus simply by opening another text file and entering the commands they wanted on that menu, which could then be executed directly using the mouse, with input to the command indicated in several standard ways. It used proportional fonts for everything, and was nothing like the common terminal. Later versions of the Oberon system supported text with embedded active components. The Oberon system is really amazing for everything it packs in such a simple package. The user interface is alien to the common conventions we are used to, but easy once accustomed.
🖥️ zetamacs · May 31 at 16:35:
@stack And they should. There is no good or principled reason to avoid it outside of programming for devices for which Unicode isn't an option, if you ask me.
I'm surprised there has still been no mention of Plan 9's reimagining of the terminal. Full Unicode support, ability to run a command and immediately block without scrolling so you don't need a pager, text can be freely edited anywhere it appears, "hold" mode for multi-line composition... in short, it's not an improved VT100-style terminal, it's something newer that's actually designed to work with a graphical display.
That's not as far as one could reasonably go, either.
@dimkr the solution for wide characters is double with like GNU Unifont does. It common in Japan, China and others.
— https://unifoundry.com/unifont/index.html
Some random thoughts
Going past ASCII does make everything an order of magnitude more complicated. Sorting order. Is a character capitalized? How long is a string? Simple bit tests are now calls to huge libraries, and things like sorting have no obvious solutions...
It's assumed for some reason, that one _has_to_ cater to every language, nationality, and gender, or be labeled 'fascist' or worse. If you are a huge corporation with unlimited resources and a desire to take over the world, OK.
If you are a person or a small group, I think it is perfectly reasonable to make a choice to limit the language support to a subset of the world. No disrespect is inherent in saying you will only support ASCII. Unless followed by a racist statement.
Although unless you really care about not linking any libraries (like I do in extremely minimal projects), adding at least superficial Unicode support is usually not a big commitment.
Are there really no terminals with good support for Arabic or Japanese? I find that hard to believe.
terminal resembles a typewriter. or actully teletype: tty.
what was printed once, can't be changed.
wirth designed oberon system to be text based, but it doesn't have terminals.
you can write a command (name of the object file and then after the dot name of its public function) anywhere. then click on it, and os will load the object file if necessary and execute the function.
ui can be text based, but not resemble a terminal.
@norayr: yes, the oberon interface is pretty amazing. I found out the hard way that I hate Oberon the language, though...
@MrSVCD I'm not an expert but I'm not sure if increasing width is a universal solution because some languages (like Arabic) have special cases specific sequences of letters become a single sign with width >=1, while most letters still have width 1
Unicode and UTF8 are pretty good bolt-on global solutions. However you never need to use 4 billion distinct glyphs. And rarely does one use more than a couple of different languages in a single document. In most cases, you could use 8-bit ASCII with the top 128 characters localized for your region. One would be enough for most European languages. In some cases like Japanese, just use 16 bits. This would be simpler and more compact. /
We had something like that, and people complained that you have to specify which code oage you are using. That is not hard, once per document! Instead we have to parse each character, which can be 1 to 4 bytes long, lose the ability to sort deterministically, can't tell the string length without parsing, and have look-alike glyphs that can be used by scammers.
In fact, UTF8 is a way to specify the code page every character!
Japanese has more than 5 ways to encode their characters.
Mojibake is what happens when encodings clash. (I saw it on DOS a lot)
— https://en.m.wikipedia.org/wiki/Mojibake
ASCII doesn't cover English, idéa isn't ASCII.
@MrSVCD: I could only think of 3... what are the 5?
@stack: from wikipedia: "There are several standard methods to encode Japanese characters for use on a computer, including JIS, Shift-JIS, EUC, and Unicode."
There are 5 versions of JIS, the first version worked easily on 8-bit computers.
@stack The top 128 might not be enough if you want to mix English, non-English and special characters - for example, if it's an algebra essay in Arabic, plus English letters and some special characters
@dimkr Yes for highly specialized tasks, a more complicated solution is worth it. But for the last week I've been saddled with annoying complexity putting together a simple Spanish quiz program. All I need is a handful of accented vowels and an Ñ. Now I have to use wide characters, causing a mismatch with stored data, or juggle UTF8 strings without being able to count bytes etc... Never thought I'd miss DOS.
TKurtBond, i was always wondering why in oberon system's text editors it is possible to use left and right arrow keys to navigate inside a line, but not possible to use up and down keys to change the line.
then i thought that maybe that's because in case of fonts with different width letters, there is this problem to solve, when if you go up, then down and you can find yourself in a different place, may occur, and wirth decided to avoid that problem.
@norayr: I've dealt with this issue on a few occasions. The solution is trivial to implement: maintain the target X position, and as the cursor moves up or down, go to the nearest available position.
Each vertical cursor navigation session keeps the target X, until horizontal movement, or some other X-altering event takes place.
Surely creators of languages and OSs are not stumped by such minor details...