[mikejmoffitt]

Interesting results. I have loved XTerm for a long time because it "felt snappy". On MacOS I've always preferred Terminal.app to the often recommended iTerm2 for similar reasons.

I think it's funny to have the suckless project page for st go on and on about how XTerm is clunky and old and unmaintainable, but the result of this small and clean minimalist terminal is a closer loser in terminal performance, which subconsciously and consciously detracts from the experience.

[geocar]

Sometimes it is easy to be faster than everyone else by simply having less code. Sometimes you need to think about how you can do as little as possible instead.

XTerm has the logic for handling partial screen updates and window obscuring other terminals don't bother with because it was written in an era that these weren't mere 10-50msec delays but 100+msec delays; Anyone who used dtterm on a sun IPX knows what I'm talking about

I'm also a Terminal.app user.

[sliken]

I'm amused to find that XTerm still include a Tektronix 4014 emulator.

[wmf]

OTOH Alacritty can supposedly redraw the entire terminal in 2 ms, so perhaps those tradeoffs have changed over the last few decades.

[steveklabnik]

An interesting side effect of Alacritty's choices:

> alacritty and terminal.app are fast enough that they’re actually limited by the speed of tmux.

[jwilm]

FWIW, We're working on adding native support for scrolling. Someone has actually made an attempt at it recently: https://github.com/jwilm/alacritty/pull/657

Initial testing has shown it not to (noticeably) impact perf in our highly unscientific benchmarks.

[steveklabnik]

Ah great!

I'm a native Windows user these days, so I can't use it quite yet, and as such, have fallen behind the time on news.

[buster]

That's awesome! No scrolling is what prevents me from using alacritty. Hope this gets merged!

[frou_dh]

> On MacOS I've always preferred Terminal.app to the often recommended iTerm2 for similar reasons.

When new Mac users ask for general app recommendations, they often seem to get immediately steered away from Terminal.app and into iTerm. I'd understand this phenomenon if T.app was horrible, but it's rather good!

(I have a theory about the long shadow of Internet Explorer causing the use of stock OS apps to subconsciously feel passè)

[masklinn]

That's ecosystem inertia: in the days of yore Terminal was pretty damn terrible, it only got tabs in 10.10 (Sierra) and xterm-256 in Mountain Lion (10.8), so people got into the habit of recommending iTerm 2 and then kept doing that even as Terminal became usable (though not necessarily great).

And iTerm still has feature edges e.g. truecolor, or better multiplexer support (Terminal only supports vertical pane splitting).

[cweagans]

> it only got tabs in 10.10 (Sierra)

I'm 90% sure that's not accurate. It's had tabs for quite a while.

[0942v8653]

Yes I distinctly remember using Terminal's tabs on snow leopard (10.6), confirmed by [0]. Also, I believe 256color was available in that release, though I'm less sure.

[0]: https://stackoverflow.com/questions/6736602/how-do-i-set-mac...

[wodenokoto]

Tabs is way older than Sierra. I started using the terminal about 5 years ago and have always used tabs.

[Analemma_]

> it only got tabs in 10.10 (Sierra)

I don't think that's true. I definitely had tabs in Lion (10.7) and I'm pretty sure they're at least as old as Leopard (10.5) and maybe older.

[Tenobrus]

iTerm2 also has Tmux integration: treat and control Tmux windows (and thus tabs) and panes as if they were native iTerm elements, and do so using the same keyboard shortcuts. Very very few other emulators do this (on any OS).

[Volt]

It got tabs in Leopard (10.5).

[ori_b]

> "st on macOS was running as an X client under XQuartz, which may explain its high tail latency."

[microcolonel]

I think the problem with st on these charts is related macOS and XQuartz. The Linux st numbers are competitive with everything except Terminal.app and eshell.

[Shugyousha]

Having st be simple does not necessarily make it fast. Sometimes there is also a tradeoff involved.

Here I don't really see what you mean since linux-st is the term-emulator with the lowest latency (only comparable to alacritty) so it looks like it's simple (though not that simple) and quite fast (on Linux).

[garbeam]

Suckless isn't focussing on macOS, as Apple software clearly isn't targeting expert users, but rather the mass market of noob users.

If you double check the plots, you will notice that "linux-st" isn't performing bad at all. The author also suspects XQuartz as one reason for the higher latency, which makes absolutely sense.

[gumby]

I've really wondered that too: why is everyone recommending iterm? I'm glad it's just a matter of taste -- I'm perfectly happy with Terminal (and running a shell inside Emacs in my terminal :-).

[lobster_johnson]

iTerm has support for tiling terminal panes within a single window. You can drag any tab to subdivide a pane as much as you like.

It's handy for keeping "tail" or "watch" commands or similar visible — the same reasons people use tmux, tiling window managers, so on.

The UX isn't perfect, but it's useful enough that I've stuck with iTerm despite the lower performance (and bugs — it's pretty buggy, and the main author rarely seems to address Gitlab issues).

iTerm has other nice features. It can run without a title bar (saves space), it does cmd-click-to-open-file, and it has a lot of customization options. I don't really use most of the features; the tiling aspect is the main feature I rely on.

[Dobbs]

I love terminal panes. I'm not sure at this point what comes out of the box and what is custom configuration but I have keybindings for creating vertical and horizontal splits, and additional keybindings for navigating left/right/up/down.

My setup is to run MacVim on the left half of the monitor and then iTerm2 on the right half. iTerm is then split into generally three horizontal splits.

[mattnewton]

I think it's because terminal.app has caught up a lot without noticable speed hits, and some % of those recommendations might be out of date.

[chuckdries]

I love the deep aesthetic customization options (though they're really non-essential)

I love the tmux integration, I used tmux before anyway and it's honestly not that different if you used tmux's built in mouse support but focus follows mouse in terminal panes is a nice touch.

Displaying images inline is alright I guess but I don't actually use it that much.

There's a bunch of stuff listed on their features page that sound useful but I don't actually use (yet). Idk I suppose I haven't noticed any appreciable difference in speed.

https://www.iterm2.com/features.html

[jasonmp85]

Good to see these replies here because I've always thought I was crazy. A new bump would come out, I'd try it again, and immediately feel it was too slow before going back to Terminal.app almost immediately.

[patrec]

It's a matter of taste in that both have features that the other doesn't have (terminal being faster being it's main, but significant one).

As far as I know, in terminal you can't use cmd as meta key, which immediately kills it for me as an emacs user (furthermore in iterm2 you can set it up so that left cmd = meta, right cmd = cmd, which I find very useful).

[gumby]

You sure can (I assume you meant opt), and have been able to since the NeXT days. There are many Emacs users at Apple (look at the Emacs key bindings in the text widgets)

[harrygeez]

For me it allows me to make my terminal minimal or dare I say, downright beautiful, which is something I definitely cannot say for any of the other terminal emulators out there, save for a few newcomer Electron-based abominations like Hyper.

screenshot: http://imgur.com/a/mFWYC

[jperkin]

For me it's a relatively trivial reason: my muscle memory has been trained over the years that cmd-[1-9] switches tabs, and there's no way to configure that in Terminal.app (last time I checked) without unstable SIMBL plugins.

[paddy_m]

I found terminal.app to be incredibly buggy on 10.12. I was experiencing more than one crash per day.

[gue5t]

This is going to sound mean however I say it, so I'm not going to sugar-coat it: that's how pretty much all suckless software works. Software becomes fast via profiling and optimization, not by ritualistically applying dubious notions of simplicity (C is simple? since when? UNIX is simple? since when?).

[garbeam]

As pointed out above, suckless isn't focussing on macOS/XQuartz users. The latency of "linux-st" isn't that bad according to the plots of the author.

In my view, simplicity often leads to better performance as a side effect -- but of course there are many exceptions.

Nevertheless, I wouldn't start optimising software unless the software is really unusable. Optimising software to look well in rare corner cases is not a good idea imho, if the price is adding a lot of complexity.

[wmf]

To be fair, suckless never claimed to care about performance.

[rodgerd]

"Slow and featureless" isd hardly an advertisement for good software.

[Occivink]

"Minimalist", "easy to understand" might be.

[michaelmrose]

Ironically a lot of suckless stuff kind of sucks. I don't know of any that are particularly worth using.

[michaelmrose]

Seems some at least disagree but don't mention what parts of suckless are worth mention. Anyone care to elaborate?