Alternative terminal emulator standards

From what I have seen, most terminal emulators are rather convoluted in their programming, and in some cases very bloated (just look at how many useless features xterm has), but despite this, it is impossible or plain difficult to get them to do nice tricks. They have lots of features very little people use, I guess to be compliant with the terminals they are trying to emulate, but they are useless. Basically, terminals are still primitive programs that are only good for displaying text (well, that's what they are for, after all), despite having the complexity of something that could do something more, but doesn't. Furthermore, our current terminals somehow manage to fuck up their text printing from time to time, so they are not even perfect for their own purpose!

I think we are stuck in the past. We are still trying to replicate devices from the 80s, such as the VT100, and sometimes those devices weren't even ready for screen sizes over 80 characters wide. They say that if it ain't broke, don't fix it, but if we keep hanging on to legacy stuff, we could be missing out on the possibilities of the future.

Could a new standard for simpler, cleaner terminals be developed? Or even better, a simpler, yet more flexible and powerful terminal. Stuff like full color support (relatively easy to do) or even letting programs create small virtual "windows" or compartments with different font sizes (including a square cell mode for software rendering of complex shapes, like pictures) would make CLI programs more powerful in case they need it while still being relatively simple to implement, even with only escape sequences and file tricks.

Other urls found in this thread:

destroyallsoftware.com/talks/a-whole-new-world
hyperterm.org/
youtube.com/watch?v=tpD1QXvtlcg
github.com/withoutboats/notty
github.com/MovingBlocks/Terasology/blob/develop/docs/Conduct.md
twitter.com/SFWRedditImages

...

Thanks for your extremely valuable input, veridian pointer mememaster.

Your proposal reminds me of this: destroyallsoftware.com/talks/a-whole-new-world

we probably get something bullshit from jewhat & team potterhole.

So many words, so little cluefulness.

emerge xterm
emerge xterm
emerge xterm

You're bitching that terminal emulators are too complex and at the same time so unbelievably ignorant you didn't even know all this has been done by them

What I got from this is that it can't be done.

Yeah, xterm does that.
Could you point out what's the name of this feature in xterm, and how to exploit it?
I know there are some terminals that support hacks for image overlay, but they are not part of the protocol. More often than not it's just rendering an image on top of the actual terminal via GTK or other libraries.

...

More like

Just use st.

Terminals aren't supposed to do advanced things, they only have to host your shell.

I would be surprised if it actually works as intended without breaking on a little change.

There have been some discussions about st here. The consensus is that it could be good if it wasn't so slow (noticeable for some curses applications).

Here ya go, OP
hyperterm.org/

st does correct UTF-8 and 24-bit color. The only thing it's missing in the OP's retarded feature list is tek4014 emulation, and that's a good thing. We already have a system that does the rest, it's called X11.


The cpu-eating slowness is fixed in git. Can confirm because I was the one who brought it up in the last dozen threads

Currently we're stuck in the past because of path dependency. Old things just work, and people expect them to work that way. If it doesn't, then it just needs extra work for everyone, like how the systemd people try to make things work their way.

Consider keyboards. Qwerty is the default layout in majority of computers. The original reason for that layout is no longer relevant. However, people are used to that layout and expect their computer to have it. Few people have changed into something else and it works fine for them. Except when they go to someone else's keyboard.

Keyboard layout is simple to change, because it is personal. Terminal on the other hand is something that a lot of different programs share in your system, including yourself. Surely you can design a terminal for some snowflake platform and a few programs to it. If you want it to become a new standard, it has to be exceptional. Otherwise it's just another keyboard layout in a way.

As anons have pointed out, OP's proposed design is flawed though. It's not a terminal in the most minimal sense. You'd need some way to control all these fonts and windows. How do you do that, other than with escape characters? Are you going to design some kind of API, faggot? How are people supposed to implement it in their terminal emulator?

OP's belief is that when you stop emulating old terminal hardware and design equally or more complicated system from scratch, it suddenly becomes free of bloat.

Now, I must meme again.

Mods.

Fixed in 0.6 or I need git?

like you fags have a fetish or something.

The "worst" part about this is that the program being run should be aware of the terminal, but this is not much of a problem. Libraries like ncurses already have to be aware of some things about the terminal, or otherwise they wouldn't be able to compute the size of its frames or center stuff in screen. I think it is done through environment variables, but I am not sure since I haven't studied ncurses' code.

Font size wouldn't be that difficult to implement, if maybe a bit difficult to design properly. I would personally only allow font size to be determined at the start of the line to avoid having to redraw the earlier characters because that would make text look bumpy, but you could also make bigger text occupy the space below the line instead of the space above to have differently sized characters inside the same line. Same goes for square grid mode, it's just a escape character away.

About the virtual terminal mode, that would be a bit more complex, but still doable. Since this is Unix, everything displayed in a terminal can be thought of a text file. Said "text file" can actually be found by running the command tty in your terminal, and in fact you can have some fun by sending stuff to be displayed from one terminal to the other by writing on this file. With the use of escape characters at the start of a line, you could tell the terminal to split horizontal space from that point onwards into two virtual terminals, either in characters or percentage of character space (which would work better with resizes). After that, you would essentially have two terminals in a tmux-like fashion, and by accessing an environment variable in the same fashion ncurses does with terminal size, you could access the two new pts like you would access your terminal. The viewport keeps track of the most "advanced" subterminal, and returns control to the original terminal once the subterminals are closed with another escape character.

I'm listening, please carry on
Fucking dropped. What is it with these web faggots trying to make everything in JavaScript. It's like watching an idiot build a house from plywood. Plywood is a good material for what it's meant to be, but you can't use plywood for fucking everything.

not in 0.6

youtube.com/watch?v=tpD1QXvtlcg

It needs to be written in Rust btw

st

Yes? Did you fall on your keyboard?

...

github.com/withoutboats/notty

i know everyone loves to bash rust around here, but this project is just what you were talking about

...

This could be pretty great if they finally manage to implement many of those features that are not implemented yet.

I know you're joking Christina-chan but it might actually be a good idea here, for a relatively low level user land program like that it should be either rust or sepples.

Certainly not fucking Javascript in any case.

eshell

>As a Rust community project, notty is committed to upholding the Rust Code of Conduct. If in a setting associated with notty anyone does anything which you believe violates this code of conduct, or which makes you feel uncomfortable or unwelcome, please contact [email protected]/* */ and I will take action that I feel is appropriate.

...

Have you read the Rust CoCk? It's not good, but it's miles better than the Open Code of Conduct version projects like Terasology are using.
github.com/MovingBlocks/Terasology/blob/develop/docs/Conduct.md

Apparently the newest Open CoCk has removed the reverse -isms clause, but it went as far as saying that if you were a minority, you could be an ass without any consequences. Rust is pretty tame compared to that, and the only clauses that don't amount to "don't be an ass" are the offensive nicknames clause and the sexual jokes clause.

The reason they are doing it is pretty cancer, though. Apparently, they care too much about their most sensible contributors; the ones that could get so triggered about someone having a silly name that could leave the project permanently the moment they saw something slightly unpolite. As some "dissenters" have correctly pointed out in the Reddit CoCk thread, if these people are so sensible, they would probably not even accept constructive criticism too well, so it seems kinda pointless to pander to them.

CoCks are usually glorified forum/community rules. I would go as far as saying it's an euphemism for the same thing that SJW have adopted to make it look more serious or Orwellian. Nobody was triggered by forum rules back then, and even we have some, so I think we should read what do these rules say before we jump to conclusions.

Heh.