Hopefully not too off-topic, I have a question: shouldn't we stop using terminal emulators already (i.e. why do we still require emulating the terminal hardware designed in 1970)? Wouldn't a text editor-like user interface be more sensible? (Perhaps, something similar to emacs' M-x shell but more universally adopted.)
I agree with you as an end user that the features of all terminal emulators available in emacs are atrocious. Have my up vote, and silent support should you decide to really put some time into a better terminal for emacs.
Yeah, implementing a new terminal emulator (and a custom shell!) is pretty rough going. I've heard the idea expressed that it's hard to get programmers to use a new code editor, even if you have a killer feature, because they need to see every feature that's ever been implemented in every old editor before they'll switch. Reminiscent of Light Table.
All of emacs' terminal emulators have been resoundly awful for me. This was probably my biggest disappointment with emacs. I was so looking forward to having the shell be useable from inside emacs, but it's really not.
Now I just use a regular terminal with tmux inside it and emacsclient inside that.
These terminals still speak an archaic and anachronistic protocol, fragmentation in the supported feature set puts IE6 and Opera Mobile to shame, and TUI applications that run in terminal emulators feel completely out of place in a modern (modern = I'd say past 20, maybe 30 years) desktop environment.
I can open vim, irssi, moc, htop, nethack, or a dozen other TUI apps, and every one of them has different key bindings, different color scheme (sometimes assuming/hardcoding white text on dark background, sometimes vice versa), different paradigm for supporting multiple buffers, different way to configure it, different way to exit - but each window still has the same icon in the task bar. KDE did this better in 1996. Mac did this better in 1984.
Even if I stick 100% to using CLI (stdio) programs, the facilities have barely improved at all since the time job control was introduced - there's a lot of potential to actually innovate here, but that would probably require breaking out of the separate terminal+shell paradigm. There were more radical attempts, but AFAICT the bleeding edge of innovation in mainstream emulators is iTerm displaying the process tree in a popup.
It's the most rich ecosystem of lowest common denominator software in existence. We have sRGB correct linear gamma blending, but Emacs in terminal still loads the wrong dark/light theme - unless you cobble together a hundred lines of custom elisp glue. I don't even understand why we need gamma blending, nobody can implement an actual production-quality graphics editor in a terminal (unless you want to double down on sixels...).
Using a terminal in windows was a horrible experience when I had to do it for a (fortunately brief) project a couple of years ago. But I think the real problem isn't the lack of a decent shell; there are already several shells out there that, while not as nice as their modern Unix equivalents, are at least usable. The bigger problem for me was the terminal emulator. Awful fonts, worse rendering, crappy copy/paste, limited size, no split screen or tabs, etc etc. It truly felt like being back in the 90's, although I'll bet that even in the 90's the Linux terminal emulator experience was better than Windows is now.
Thank you. I think it's a bit misleading then to call it a "terminal emulator". It's not really emulating one of those old boxes, is it? It's providing a text interface to a computer's functions. That's great but it's not emulating anything.
Terminal emulators, IMO, have 2 big reasons they are popular. First is that they work like a better, more stable web browser in the sense that they provide a standard platform to develop UIs on. Second is that the command shell is arguably the best general purpose UI we have for computers today and it lives in the terminal.
First, if I want to come up with a setup that includes a modern terminal emulator with lots of features, a decent number of extensions and plugins for things like zsh, etc..., I will INEVITABLY end up with a something that:
1) has way more input latency that it should have (iterm2, Ive had to just fall back to Terminal.app)
2) takes WAY too long to launch a new bash/zsh/whatever session if I split a window (cause parsing thousands of lines of autocomplete code written in bash, profiles, etc... is SLOW). Shit, just installing nvm and sourcing all its crap adds an easy 400ms to session start time.
3) works on one, maybe two platforms at best.
Second: I understand that using a terminal for everything is inevitably going to be less efficient that a UI in very specific scenarios, but this ends up being true way too often, and a large part of it is due to the CONSTANT need to parse/marshal/unmarshal output format of one program to get it right for input somewhere else. Some of that is the terminal's fault (along with the whole CLI ecosystem), but a lot of it is just cause there are 9000 different competing formats for human readable structured data. Powershell really tried to get this right, and I salute them for it.
Third: terminals have been around for a long time, and they've come up with their own conventions for keyboard shortcuts/etc... over the decades; I get it. But its time to just dump that baggage and default to whatever the standards for a particular OS are.
i mostly agree. if you want to run an application that assumes ansi escape sequence support and a terminal emulator that doesn't implement ansi escape sequences, you can run a terminal emulator inside your terminal emulator, with the inner terminal emulator interpreting the ansi escape sequences and talking to the outer terminal emulator with whatever escape codes the outer one uses
three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw
— ? —
what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can
1. write programs for in any programming language such that
2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and
3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and
4. the program is interactive (html kind of fails at this), and
5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and
6. small computers (under a megabyte of ram) can be used to show the program's user interface, but
7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc.
emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video
obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel
i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead
And people wonder why I think terminal is pretty horrible environment for anything but purely line driven applications. Just the other day my coworker was asking my why on earth do I run gvim instead of vim in terminal; I feel now vindicated. Sure, I haven't hit this issue but I am all the time cognizant of the eldritch horrors that are the terminal emulation layers, which makes me prefer to avoid them. And having tmux sit in the middle doing another emulation layer does definitely not help the feeling.
I just wish there were more almost ncurses like lightweight toolkits that would run natively in graphical environments, because to me they seem pretty rare.
It's great to see improvements in Emacs. Are there any developments on getting a decent terminal emulator? I use term but occasionally have to open GNOME terminal when Emacs' term can't display something properly (like ncurses-based programs).
I guess this is cool, but maybe they should focus on actually making Windows Terminal into a usable terminal emulator first. I've found so many bugs with it and it still doesn't even have a GUI for its settings.
reply