I've been using a few - in the end I landed on sakura: http://www.pleyades.net/david/projects/sakura

I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like config file, and I can easily have different font preferences on my laptop, my netbook and my desktop (all different screen sizes and different PPI).

FFW I use a spartan xmonad setup, and typically run one, or a handful of terminal windows, each with their own gnu screen instance (typically one local, and a few remote screen instances over ssh. Sometimes I'll have more than one view/windows to one screen session -- and sometimes I might have a screen for a chroot or local vm/container of some sort).

Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm.

I do have one question though, why are the colors more pale in sakura than in xterm?

And is there any way to change it?

I have no idea about sakura, but being a libvte-based terminal, I highly doubt it's comparable (or even approaches) xterm in term of rendering speed.

I'm wondering how people can compare these terminals mentioning speed, considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring?

xterm is quite fast (in the order of 3-5x faster) than any libvte-based terminal. Try doing something like "time [term] -c 'cat <bigfile>'", and try varying the scrollback size to have a real measure.

[u]rxvt in turn is even faster, especially with large scrollback buffers, which is the main (I could say only, really) reason I use it. As in, 10x faster than any libvte based terminal.

I also use suckless tools (with spectrwm), though I never had a reason to investigate st. urxvt supports fallback fonts, which for UTF-8 text is essential.

> I'm wondering how people can compare these terminals mentioning speed, considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring?

Not sure about others, but the first thing I test: dmesg; ps auxww; ls /dev

I only really care about apparent speed and, like I said, sakura was the only one that was comparable to xterm.

None of the other terminals I have tried (and only now I realize that they have libvte in common, thanks for that) have managed to perform acceptably (for me, at least).

On my windoze box now, so can't check - but I think there should be something about colors in the right-click context menu? But I'm not entirely sure when (as in which version) palette/colorset support[1] was added -- it might not yet be in Debian stable?

https://code.launchpad.net/~kraiskil/sakura/colorsets/+merge...

Awesome, thank you!

If others have the same issue, it's: right click -> Options -> More -> Set Palette -> Xterm

I've used gnome-terminal, sakura and now I'm using terminator: http://gnometerminator.blogspot.co.uk/p/introduction.html

The main difference with the other terminal emulators is that I can easily do horizontal and vertical window splits.

Many use screen or tmux for that but I find them too limiting, especially in their scrollback implementation.

i always found screen splitting in the terminal when you have a graphical window manager kinda of silly.

This is especially true when using a tiling window manager such as wmii.

In that case you don't even have to rearrange windows - each new window automatically takes part in the split. And you can combine terminal sessions, browser, etc. as you wish. I find this a lot easier to use than screen/tmux.

I'd love it if there would be graphical frontend to tmux or screen. Something that would look very much like a terminal emulator, with tabs and splits, but backed by screen or tmux, whereby each tab or split window would be a tmux or screen window. And the awesome part is that when you're elsewhere, you could ssh in and attach to that tmux or screen session.

You can send commands to a running tmux session, eg. http://superuser.com/questions/492266/run-or-send-a-command-...

How far you take it depends on what you'd want out of such a tool. Simple "New Shell", "Close Shell" buttons would be easy; overlaying draggable partitions would be more effort, and less elegant, but still do-able.

You can do that on OS X with iTerm2 e.g.: http://www.railsonmaui.com/blog/2014/03/11/rocking-with-tmux...

It means you can do screen splitting on a remote machine and still have the same workflow as your local sessions, which is pretty nice.

After using emacs a lot I've ended up preferring screen splitting.

I used to be happy just running multiple xterms, but I've been using Linux again recently and found myself a bit unhappy with that. I think due to advancing age I'm just finding it hard to cope with lots of windows. Keeping on top of them is a pain.

I tend to have terminator fullscreened (no decorations) on one desktop, and switch desktops far more often than I switch windows.

Gnome-terminal, rox-term, sakura and terminator are actually all based on the same terminal emulation backend: libvte

st is not about rewriting xterm.

it's about removing features, and then rewriting.

for example, it doesn't even have scroll back! ... which is the reason i don't care much for it.

I like roxterm, but I recently switched to xfce's terminal, which lets me load it without a menu bar, (I like having more vertical space).

More options are good.

hide_menubar=1 in roxterm config :)

Sorry that was unclear, I meant no menu bar and no drag bar with minimize and close buttons; my terminal window goes from the top of my screen to the bottom. I realize I can use a DE that lets me do that, but my preferred DE on linux atm is xfce itself. If there is a way to configure roxterm to not have a drag bar from inside the program, I have not found it.

I use the Xfce 4 Terminal on a i3 with no DE. Works wonderfully and has all the features I care for and need.

Same here. Very few dependencies.