Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Looking for a substitute terminal emulator. (Read 2978 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Looking for a substitute terminal emulator.

Hi I came from dwl, and I'm looking for a terminal emulator that runs on Xlibre that is just as lightweight and full featured as foot terminal: https://codeberg.org/dnkl/foot

Am using st, but it lacks features even with patches. There are others that can match foot in features (or more) but consumes 8-10x ram. That's absurd for a terminal emulator.

st and foot eats up around more or less 30mb of ram
alacritty at 270mb
ghostty at 300mb

Tried urxvt the one with truecolor support patch (latest one in aur) gives a segfault.

Any recommendations that fit those parameters?

Re: Looking for a substitute terminal emulator.

Reply #1 –
Not sure what your required features are (never used wayland), but I've been surprised at how much I like zutty. Been using it as my main terminal for about a year now. It is lightning fast compared to anything else I've ever used. Binary available in Arch's extra repo.

Re: Looking for a substitute terminal emulator.

Reply #2 –
Quote from: lotuskip – on
Not sure what your required features are (never used wayland), but I've been surprised at how much I like zutty. Been using it as my main terminal for about a year now. It is lightning fast compared to anything else I've ever used. Binary available in Arch's extra repo.

Supports truecolor, does not change the blinking frequency of cursor (or better yet completely hide input) when typing password. Consumes 30MB more or less per terminal session. Clearing the terminal screen actually deletes everything even when you backscroll. Doesn't crash and is fast even when testing 'cat /dev/urandom'. No GUI such as scrollbars, topbar, etc. Based on compiled languages.

That's all pretty much I require.

I tried zutty but it eats up 250+ MB of ram per terminal session.

Re: Looking for a substitute terminal emulator.

Reply #3 –
Quote from: clappingsnowdrop – on
[I tried zutty but it eats up 250+ MB of ram per terminal session.
Huh. I guess that's the hardware acceleration. From Zutty's own comparisons:
Quote
Of the three GPU-accelerated terminals, Zutty consistently uses the least amount of memory – less than half of what Kitty consumes, in both tests.
Overall, only xterm, urxvt and st are able to consume less memory than Zutty.

Re: Looking for a substitute terminal emulator.

Reply #4 –
Quote from: lotuskip – on
Quote from: clappingsnowdrop – on
[I tried zutty but it eats up 250+ MB of ram per terminal session.
Huh. I guess that's the hardware acceleration. From Zutty's own comparisons:
Quote
Of the three GPU-accelerated terminals, Zutty consistently uses the least amount of memory – less than half of what Kitty consumes, in both tests.
Overall, only xterm, urxvt and st are able to consume less memory than Zutty.

Seems like all gpu-accelerated terminals consume atleast 250+ MB of ram. No idea how or why, but unfortunately that's a deal breaker for me.

Managed to get urxvt work. Needed to configure quite a bit. It looks ancient out of the box, but now it looks just like and functions close to my foot terminal config. Not confident if it's stable or not. If I don't post updates about it (within 30 days) then it's "stable".

Can't enable blink though as when going into password prompt mode, the blinking stops when it receives input. I'm willing to make a concession for that specific feature. Unfortunate but it seems this is a common flaw in terminals. Only foot, wezterm, and ghostty implements this well.

Ram consumtion is about 30 MB more or less. Same with foot and suckless terminal.

Re: Looking for a substitute terminal emulator.

Reply #5 –
If RAM consumption is a problem because you have a lot of terminal sessions open, you should give Kitty a try: it supports running everything in a single process. The first window is gonna cost you roughly 150MB, but every window after that is like 5MB, so, after 7 or 8 windows it actually saves you RAM.

Re: Looking for a substitute terminal emulator.

Reply #6 –
My understanding is that it's basically the double buffering that eats up memory. And the amount then depends on your screen resolution & terminal window size.

If urxvt is your choice (used to be mine) and RAM is precious, definitely run the server (urxvtd) and start terminal instances as clients (urxvtc), not standalone (urxvt). I still have 'urxvtd -q -f' commented out in my .xinitrc. The clients start up slightly faster, too. Not sure if people with modern hardware notice that sort of stuff at all, but I have a humble machine...

Re: Looking for a substitute terminal emulator.

Reply #7 –
Quote from: Pragma Once – on
If RAM consumption is a problem because you have a lot of terminal sessions open, you should give Kitty a try: it supports running everything in a single process. The first window is gonna cost you roughly 150MB, but every window after that is like 5MB, so, after 7 or 8 windows it actually saves you RAM.

Like a terminal server daemon. Problem is that if the server crashes, so does all the clients. So I prefer standalone clients. Currently am in Xlibre. I think kitty is wayland only, it wouldn't launch when I tried.


Quote from: lotuskip – on
My understanding is that it's basically the double buffering that eats up memory. And the amount then depends on your screen resolution & terminal window size.

If urxvt is your choice (used to be mine) and RAM is precious, definitely run the server (urxvtd) and start terminal instances as clients (urxvtc), not standalone (urxvt). I still have 'urxvtd -q -f' commented out in my .xinitrc. The clients start up slightly faster, too. Not sure if people with modern hardware notice that sort of stuff at all, but I have a humble machine...

While I have quite a bit of ram to spare, I still would prefer not to allocate that much ram for a terminal.

Gave xterm a shot, configured it and it meets every requirement listed above, even the password hide prompt. But for some reason it's slow in output. About .002 ms per line of output from the command ls -lha (165 lines). Compared to all other terminals listed above where it's instantaneous.

Now am contemplating of which either to choose xterm or urxvt.

I know I'm being nitpicky about it, but it's because I don't really use GUI unless really necessary, (steam, games, etc.)

Re: Looking for a substitute terminal emulator.

Reply #8 –
A more exaggerated test of 1000 files
Code: [Select]
touch file-{1..1000}.txt

urxvt
time ls -lhart

real	0m0.009s
user	0m0.003s
sys	0m0.006s

xterm
time ls -lhart

real    0m1.010s
user    0m0.006s
sys     0m0.006s

Re: Looking for a substitute terminal emulator.

Reply #9 –
Quote from: clappingsnowdrop – on
[Like a terminal server daemon. Problem is that if the server crashes, so does all the clients. So I prefer standalone clients. Currently am in Xlibre. I think kitty is wayland only, it wouldn't launch when I tried.

Kitty is definitely not Wayland only. If Kitty and urxvt carsh, there might be something odd with your system.

Re: Looking for a substitute terminal emulator.

Reply #10 –
Quote from: Pragma Once – on
Quote from: clappingsnowdrop – on
[Like a terminal server daemon. Problem is that if the server crashes, so does all the clients. So I prefer standalone clients. Currently am in Xlibre. I think kitty is wayland only, it wouldn't launch when I tried.

Kitty is definitely not Wayland only. If Kitty and urxvt carsh, there might be something odd with your system.

You're right, checked my kitty config and I had set it to wayland only. Launched it. Consumes 300MB of ram.

Re: Looking for a substitute terminal emulator.

Reply #11 –
I've chosen to pick xterm. Went into a rabbit hole as to why it's slow. Found out two things:

1. It isn't. It just processes each output stream per line. Whereas other terminals skip this step. Easily verifiable by redirecting the output an ls -l command in a directory with 10k files to /dev/null with the time command.

2. Using the ls command with colors slows down the output. Also easily verifiable with these tests: (also within the same 10k file directory)
Code: [Select]
for i in *; do echo "${i}" ; done
or
ls -l --color=never

Note: I'm using vivid for my LS_COLORS which has a lot of colors set for specified file types/extension.

Workaround for #2 is to do this: (source on the bottom-most answer.)
Code: [Select]
eval `dircolors -b | sed s/or=[^:]*://`
The problem is that it now doesn't show my color config correctly with this workaround. These LS_COLORS seem to be the tty default.

I don't think there are any more terminals for me to test on. Newer terminals in the future will probably be gpu accelerated and as a consequence it consumes a lot of ram.

I will mark this now as solved. Thanks for the tips and suggestions lotuskip and Pragma Once.

Re: Looking for a substitute terminal emulator.

Reply #12 –
Quote from: clappingsnowdrop – on


I don't think there are any more terminals for me to test on. Newer terminals in the future will probably be gpu accelerated and as a consequence it consumes a lot of ram.


Not sure what the ram consumption is, but i've always found RoxTerm to be light and efficient (YMMV of course). I'm not using xlibre (yet) but hopefully soon. :)

Re: Looking for a substitute terminal emulator.

Reply #13 –
termite (if its still around), tmux, screen
Supercalifragilisticexpialidocious

Re: Looking for a substitute terminal emulator.

Reply #14 –
termite is for whatever reason dependent on systemd.

UPD: actually it can be compiled without systemd support, but still it's undeveloped anymore.