As someone who has dabbled in terminal emulation (I was the maintainer of Console Telnet for Win32 twenty years ago), I have respect for someone who takes the time to optimize a terminal emulator by building a fast parser and being careful with screen updates.
That used to be the only way to make a graphical program fast, but these days hardware is so fast you can render an entire scene before the next screen refresh and still have cycles to spare. As long as you initiate rendering early enough, it's hard to go much faster.
I'm curious how foot compares to older fast terminal emulators such as Eterm, xterm, and rxvt. I think libvte is neat (anyone can write a terminal app now) but is it resulted in terribly slow programs like gnome terminal. Before that terminal emulators tended to be much faster -- they had to be, because hardware was so much more limited.
libvte is a big reason that GNOME Terminal tends to be faster than competing terminal emulators, including xterm and rxvt. One of VTE's tricks is that it doesn't bother painting the screen if the contents are going to be overwritten in the next frame anyway; you can scroll through megabytes of data in fractions of a second this way.
I have a 655MB file with 1.5 million lines of lorem ipsum. I timed a cat in several terminal emulators. For this simple test, gnome-terminal beat xterm a little bit but wasn't anywhere close to the rest:
And I don't really care that much but I will say that while it is a bit of a dog in the bulk display race, no one beats xterm in the keyboard latency contest.
Enabling fastScroll in xterm makes it competitive in the "bulk display race". It's disabled by default because who cares how fast a huge file can be displayed on stdout in real-world usage?
I've heard various things about VTE over the years including:
1. They "like" xterm because i get value out of screen tearing and feeling like they can catch what is scrolling by (even though it's literally seconds slower)
2. They don't like the 40 fps cap it currently has because it predates reliable access to vertical sync information in applications.
3. They are using the GTK 4 port which draws with cairo and uploads surface data on every frame update.
The patches I put together for VTE this week (while having some down time with Covid) address a portion of that by making it render fonts/rectangles/emoji/etc on the GPU using GTK's OpenGL renderer (which I also wrote a large portion of).
Years ago, the biggest bottleneck with VTE was that it was storing the scrollback history on disk (https://bugzilla.gnome.org/show_bug.cgi?id=631685). Eventually support for an in-memory scrollback buffer was added, which improved the situation considerably.
Long dumps of output with VTE seems to be fast enough, at least with a barebones program that creates a VTE widget and doesn't do much else. But Gnome Terminal was noticeably slower than my naive program, last time I tried it. I don't know why.
xterm has a command line flag that enables the same speed hack. It's disabled by default. The major difference between xterm and the others is that xterm emulates a terminal and libvte-based emulators, Kitty, and the like are more like shitty xterm emulators. Accuracy is preferred over speed, and certainly over silly microbenchmarks like cat'ing a 655 MiB file to stdout and timing how long it takes to display.
rxvt used to be my go-to terminal, but it was only fast in the era where we had actual 2D hardware. That era ended, oh, like 15 years ago? Ish? On the AMD side, Radeon GCN 1.0 (think 7970) came out 12 years ago, and that was their first card that entirely removed 2D hardware (which means all 2D ops are handled by optimized shaders; in Linux, that'd be handled by glamor); but wasn't the first gen of AMD that was in the process of removing 2D, and nvidia was about a gen behind every step on that.
Between then and now, I ended up trying every emulator. The libvte ones tended to be slow, buggy, and missing features (although, nowadays, it's sorta cleaned up its act, but not entirely). The terminal community has been able to write three emulators that make for good urxvt replacements: alacritty, wezterm, and kitty.
Foot seems like its trying to join those three, but it's lack of other-OS support (since it's focusing on being, purely, the best possible Wayland terminal) kind of holds it back (unless you're only using Linux, then obviously this doesn't apply to you).
I don't think I've ever encountered a problem where terminal emulation would be too slow. What I do have encountered are terminal emulators that go bonkers and require some arcane configuration magic to figure out what to emulate.
GNOME terminal works and looks pleasant to boot. In fact it works so well that I almost never think of it although I use it all the time.
> I don't think I've ever encountered a problem where terminal emulation would be too slow.
You don't notice it until you get into a situation where the terminal (emulator) insists on showing you everything flying by, instead of just skipping to the end, in which situation you may be waiting a really long time. Some emulators also cannot deal with, say, 1 million lines of scrollback and searching.
That's fine if you know that your logs or whatever will be very long, but if you're unaware of how long it is, or just don't think about it, it's easy to get caught in a situation where you have to wait for several seconds until you can use your terminal again.
Related: this problem gets way worse over SSH. It would be nice if there was kind of SSH replacement that could just send what's currently on screen, plus some lines in each direction.
Being fast is not just about hitting the deadline for 60fps or more. Ingestion performance (cat /dev/urandom), startup time and overall latency are also important factors.
There are a few terminal emulators that are fast enough that further optimization is mostly for the heck of it...
And ugh, gnome terminal. The internet explorer of terminal emulators, only used to install foot and alacritty.
Anyone has experience with Gnomes new "default" terminal console? How is it feature-wise (compatibility with different terminal emulations) and performance-wise?
I've been using Foot for a while now, having switched to it from Alacritty. I like it. I don't really require much from my terminal other than for it to "feel" snappy and to have some cosmetic customization, and from my own playing around, it does both well.
I tried it for a week or so on Ashai. It was super fast. However the lack of tab support ended up being a dealbreaker. Multiple instances are ok, but I prefer tabs at the top of my application.
Which allows you to do tabs (with wm). So it has tabs if you really need them. Also foot can be used as a server and client, which I use all the time. It allowes for instant start and less memory consumption, when you need many terminal windows open.
I've never understood the love for tabs. They stop you from seeing two terminals simultaneously. I mean, we invented windows exactly for that, didn't we?
It depends on what you want to manage your tabs. For example, a good tiling window manager will handle tabbing for you. In i3 Meta-w will swap into tabbed mode.
You sound like a fellow Sway user. I switched too for a bit, as it’s the new blessed terminal, but I had a couple glitches in a TUI app and switched back. Not really sure what I could have really gained by switching. They are both great.
Unfortunately there is no support for ligatures. A good programming font like fira or source code pro makes for such a quality of life improvement. At least easier on the eyes.
It seems that many terminal emulators can’t or won’t support them, because they are hard to render properly.
Does anyone have a handy guide for getting rolling with (neo)vim as IDE? I’ve been using LunarVim which mostly works but has enough annoying edges that I want to roll my own config; but there is a lot of ground to cover and I’m not sure where to start.
Kickstart.nvim [1] is a good starting point. One big Lua file which gets you 90% there and shows what’s possible while making it easy to change/add stuff and getting started doing your own config.
I’ve really enjoyed AstroNvim and have used it pretty regularly for more than a year now. No major breaking upgrades, and very good support and user manual.
That’s because writing Java all but requires a giant, heavy ide. Like IntelliJ, eclipse or netbeans, and always has. Vim + lsp for basically any other sane language is good enough.
You can keep telling yourself that, it doesn't change the fact that IDEA beats any plain text editor for working with code in any language I've ever seriously tried.
It's not just Java. I used vim/neovim for about a decade on and off, and then went all in on neovim for about a year (because I honestly wanted to see what's on the other side), forcing myself to believe that lie in spite of my experience screaming the opposite the whole way, but eventually came back to IDEA because it's not “good enough” if you know both of them well.
One works with code on the AST level, understands the whole project at once, and is developed as a monolithic project (not really — IDEA is very modular and is built as separate components, but they integrate so well you don't feel it).
The other works with text in currently open files and has smart features tacked on the side through language servers of varying quality (the best of which have 10% of functionality supported by a comparable IDE). The difference in how they behave and what you can accomplish (I repeat, if you know both of them well) is considerable.
There are lots of things to criticize in JetBrains' tools (terrible performance, well known bugs go unfixed for decades), but it's not just a glorified text editor.
Also, Java does not "require a giant IDE" any more than other languages do. The language — because of its static typing and good support for reflection — lends itself to writing excellent autocompletion and refactoring tools. Same for C#, F#, Kotlin. Most other languages simply don't have them, not that they don't need them — they just generally cannot have them because of heavy reliance on runtime “magic”, or small user base, or exceedingly complicated analysis (even JetBrains “failed” here — CLion is a quite poor experience compared to Rider/IDEA), or other reasons.
All the reasons you give for idea being superior sound like Java developer problems.
Maybe I don’t need my editor to “understand the entire project” because the code I work on is modular and self contained enough that it doesn’t matter.
When I need a big refactor, tests are usually there to help.
Of course, when you are working on a code base full of AbstractAutowiredFactoryBeanFactories the yea of course you are going to need some more involved tooling, because it’s impossible for a human to read.
> Maybe I don’t need my editor to “understand the entire project”
With all due respect, I don’t think you have seen the monstrosities project can grow into over multiple years and big teams. Not everything is at the scope of, say, Foot - but even this pushes the boundaries of human understanding without tools to aid.
Just as much as going to the 10km away supermarket requires a car or public transport - you can walk if you want, but I will have already went home from shopping while you are still just started walking.
Naw, you have no free time because you live in a food desert where you can't even walk to get groceries and you're stuck in your car for everything. You're totally dependent on a giant, expensive, resource-intensive monster. It would be nice to have options, but you're locked in.
Tbh, I never ventured outside of Konsole. Never felt I was missing something or was limited by performance or anything beyond what the stock Konsole offered.
I feel the same...and often, when i feel that, then maybe i'm not the target audience for said tool/app.? (Which is not bad either way, simply that as good as the tool/app. might be, its just not for me.)
I try to use KDE every year or so, and I've been doing this since KDE 1.0. It consistently keeps not delivering the experience I want. They have an uncanny ability to keep inserting "jank" everywhere, making the whole experience feel almost good but not quite.
But I'll keep trying it. Perhaps they'll get there before I die of old age.
Not sure what you mean by jank, but nothing else even comes close in my experience. Gnome feels clunky in comparison with stuff like missing server side decorations and lack of adaptive sync on top of that.
I don't doubt that people like KDE, I just cannot figure out why. Something to do with usage patterns, perhaps. I never liked the Windows 95+ style UIs, perhaps that's it. Also KDE seems to be always be riddled by display bugs that I get to experience.
I use Gnome when the desktop is irrelevant, like for instance my gaming box. Sway for when I want to optimize developer experience.
Admittedly this was fifteen years ago, but I was blown away by the developers’ inability to make any actual design decisions, instead punting literally everything to a mountain of configuration options.
Case in point, the taskbar system clock. There were no fewer than six full tabs of options to customize its behavior, including the ability to use Swatch Internet Time. Everything else bought into this philosophy too, to the point where I have to believe its users spend more time configuring it than actually doing anything useful or productive.
KDE still has this mentality, though they try to somewhat sweep it under the rug. Toolbars aren't overflowing anymore... usually. But the menus and dialogs still have those hundreds of options and it definitely gives a feeling that the developers can't commit to decisions themselves.
Really, KDE just has a maximalist philosophy. Shove everything into users' faces all at once because of all possible opinion variations.
Part of why I like GNOME is that it's the exact opposite: minimalism. The options it does offer tend to be the options you actually might want to tweak, and there's not many of them. (In the GUI anyway; GNOME still has lots of options available via dconf-editor/gsettings, basically the GNOME equivalent of the Windows Registry)
A lot of the last few years of releases has been about tweaking defaults and providing a smoother experience for first time users. This is very subjective obviously, but I find KDE Ddefaults to be a lot closer to what I like, and I appreciate having all the options be built-in as opposed to having to hunt a dozen or so random gnome shell extensions to get that last 5%.
KDE 3 and 4 were a dumpster fire. Even the first release of Plasma was very rough. But I switched to KDE maybe 5 years ago and never really looked back. If your experience with KDE is from 15 years, give it a shot with an open mind. It’s pretty great imo
Kids today will never know the awesomeness and terribleness of Swatch Internet Time. I remember when they gave a bunch of money to CNN and for a brief period the time listed on articles was Swatch Internet Time.
That aside from the tz name, it looks like regular time in a regular timezone (where you or the other person recides), so it's equally easy to confuse.
"Oh, you meant 11:00 UTC, not 11:00 Berlin time, ooops!".
Well, it's a matter of taste. But I find the latest version quite pleasant when using Krita's dark orange color scheme.
I really, really, love how much I can customise though.
I also try GNOME, Xfce, and Cinnamon every new relatively big release. And, as far as I'm concerned, really like all those projects.
I must say though, I hate how GNOME locks you in to their apps. I understand their commitment, but for instance I would appreciate if they let me choose which terminal I could launch from Nautilus.
I use KDE, but it's just a matter of preferring their development tools.
Foot has an opt-in server mode so that if you are used to running multiple terminals at once, you can save a little memory. Great for a low-end device. Of course, if the server is closed/crashes, you lose all the client terminals which can be annoying.
Unfortunately it tends to do so randomly (was using foot for like 3 or so years by now). And in the end you'll only ever end up saving single digits of RAM. I suggest using server mode *only* on a RAM constrained device like a SBC or a embedded device (Tablet running Linux).
I use it this server-client mode for a couple of months at least, and I never experienced any crashes. Not that I see a huge difference, just it fits my workflow better. I do have many many terminal windows open at the same time, but most of them aren’t busy doing something. They are either some kind of app (e.g. ranger) or a space I usually come up to do something specific (e.g. this workspace I use for sshing that server and that workspace to do things locally).
I was very impressed with Foot on my MNT Reform, where I was having trouble getting Alacritty to work (hardware issues too difficult to overcome, and I say that as someone who was able to apply a patch to make Alacritty run on my Pinebook Pro before the mainline version supported the hardware). Foot installed and ran like a breeze, and never felt slow even with pretty minimal hardware.
When I used a Raspberry Pi 4 with 64bit kernel+userspace and Wayland (sway), foot was the only native terminal that didn't eat up lots of CPU. I presume some kind of OpenGL vs OpenGL ES issue.
So i lokked a bit more and the sixel support seems to be decently good in foot (and i need something that works in tmux)
you can even play doom or videos at 30fps https://codeberg.org/dnkl/foot/issues/481
This made me curious about image support in the emulator I use (iTerm2), and I learned that it has these cool utilities[0] that (inter alia) add aliases for imgcat and imgls, which are exactly what they sound like.
This certainly looks interesting. I've been using Kitty for a while and it works great and supports so many features. It would be nice to see how it compares to Foot in terms of speed. I'm also curios about Ghostty, the in-progress (but currently private) terminal from Mitchell Hashimoto.
How do TUI software like nano or tmux that support mouse input behave under Wayland? Do mouse inputs work as they should?
Has someone here who's using Wayland give it a try?
I have no idea how ncurses (I guess) interacts with the mouse through the terminal so I don't know if it relies on X11.
Well, all the terminal emulator needs for this is the cursor position inside the window, which Wayland provides. Nothing X11 specific here. Ncurses and similar just ask the terminal emulator to provide mouse click Escape codes.
I appreciate that their benchmarks are executed in a peak-optimized build. But, it leaves open the question of whether anyone actually enjoys that peak performance, because all the users install it from unoptimized distro packages.
I'm limited to choice of terminal emulator due to having a hard requirement for quake style one-keypress dropdown. Unfortunately, in pursuit of cross-platform compatibility the *critties feel like this is a desktop environment problem, and the last gen of console apps that can do this are getting a little long in the tooth and starting to break in things.
It's a bit meh, IMO. Doesn't honour my dark theme settings. Doesn't support horizontal or vertical splitting, or even tabs. I'll stick with my very non-minimalistic Terminator.
A faster terminal feels better. It is the kind of things that are hard to point out but enough to feel the difference side by side.
I definitely noticed it when I switched from terminator to kitty.
Now the race of which one will cat a large file the fastest is a bit pointless, but it should be fast enough not to add more than a frame of latency for regular use.
Setting aside the fact that it's no fun waiting around when you accidentally cat a gigabyte log file to stdout, a more efficient terminal has two main advantages: it runs better on low-end hardware, and it uses less power to do the same job. If you have a fast computer and don't care about battery life, there's no real reason to switch.
It really is nice once managed - it's hard to explain, but everything is very smooth. I would guess the display synchronization/mixed refresh rate support is to thank.
Some Electron-based things and Steam are the main holdouts I've noticed.
I suspect the Electron things at-large will be sorted out before Steam... they simply need to rebase while Valve has to modernize their libraries (ie: vgui)
I love this terminal but it had a lot of flickering issues when I would run it on sway with nvidia drivers. Ended up just going back to xorg, I use kitty there.
That used to be the only way to make a graphical program fast, but these days hardware is so fast you can render an entire scene before the next screen refresh and still have cycles to spare. As long as you initiate rendering early enough, it's hard to go much faster.
I'm curious how foot compares to older fast terminal emulators such as Eterm, xterm, and rxvt. I think libvte is neat (anyone can write a terminal app now) but is it resulted in terribly slow programs like gnome terminal. Before that terminal emulators tended to be much faster -- they had to be, because hardware was so much more limited.