[HN Gopher] Contour: Modern and fast terminal emulator
___________________________________________________________________
Contour: Modern and fast terminal emulator
Author : ingve
Score : 164 points
Date : 2023-10-08 12:20 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| masto wrote:
| What's modal about it?
|
| I'm also in the "I've never wished my terminal were faster" camp.
| Certainly I've wished the things I run in it were faster, but
| that's a different story.
|
| I split my time between macOS and ChromeOS, and I find it easier
| to just stick to what's built in. The things that add friction to
| my development experience are not waiting for tty characters to
| draw, they are hopping around between the mess of tabs and
| windows between the browser, VS Code, and terminal sessions, all
| tied for a distant third; in second place, waiting for builds;
| and by far and away #1, trying to understand how this goddamn
| maze of abstraction and indirection and microservices and
| frameworks works so I can figure out where to actually put my
| code.
| maccard wrote:
| > I'm also in the "I've never wished my terminal were faster"
| camp.
|
| I have an application that I run daily that is noticeably
| (15-20%) faster if I redirect terminal output to a file, or if
| I use a non-default terminal emulator. In this day and age, not
| being able to keep up with drawing 80 x 24 even with unicode is
| just not acceptable.
| mistercow wrote:
| > I'm also in the "I've never wished my terminal were faster"
| camp.
|
| In the long long ago, I remember having to limit my terminal
| scrollback to avoid things getting laggy. That hasn't been the
| case for a long time, because terminals started taking
| performance seriously.
|
| So I think advertising speed is more of a table stakes
| situation than a competitive advantage. I want to see that a
| new terminal emulator is thinking about speed because if
| they're not, I can probably rule them out as an option
| immediately.
| mk12 wrote:
| There are lots of terminal projects recently. Ghostty
| (https://mitchellh.com/ghostty) and Terminal Click
| (https://terminal.click) come to mind. Also Warp and Fig but they
| don't appeal to me because they're proprietary (and Fig got
| acquired by Amazon). I've been very happy with kitty
| (https://sw.kovidgoyal.net/kitty/) for years and it would take a
| lot to make me switch.
| mongol wrote:
| Both Ghostty and Terminal Click developed with zig, it
| seeems...
| angra_mainyu wrote:
| My favorite is alacritty, although kitty is a close second, not
| a big fan of how kitty handles fonts/colors compared to
| alacritty.
| KolenCh wrote:
| I've used kitty for quite a while but it has subtle problems
| with tmux that I use all the time (one of the primary reason is
| persistent session).
|
| From the FAQ https://sw.kovidgoyal.net/kitty/faq/ and other
| GitHub issues, it seems the recommendation is not to use tmux.
| Since I need to use tmux, I then change the terminal emulator I
| use instead.
| hiAndrewQuinn wrote:
| What kinds of problems? I've used tmux with kitty plenty and
| never noticed anything, but that's probably because I just
| didn't care to look.
| KolenCh wrote:
| The one I encountered is color problem. I can never get
| xterm-256color works reliably and has to use
| screen-256color which supports lesser features such as
| italic.
|
| Running btop within tmux using kitty also has color
| problems, but Alacritty also fails at that.
| dmos62 wrote:
| Colors in terminals are tough. There's the terminal, then
| the shell, then tmux, then vim, and you want all of their
| configs in concert even when you're switching between
| light and dark one or twice a day. Colors are tough in
| general. Even the browser color story kind of sucks. Dark
| reader goes a long way, but not enough
| KolenCh wrote:
| Right, I sort of understand that (not the details). I'm
| sympathetic to the kitty author, who explains why other
| terminals and tmux are doing things wrong, etc.
|
| I guess it is especially messy in the terminal, reading a
| little bit into the issues and it just feels like a ton
| of legacy hacks between different implementations.
|
| And comparing that to the browser is interesting. Both
| are "ubiquitous"--terminal emulator for cli/TUI, and
| browser for GUI. May be because of there generality /
| ubiquity, it is messy and impossible to "make it right".
| mfontani wrote:
| I had a long battle with making kitty work with tmux. I
| settled on the following in ~/.tmux.conf, before moving
| to wezterm for good. Maybe it fixes things for you, too:
| set -g default-terminal xterm-256color set-option
| -sa terminal-overrides ',xterm-kitty:RGB' set-
| option -ga terminal-overrides ",xterm*:Tc:smcup@:rmcup@"
| set-option -ga terminal-overrides
| ",screen*:Tc:smcup@:rmcup@" set-option -ga
| terminal-overrides ",tmux*:Tc:smcup@:rmcup@"
|
| I honestly don't know whether all are needed, or only
| some. But with these, it worked well for me.
| KolenCh wrote:
| I tried the first line and in some situations
| (specifically with some remotes, i.e. kitty -> ssh ->
| tmux with that 1st line) it still won't fix it.
|
| I gave up kitty because the author obviously don't like
| tmux and is advising users not to use it. So it is more
| like a choice between kitty and tmux. Giving up kitty is
| easier for me in terms of features and time for
| retraining.
|
| What's your reason to migrate from kitty to wezterm?
| mfontani wrote:
| > What's your reason to migrate from kitty to wezterm?
|
| My reason to no longer using kitty is simple: I don't
| like _having to_ copy kitty 's terminfo data to every
| single system I connect to in order to have my terminal
| work.
|
| It's fine for those few systems I very often connect to,
| of course.
|
| But I also connect to ephemeral systems, sometimes for a
| short session, and the toil and friction inherent in
| having to do that just isn't worth it.
|
| Sure, "kitty +kitten ssh ..." can work in most people's
| scenarios. Didn't quite work in mine, due to various
| intricacies about my ssh setup - multiple ssh keys,
| handled mostly by ssh-ident.
|
| wezterm Just Worked for me. As I got "back" to also using
| other systems like Windows and MacOS, it Just Worked
| there, too. No fiddling with terminfo, no fiddling with
| $TERM, either.
|
| Happy days.
| KolenCh wrote:
| Your reasoning resonates with mine very much. I'll look
| at wezterm soon and hope it will works for me too.
| mfontani wrote:
| > I tried the first line and in some situations
| (specifically with some remotes, i.e. kitty -> ssh ->
| tmux with that 1st line) it still won't fix it.
|
| You likely need all of them ;-)
|
| IIRC it "fixes" terminfo stuff "within tmux" for kitty
| regardless of what $TERM is set. Mind you, I was using
| the latest tmux at that time. tmux 3.2?
|
| Here's the issue I had:
| https://github.com/kovidgoyal/kitty/issues/3018
|
| Looks like it should be fixed on a very recent tmux;
| otherwise this MIGHT help: set-option
| -as terminal-features ',xterm-kitty:RGB'
|
| ... or not.
| KolenCh wrote:
| I tried your solution using one remote server that I had
| trouble with before and it works! That's really great.
| This probably solves enough problems with kitty for me
| that I can use it until I find a better solution. (I am
| using Alacritty at the moment but it has other problems
| so that I have to use kitty as fall back for some
| situations.)
|
| Thanks!
| diath wrote:
| Seconding kitty, a while ago I tried like a dozen of different
| terminal emulators and tested a lot of features including link
| clicking, escape code rendering, Unicode rendering and so on,
| and only kitty and Sakura have passed most of my requirements,
| with Sakura having one issue that I cannot recall that
| ultimately made me choose kitty. Built-in window splitting
| without tmux is also great. The only downside is that when you
| SSH into a remote machine without kitty's terminfo installed,
| you can't even use backspace or other common keys, which is
| annoying.
| snapplebobapple wrote:
| I went wezterm because kitty wasnt always playing nice with
| tmux and i dont think i would go back at this point there is
| something i juat like more about wezterm i cant put my finger
| on.
| eviks wrote:
| Thanks for the links! Click is cool&bold in that it tries to
| get rid of all the obsolete baggage, pity it's in C, though
| danielvaughn wrote:
| I wasn't crazy about the proprietary nature of Warp, but I
| tried it and was sold almost immediately. I can use the same
| modifier-key commands to select and manipulate text that I'm
| used to, which feels super nice. They also provide such good
| sessionization out of the box that I don't really feel the need
| to install tmux or anything like that.
| lobsterslive wrote:
| The problem is that Warp is closed source, requires a log in,
| has extensive telemetry, promised to go open source but never
| did and has raised 78M from VCs including 50M from Sequoia,
| the FTX people.
| satvikpendem wrote:
| Indeed, VCs will want a return on their investment at some
| point, and it doesn't seem like simply sharing some
| terminal commands in the cloud with your team will be
| enough to justify that valuation. This is especially true
| as the Zero Interest Rate Phenomenon of the last 15 years
| is now over.
|
| Personally I'd never use something VC backed for something
| so critical to my productivity.
| alchemist1e9 wrote:
| Having never heard of Warp and wondering what would get
| VCs to give that much to a terminal project I just took
| look at their website and it's obviously the AI/LLM
| aspect.
|
| With that said does anyone know which open source
| projects are looking at LLM integration. It's not a bad
| idea.
| jrm4 wrote:
| It's not at all a bad idea as something like "optional
| plugin," but it's _definitely absolutely_ a bad idea if
| we 're also mentioning VC's.
| satvikpendem wrote:
| I took a look before this year and it used to be that
| their value proposition was more so geared towards
| sharing terminal inputs and outputs easily. Now they seem
| to be leveraging OpenAI APIs instead as their main value
| prop.
|
| However, I still don't really see why someone would pay
| 12 bucks a month for that when they could just pay a
| little bit more for full blown ChatGPT and use AI for
| much more than terminal commands (and there are already
| terminal and vim plugins to directly query GPT with your
| API key, which is orders of magnitudes cheaper than
| Warp). It seems like a product that has no clear target
| market or target usage, seems more like a feature than a
| full product.
| andrepd wrote:
| Having an LLM run terminal prompts sounds like a recipe
| for disaster
| alchemist1e9 wrote:
| It's more about sophisticated replacement for tab
| completion.
| satvikpendem wrote:
| I can just run Llama locally for that, no VC required
| (and indeed there are plugins which do exactly this
| already). Llama and other local LLMs are being optimized
| to run on the CPU on less than 1 GB of RAM so it's not as
| if only those with beefy GPUs can do so.
| alchemist1e9 wrote:
| Agreed and the part I'm missing is these plugins which do
| this. Any suggestions or recommendations would be
| interesting to hear. Which terminals and which plugins
| etc.
| danielvaughn wrote:
| Thankfully it doesn't run it, it just inserts the
| commands into your prompt. It's kinda nice but I've also
| been using the terminal for like 12 years, so I don't
| find myself relying on it very often.
| mananaysiempre wrote:
| > I can use the same modifier-key commands to select and
| manipulate text that I'm used to, which feels super nice.
|
| I know this is not a complete solution, but just in case you
| weren't aware, the keybindings in GNU Readline are nearly
| entirely configurable[1]. Getting some of the keybindings to
| work could require digging into serial terminal arcana[2],
| unfortunately, but here a terminal emulator that supports
| either the Kitty keyboard protocol[3] or the (venerable if
| impressively badly documented) modifyOtherKeys feature[4]
| could make things easier (messing with the serial driver[2]
| seems an overreaction to me, and you can't get acceptable
| Ctrl-C behaviour that way anyway). The "new" terminal
| emulators mentioned in this thread (alacritty, contour,
| kitty, wezterm) should be able to do the trick, and of course
| xterm as well (probably rxvt too?); tmux compat needs help,
| though[5].
|
| [1] https://tiswww.cwru.edu/php/chet/readline/rluserman.html#
| Bin...
|
| [2] https://susam.net/blog/from-xon-xoff-to-forward-
| incremental-...
|
| [3] https://sw.kovidgoyal.net/kitty/keyboard-protocol/
|
| [4] https://invisible-island.net/xterm/modified-keys.html
|
| [5] https://github.com/tmux/tmux/issues/3335
| Razengan wrote:
| I tried to try Warp, out of curiosity, and.... Are they fn
| kidding? A terminal that requires sign-up???
|
| What in the actual hell.
|
| Oh my god Fig too! Which of you is encouraging this crap??
| alwillis wrote:
| I had the same reaction to having to sign-up to use a
| terminal?
|
| I was this has gone too far--hell no.
|
| Been a happy WezTerm for the past year or so.
| hn92726819 wrote:
| Is Kitty's startup time (~200ms) not unbearable for other
| people? Is it faster now or do people not spawn new terminals
| constantly?
| lytedev wrote:
| I open new tabs or panes in my single terminal window,
| personally FWIW.
| vluft wrote:
| you can run it with `--single-instance` (or `-1`) and you
| only pay (most of) that startup cost once.
| ljm wrote:
| Kitty's my daily driver on Mac (when I'm not using eshell,
| anyway), but on the Windows side I am actually pretty damn
| impressed with Windows Terminal over WSL2. I don't even bother
| using graphical mode on emacs in WT/WSL, it is smooth as butter
| and super responsive in terminal mode and aside from using
| Linux, I'm actually preferring it as a dev environment to a Mac
| these days.
|
| In fact, it feels like there's an ever-so-slight latency when
| on a Mac that Windows doesn't have. At first I put it down to
| the keyboard feel, but even using the same keeb it feels a bit
| more 'squishy' on the Mac.
| bitvoid wrote:
| I really like Windows Terminal too. The one issue I have is
| that I have Ubuntu as the default session and when I open the
| terminal from the start menu (i.e., hit command key, type
| "terminal", and hit enter), it opens but loses focus. The
| only way to remedy it is to disable WSLg (GUI support). It's
| a long standing bug and a weird one at that.
| [deleted]
| ljm wrote:
| Yeah, that and sometimes the WSL session takes forever to
| boot up (a good 10+ seconds for the first time, for me).
|
| Once it's working it's fantastic. I don't know what it is
| with MacOS, unless they're subtly animating keypresses or
| something. Linux is as responsive as Windows is too. It's a
| wired keyboard so nothing to do with bluetooth.
| camdv wrote:
| I think that's the initial boot of the VM. I'v noticed it
| too.
| grudg3 wrote:
| Correct. If you run `wsl --shutdown` as an admin then
| start up Windows Terminal again the delay is back the
| first run.
| mardifoufs wrote:
| I love Terminal but I can't get glances working on it
| correctly :(.
|
| (I know, the task manager is good enough usually but not for
| having an overall view of everything, and not really for GPU
| usage. )
| eej71 wrote:
| Also, Microsoft has their own new terminal program.
|
| https://github.com/microsoft/terminal
| rob74 wrote:
| I switched to wezterm (https://wezfurlong.org/wezterm/) a few
| months ago and I'm pretty pleased with it (especially the
| search function, which is something not many terminals
| support), although it still has some rough edges.
| SadTrombone wrote:
| Huge WezTerm fan, the dev is very friendly and responsive on
| GitHub as well.
| alwillis wrote:
| +1 for WezTerm.
|
| Switched from iTerm 2 like a year ago.
| [deleted]
| Conscat wrote:
| https://github.com/contour-terminal/contour/issues/382
|
| This apparently does not support the Kitty graphics protocol,
| just Sixel, which makes it look fairly unattractive to me,
| personally.
| malablaster wrote:
| I don't see the point of pitching "fast" as its first selling
| point. Are people frustrated by the latency of the incumbents?
| user3939382 wrote:
| I've never been able to perceive the difference. I use iTerm2
| and I can't perceive how it could be faster.
| vidarh wrote:
| Most of the time people only notice the slowness if they are
| in the habit of regularly letting huge amounts of output
| stream to the terminal, so it really depends on _how_ you use
| your terminal. I agree with you - for me terminal speed was a
| solved issue in mid 1980 's, and has not been an issue since.
| [deleted]
| ur-whale wrote:
| > Are people frustrated by the latency of the incumbents
|
| Yes. If you write code in vim as I do, terminal latency
| (snappiness) is very important. s a matter of fact, that's the
| main reason I paid attention to this project.
| sodapopcan wrote:
| Ya, there was a very noticeable VImprovement (lol, sorry)
| switching from iTerm to Alacritty. I'd never heard of this
| project before, looks really interesting.
| kergonath wrote:
| Short answer: yes.
|
| Longer answer, there are diminishing returns, but speed
| definitely is a selling point. A terminal being slow is not
| necessarily something you notice straight away (if the software
| is competent in the first place; a lot of them are not).
| However, testing a new one with a lower latency and fewer
| buffering issues is when you feel it, and then it is difficult
| to go back.
| ghusbands wrote:
| Yes. It's common on at least Microsoft terminals to be waiting
| for the terminal to finish displaying the output it has been
| sent. I expect that it will be the same for many older terminal
| emulators.
| vidarh wrote:
| Most older terminal emulators tends to do fairly well. E.g.
| on Linux, rxvt tends to be one of the fastest. Many older
| terminals tends to do well not least because many older
| terminals implements jump-scrolling properly (scroll multiple
| lines at a time before updating the screen if the rendering
| doesn't keep up) because there are even escape codes to turn
| that on/off.
|
| There's a weird "bathtub curve" when it comes to terminal
| speed where the oldest tends to be well optimised in terms of
| tricks to _minimise rendering_ , the newest all tend to
| concern themselves very much with rendering smart, but often
| miss the old-school tricks, and quite a few of the ones in
| the middle are just really naive about everything.
| ku1ik wrote:
| Spot on!
| hoherd wrote:
| After using iTerm2 as my daily driver for like a decade, and
| then trying out some of these other "fast" terminal emulators,
| I was amazed at how slow the experience in iTerm2 is. I even
| kept alacritty around as a second terminal for a while for
| cases when not having iTerm2 features wasn't a deal breaker,
| but eventually I just went back to iTerm2. I am still aware of
| how slow it is, and although I tolerate it, I wish it were as
| fast as some of the others.
|
| You can see the speed difference with your eyes by joining a
| tmux session from different terminal emulators and doing
| operations that redraw the whole terminal, such as searching in
| a less pipe.
| kergonath wrote:
| > eventually I just went back to iTerm2. I am still aware of
| how slow it is, and although I tolerate it, I wish it were as
| fast as some of the others
|
| Indeed. It still has the best feature set of all the terminal
| emulators I tried, though, and I wish it worked on Linux.
| vlovich123 wrote:
| I find Konsole very featureful and fast...
| greymalik wrote:
| I see...
| anta40 wrote:
| These days, I mostly use WezTerm on MacOS. And ocassionaly
| iTerm2.
|
| iTerm2 is slow? Man I guess I'm not a heavy command line
| user. I mosty open 5 or 6 tabs. tmux? Very very rarely.
| Macha wrote:
| The slowness is noticeable often enough in simple typing
| latency, but there's definitely a spectrum as to how much
| people notice or find it frustrating. On the one end
| there's the people that won't use anything but xterm, while
| on the other there's people who don't care about the
| seconds of latency for some remote development setups.
| gusfoo wrote:
| > Are people frustrated by the latency of the incumbents?
|
| Not me, no. And I'm not even frustrated by pretty much
| anything. I have some Cygwin SSH sessions on the go and I'm
| running 'screen' in those terminals. It works and has done
| since the '90s.
| kristopolous wrote:
| Seems to be a windows/mac problem. In Linux I've never really
| been bothered by it in at least 20 years
| tssva wrote:
| The speed of Gnome Terminal and Konsole on Linux along with
| Microsoft Terminal on Windows didn't bother me until I tried
| a couple of the newer faster terminals. Now all 3 seem slow
| to me.
| cpach wrote:
| It's not a Windows/Mac thing. There are definitely slow
| terminal emulators for Linux as well. I'm quite sure you
| wouldn't want xterm as your daily driver.
| kristopolous wrote:
| I use exactly that. It's fine for me and I'm very much a
| terminal first person.
|
| Maybe people have extremely fancy shell setups? Perhaps
| it's a font thing that slows it down? Can you demonstrate?
|
| I'm usual a tmux/zsh/vim user (although I've promised to
| switch to emacs for years :( )
|
| I just timed my xterm. I'm displaying about 2.3MB/s of
| characters.
|
| Basically here was my test $ dd
| if=/dev/urandom bs=10M count=1 | hexdump -C > /tmp/test
| $ ls -l /tmp/test -rw-r--r-- 1 chris chris 51773449
| Oct 8 09:32 /tmp/test $ time cat /tmp/test
| ... wait wait wait .... 51773449 / (total
| time) / (2^20)
|
| Now this of course depends on the size of the window. I'm
| on a 4320x3840 dual 4k monitor and the window geometry was
| 1334x928 for this test.
|
| I acknowledge this computer (i7-8650U ~ 2018 thinkpad with
| a boring UHD Graphics 620) is capable of faster output but
| the xterm featureset is _vaaassstt_ (albeit extremely
| complicated) and I 've found the other terminals to be
| lacking.
|
| My only faithless move away from xterm was probably 17 or
| so years ago with rxvt when I was on a laptop with ballpark
| 16MB of memory. It's memory footprint and startup time was
| way smaller probably for its total lack of features and
| unicode support. That made a difference on my Toshiba
| Protege 120mhz pentium I was using at the time.
|
| When I was a macOS and a Windows developer, slow terminals
| were definitely a problem though
| slotrans wrote:
| 2MB/s is _glacial_. Your computer is very fast, it should
| be able to print over 1GB /s without breaking a sweat.
|
| Casey Muratori demonstrated this with his refterm
| project. It seems like a lot of interest in making fast
| terminals has followed from that.
| kristopolous wrote:
| Why do I care? I can't read things that fast
|
| This isn't rhetorical. I can't answer the question
| SoftTalker wrote:
| I use xterm. Seems fine. Not sure what I'm missing I guess
| but I get my work done.
| cobbal wrote:
| Latency doesn't bother me too much, but throughput can really
| matter if I'm running a particularly verbose command. Often
| program speed is limited by how fast the terminal is able to
| clear the stdout pipe. This is especially true when running
| commands inside emacs "build" window (which is running who-
| knows-how-many regexs). If it's more than ~10,000 lines long
| then an instant command can be slowed down to more than 10
| seconds.
| IshKebab wrote:
| On Windows, yes. Not on Mac or Linux though.
| IshKebab wrote:
| It would be nice if someone worked on actually improving the
| terminal experience. Selecting, copying and pasting text is still
| pretty awful (why is the cursor an entire block rather than a I
| bar?). Editing multiline inputs is awful. Navigating history is
| so-so (even with McFly etc.). Anything more complicated than
| left/right/up/down fails half the time and dumps control
| characters instead.
|
| Why are terminals always stuck in the 70s? Can I get a modern
| terminal?
| paradox460 wrote:
| Fwiw, iTerm2 has a "copy mode" which lets you navigate around
| and yank the visible terminal and scrollback with vim bindings
| indymike wrote:
| > Editing multiline inputs is awful.
|
| Outside of "line at a time" i/o (a rarely used mode where an
| entire line is edited locally and then sent to the host), most
| of what users see is as interactive is controlled by the
| program you are interacting with. The terminal just takes
| commands from the host and does what it is told. BTW, line at a
| time mode isn't used that much. The only thing I use that uses
| line at a time mode is telenet in LINEMODE.
|
| > Navigating history is so-so
|
| Yes, that is because the program you are likely interacting
| with where history is relevant implements it's own repl or
| command line (i.e. bash, zsh, python, etc...) and it is
| responsible for it's own history and may implement it
| completely differently than say, bash or zsh.
|
| > Why are terminals always stuck in the 70s? Can I get a modern
| terminal?
|
| We do have a modern terminal: the web browser... and it's
| pretty nice.
|
| There have been a ton of tries at more modern terminals, but
| ultimately, they end up really being limited by the software
| running in the terminal session. In the 90s we had a ton of
| commercial terminal emulators that would allow you to create
| full guis, complete with dialogs and forms. In the 00's there
| were a few tries at terminals that would allow html output and
| embedding of html forms for input (can't remember the names of
| them). I suppose there's also the whole X11 thing... which is
| so good enough that it's really hard to kill.
|
| Let's get back to character mode:
|
| A lot of interactive terminal software is built using different
| libraries - so sometimes you get a terminal gui based on
| ncurses, terminal.gui, or something else... here's a list:
| https://github.com/rothgar/awesome-tuis#libraries. Most of
| these libraries try to use most of the features in your
| terminal emulator, but often, just use stuff that is in
| everything.
|
| For command line programs (i.e. just type a command), a lot of
| the experience is dictated by the parser used by the tool and
| whatever the underlying operating system has for passing
| arguments. Some shells and terminal emulators (like iTerm2 on
| mac) try to smooth this out, but again, there's a lot of
| variety in command line parsers.
|
| Probably the biggest modern improvement in the shell world was
| gettext and various command-line completion libraries which
| allows command parameter completion if the developer supports
| it or uses a parser that supports completion. But none of this
| is the terminal itself doing the work.
| Macha wrote:
| There are better experiences (e.g. my shell has vi mode which
| is much nicer for editing multi-line inputs, I'm sure if I
| could be bothered to learn emacs/readline shortcuts that'd be
| another set) but they're not easily discoverable and a bit
| unevenly distributed.
| muhammadusman wrote:
| Once in awhile I'll try these new emulators but I keep going back
| to iTerm2. Maybe having a comparison of the two or similar would
| help convince me and others in the same boat.
| AceJohnny2 wrote:
| Does it support `tmux -CC` ?
|
| Sorry for being _that HN commenter_ but, if not, I 'm bored with
| yet another terminal that just equates established features.
|
| iTerm's killer feature is `tmux -CC` support, so that tmux's
| sessions are integrated natively. I find it shocking that, years
| after tmux established this feature, iTerm remains the only
| terminal emulator to use it.
| felixding wrote:
| Tmux control mode is one of the keys reasons I can't leave Mac.
| I also feel it's unbelievable that iTerm 2 is still the only
| terminal that supports this feature.
|
| For anyone who is asking why this feature is good: it's really
| not that easy to see the benefits from the documentation, blog
| or even videos, until you personally try it. At least that's
| the case for me.
| iamjackg wrote:
| I worked on a pull request to implement it in Terminator a
| long time ago, but eventually gave up. Control mode was
| contributed to tmux by the author of iTerm2, and if you
| explore the iTerm2 codebase you can definitely see that
| they're very tied together in terms of implementation choices
| and general design. It's not that simple.
|
| In order to have two-way synchronization, your terminal needs
| to not only have an architecture where you can add a
| background thread that can control the "main" terminal
| interface, but also be flexible enough to properly size all
| windows and panes, and match font sizing. If your terminal
| supports different font sizes for every pane/split, those
| have to be turned off in tmux mode. There's all kinds of
| corner cases.
| riddley wrote:
| I read the Control Mode section of the man page, but the
| utility didn't leap off the page. Would you share what's cool
| about this mode?
| lanza wrote:
| sshing into a server only happens within one shell. Thus you
| can open tmux there and that's the only level of granularity
| you can have.
|
| iterm window->iterm tab->ssh->tmux windows->tmux panes
|
| With `tmux -CC` it lets you hoist that chain upwards and map
| the entire ssh session into an iterm window.
|
| iterm window (ssh session) -> iterm tabs (tmux windows)
|
| The biggest benefit for me is that you can then open another
| tmux session within the CC one and use tmux as normal
|
| iterm window (ssh session) -> iterm tabs (tmux windows) ->
| tmux2 windows -> tmux2 panes
|
| And then the normal feature of tmux is that it persists
| across ssh sessions. This also means that the entire iTerm2
| window and all its tabs and splits are also maintained across
| sessions. I think my current layout on my main development
| machine that I remote into is over 3 months old.
|
| Another point of view is that it decouples the state of your
| tmux tabs/panes from your terminal emulator itself. e.g. if
| you use this locally instead you could then terminate the
| entire iterm program and reopen it and restore the same exact
| window/tab/pane splits you previously had. This is a nice
| perk for restarting/updating iTerm.
| jordemort wrote:
| > f you use this locally instead you could then terminate
| the entire iterm program and reopen it and restore the same
| exact window/tab/pane splits you previously had. This is a
| nice perk for restarting/updating iTerm.
|
| iTerm seems to be able to pull this off itself during
| upgrades, even without tmux. The first time it happened, I
| was surprised, and now I just install iTerm updates with
| abandon, knowing that all my 40 terminal windows and all
| the stuff in them will come back after the update.
| riddley wrote:
| I appreciate your explanation, but I'll confess that I
| still don't get it. I assume I'm just not understanding;
| please don't take offense.
|
| The state of my splits etc are already distinct from the
| terminal emulator as is/are the session(s) without CC. I
| can restart my terminal emulator or add new sessions at
| will without needing any special support from the terminal.
| AceJohnny2 wrote:
| First, some background: Tmux is great but (like GNU Screen)
| introduces a layer of abstraction between you and the shell.
| You have to use its special keybindings to create new
| windows, switch window/pane, or most annoyingly _to scroll
| through history_.
|
| Control Mode removes that layer of abstraction, so (with
| iTerm) you can use all the normal terminal emulator functions
| to do what you expect: click on panes to select them, tmux
| windows are just native tabs, _and you can scroll the
| terminal natively_
|
| In effect, all the UI compromises you had to do to make use
| of tmux... go away.
|
| It's a _huge_ benefit, because it means all the friction of
| using tmux disappears. Instead of thinking "do i really want
| to deal with tmux's UX for this quick ssh session?" (it's
| never as quick as you think) I just do it. All my terminal
| sessions are now in tmux. If I'm doing something on a remote
| machine, i can confidently close my laptop and know i can
| restore later.
| shmichael wrote:
| the iterm mode allows one to create, split, resize remote
| terminals as of they were native terminal windows, instead of
| all of them being contained within one terminal window and
| controlled using completely different keyboard-only shortcuts
| (via tmux)
| singwhenurdown wrote:
| does this make it faster? or is it used for the native feel
| drbaba wrote:
| Mainly the native feel. For example, you can use standard
| Cmd-based keybindings to control tabs and panes, and get
| smooth mouse scrolling in each pane.
| throwaway290 wrote:
| How is it useful? I could never understand why I would want
| something like that as opposed to just using Tmux splits &
| terminal emulator windows. And this is the only selling point
| of iTerm! Everything else is strictly worse (lag, CPU/memory
| usage) compared to plenty of emulators.
| ur-whale wrote:
| > contour ... actually fast
|
| and yet, borderline impossible to install without using flatpak
|
| So which is it ? fast or needs flatpak ?
| diath wrote:
| How come? It doesn't seem to have any dependencies that you
| wouldn't be able to get, they're pretty common.
| worksonmine wrote:
| > So which is it ? fast or needs flatpak?
|
| Are they mutually exclusive?
|
| If you don't like flatpaks it seems to be available on the AUR,
| fedora or homebrew if you're using mac. Debian repositories are
| always lagging behind for new stuff so that's no surprise but
| the dev provides a script for installing dependencies on the
| rest of the distributions somewhat customized to your flavor if
| you're willing to build from source. There is a debian
| directory so it seems like they started the process of getting
| included but you'll have to verify in the mailing-lists to see
| what the current status is.
|
| I'd say that's plenty of options to choose from. The simplest
| being flatpak. Are you a package maintainer yourself? Do you
| know how much work is involved to get into the main
| repositories? This is not npm.
| yjftsjthsd-h wrote:
| Wait, does flatpak have a runtime performance penalty?
| doubled112 wrote:
| If I can run Steam and play games packaged with Flatpak,
| hopefully my machines can handle a terminal emulator too.
| ur-whale wrote:
| With games, you don't have startup time issues. Not so for
| something as ubiquitous as a terminal emulator.
| doubled112 wrote:
| Do people have startup time issues with Flatpaks?
|
| I can't say I've ever noticed a difference, but
| everything I use has an NVMe. Perhaps it matters.
| JCWasmx86 wrote:
| It's easy to install on ArchLinux and Fedora. The build process
| seems to be just standard CMake, so calling it "borderline
| impossible" is really a stretch.
| ftyers wrote:
| Does it support Arabic/Devanagari and not do crazy things with
| BiDi? If so I'm sold!
| slim wrote:
| do you think mlterm is slow?
| ftyers wrote:
| I've not used it, is it good?
| kps wrote:
| Not that commenter, but I also use mlterm and have for
| years, even though I don't normally use BIDI or other
| 'exotic' language capabilities. It is _just_ a terminal, in
| the do-one-thing-well sense. Its downside is its somewhat
| idiosyncratic configuration (although there is now a GUI
| for most of it, so newer users might not notice).
| mgaunard wrote:
| I use terminator because it's reasonably lightweight (despite
| being written in python) and has good tab and split screen
| support.
|
| I'm not interested in tmux since I work on my computer directly.
|
| Is there anything with a comparable feature set that's faster?
|
| I couldn't care less about Mac or Windows support.
| abnry wrote:
| The GUI style choices turn me off to terminator. Silly reason.
| Maybe I should look at changing defaults.
| whalesalad wrote:
| Tmux is great even for local dev. I use it locally and
| remotely.
|
| You might like to try kitty.
| snapplebobapple wrote:
| Keep am eye on zellij, its almost there for me for making me
| gice up my tmux that i put a lot of work getting just right
| mhitza wrote:
| I've been using terminator as well for who knows how many years
| at this point, and aside from the startup I don't percieve it
| as slow.
|
| What, or in which circumstances exactly do you feel your
| terminal emulator is slow and would need to be faster?
| Tempest1981 wrote:
| How do I check if my older CPU has AES-NI?
|
| > Requirements: CPU: x86-64 AMD or Intel with AES-NI instruction
| set or ARMv8 with crypto extensions.
|
| Edit: maybe
| https://en.wikipedia.org/wiki/AES_instruction_set#Intel
| SushiHippie wrote:
| The lscpu command will you show you. IIUC you need to have
| "aes" under the flags entry.
| blueflow wrote:
| Prerequisites: ./scripts/install-deps.sh
|
| Please don't do this! List your dependencies normally. Packaging
| OSS projects is difficult enough already.
| jraph wrote:
| I don't know. If the script is legible, that's an executable
| (and therefore probably tested), exact documentation.
|
| edit: yep, I just took a look and can confirm, it takes a few
| seconds to get the list of dependencies for several
| distributions. It's way better than most readmes.
| tupolef wrote:
| I just tried it and I will keep an eye on it for later. Currently
| it is a work in progress and there is a lot of issues with the
| dependencies and compatibility with legacy setups, but it is way
| better than Warp and other GPU terminals that I tried.
|
| I am currently a happy user of Urxvt and intend to continue until
| I am forced to switch to wayland (in a long time, I hope). In
| comparaison I have to add that the rendering in more defined in
| Urxvt that Contour even after tinkering, and like always it uses
| at least 5 times less memory.
| MightyBuzzard wrote:
| [dead]
| Stem0037 wrote:
| I remember the days when I had to juggle between different
| emulators just to get a fraction of these features...
| cout wrote:
| I am always pleased to see code that is reasonably clean and uses
| modern C++.
|
| Sixel support is also nice to see. For all its faults, I think
| it's the only pixel graphics extension that currently has a
| chance of widespread adoption.
|
| I am curious if the authors have made any attempts to quantify
| "fast". Are there any benchmarks? In particular, I would love to
| see some input latency comparisons.
| akdkfe223 wrote:
| Does anybody know if it's actually fast in terms of low latency?
| I personally don't care about GPU acceleration or any of those
| things that Alacritty and others claim makes them fast when the
| latency is noticeably worse than older non accelerated emulators.
| angra_mainyu wrote:
| the latency is excellent, I immediately noticed a huge
| difference, particularly when seeing the output of long
| commands (e.g: tail -f)
| sprash wrote:
| If latency is your biggest concern you have to use a terminal
| emulator without double buffering. So far xterm and mlterm are
| popular choices.
| cmrdporcupine wrote:
| Looks nice, but seeming lack of tabs support
| (https://github.com/contour-terminal/contour/issues/90) makes it
| a hard sell for me.
| tmtvl wrote:
| I like that they reference the VT510 manual, if the terminal
| implements the more advanced control codes then individual
| applications can do their work without needing to rely on their
| own implementations of the needed functionality. I'm gonna give
| Vttest a whirl in Contour and if it does well I'll try daily
| driving it for a while.
| kelsey9876543 wrote:
| i don't see the point of adding vi input mode to the emulator
| when we have it inside bash with `set -o vi`
| drbaba wrote:
| Many interpreters don't use Readline (e.g. IPython and Zsh),
| and enabling inconsistent Vi keybinsings in each one can be a
| bit annoying. From that perspective, adding it to the terminal
| seems a possibly easier way to get it "everywhere"?
| williadc wrote:
| IPython absolutely uses readline
| drbaba wrote:
| Not anymore. Since IPython v5 (5+ years ago?), readline was
| replaced with prompt_toolkit.
|
| EDIT: Here's an official source: https://ipython.readthedoc
| s.io/en/stable/whatsnew/version5.h...
| mhitza wrote:
| Possibly more universal, but there are also tools like rlwrap
| [1] that adds readline support to programs that don't have
| it. From the docs apparently the readline library ships a
| similar tool ootb nowadays but I haven't tried that and just
| noticed now when I wanted to share the rlwrap link.
|
| [1] https://github.com/hanslub42/rlwrap
| Gualdrapo wrote:
| As it supports Windows, I guess it would be useful for them
| kelsey9876543 wrote:
| bash runs on windows
| akdkfe223 wrote:
| Feels a little bit misleading to say that honestly. It runs
| on windows in what is effectively a chroot/jail/container
| esque monstrosity. I personally consider that to qualify as
| a totally separate userspace and therefore not the same
| operating system as one would assume when you use the term
| windows without any additional qualifiers.
| miloignis wrote:
| Are you referring to WSL/2? The msys2 / Git Bash
| integration is more integrated with Windows then how I
| interpret your description.
| fefe23 wrote:
| I would love it if it became standard practice for projects to
| list their dependencies.
|
| I was going to try this but it wanted to pull in Catch2 (some
| unit testing framework) and apparently has a dependency on Qt.
|
| It is good and nice if your project has unit tests, and by all
| means use a framework if you think you need one. But don't make
| me install your framework just so I can do a standard release
| build. Only require it for building and performing the unit
| tests.
|
| If the home page mentioned the Qt dependency, I wouldn't have
| downloaded the source code.
| amitizle wrote:
| I'm not trying to annoy, I swear. I am using Alacritty for a few
| years. With tmux config that is moving with me for +- 8 years,
| except for speed of a terminal emulator, I can't understand the
| difference between them (other than iTerm2 which is nice but has
| way too many features)
| whalesalad wrote:
| I like native tabs so that I can compartmentalize multiple tmux
| sessions. Alacritty with tabs would be perfect. Kitty seems to
| be that - but it's got some oddities of it's own.
| eviks wrote:
| wezterm has a unique great feature of programmable
| configuration (lua), which allows (among many things) to have
| custom keybindings depending on the foreground process, then
| there is also some keybinding modality (in Contour as well),
| then some have quick command panels, then there are various
| levels of tab support, then there are a bunch of other UI
| improvement...
|
| But if iTerm2 has too many features, implying you don't care
| that much about them, you might not be invested enough to learn
| about the difference (there are many little things and not a
| great comparison of various terminals for an easy read)
| bloopernova wrote:
| I was going to comment something similar. I use iTerm2 day to
| day for work, and gnome-terminal on my personal Linux box.
|
| What's a compelling reason to switch terminals? Or maybe: is
| there a compelling reason _not_ to switch?
| sergioisidoro wrote:
| > is there a compelling reason not to switch?
|
| Your terminal emulator is one of the most security sensitive
| things you use. Sudo password? SSH keys? logs? A lot goes
| through your terminal, so I think about 5 times before trying
| out new terminals.
| [deleted]
| angra_mainyu wrote:
| alacritty's configurability is incredibly good, also the
| scrolling and crispness in rendering is a godsend,
| particularly if you're a heavy user or even just do long
| tails.
| eviks wrote:
| for one, being able to have an identical user experience
| across all platforms
| bloopernova wrote:
| Good point. I share my shell config between Linux and macOS
| so my UX is mostly the same. Gnome-terminal and iTerm2 act
| similarly enough that it doesn't really bother me moving
| between the two.
| akdkfe223 wrote:
| It depends what kinds of things you find compelling but I
| would guess probably nothing if you haven't already been
| sucked into the terminal emulator rabbit hole. iTerm2 and
| gnome terminal are both perfectly functional for 100% of the
| tasks you will actually need them for.
| sodapopcan wrote:
| The major reason I switched from iTerm to Alicritty is the
| config. I use cmd as my tmux key. This was really annoying to
| get working in iTerm and was brittle. It required all of
| macos overrides, iTerms overrides, Tmux config, and Karabiner
| Elements to get it how I liked it. With Alacritty, it's all
| done with a clean Alacritty config and a couple of macos-
| level overrides (I use cmd-q and cmd-h differently in
| Terminal). Also, the vim+tmux combo is noticeably faster in
| Alacritty. I'm very interested in Contour.
| NetOpWibby wrote:
| I currently use iTerm AND Alacritty. If the latter
| supported tabs, I'd use that exclusively.
| 77pt77 wrote:
| Tilling window manager?
|
| I use i3.
| da39a3ee wrote:
| > The major reason I switched from iTerm to Alacritty is
| the config.
|
| Exactly the same for me! My terminal config *must* be in
| version control. But iTerm2 keeps it in some sort of Apple
| Plist crap. It has a "dynamic JSON profile" feature but
| it's hard to use correctly.
|
| Switching to Alacritty from iTerm2 has been fantastic; I
| don't miss anything. I don't use tabs; I use tmux. I need
| an OS-wide "hotkey" but a few lines of hammerspoon seem to
| do that perfectly.
| czottmann wrote:
| > Available on all 4 major platforms, Linux, OS/X, FreeBSD,
| Windows
|
| I know it's nitpicky, but it's "macOS" since 2016, i.e. it
| stopped being "OS X" or "OSX" about 7 years ago.
| politelemon wrote:
| Any idea why nvtop wouldn't work on it? I run nvtop and get
| "Error opening terminal: contour."
| da39a3ee wrote:
| I've in the camp of never noticed my terminal emulator being
| slow. Used iTerm2 for 10 years, switched to Alacritty recently
| for reasons unrelated to performance. Before iTerm2 on Linux I
| don't really remember what I used but I don't remember it being
| slow. Haven't noticed scrolling speed being slow, and I don't get
| this "insert latency" obsession.
| tiffanyh wrote:
| A prominent blog post benchmarking latency of various terminals.
|
| https://danluu.com/term-latency/
|
| TL;DR; terminal.app on macOS is typically the fastest.
| idoubtit wrote:
| Your benchmark is more than 6 years old, on a 2014 Macbook,
| with a strange choice of terminals. LWN's article on the
| subject is almost as old, but with a better comparison:
| https://lwn.net/Articles/751763/ (2018)
|
| For a recent take, though by one of the competitors, see
| https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty
|
| > TL;DR; terminal.app on macOS is typically the fastest.
|
| Even on macOS, that's probably not true, at least nowadays. See
| https://www.lkhrs.com/blog/2022/07/terminal-latency/ (2022)
| 4death4 wrote:
| It says Terminal.app follows closely behind the fastest. This
| level of discussion around "fast" terminals is funny to me.
| I've always used Terminal.app and never had a single problem.
| It turns out the default option is likely the best in this
| case.
| konart wrote:
| How does it compare to Alacrtitty, Kitty, Wezterm, Rio and other
| moder and actually fast terminal emulators?
| souvlakee wrote:
| Recently discovered Rio and it works faster than everything GPU
| accelerated I've ever tried. Believe that's because WebGL.
| pmarreck wrote:
| Wezterm is my jam
|
| https://wezfurlong.org/wezterm/
| cormullion wrote:
| Overall I think Wezterm has the best font support (and the best
| support).
| sprash wrote:
| Really cool, the parallax background scrolling feature:
|
| https://wezfurlong.org/wezterm/config/lua/config/background....
___________________________________________________________________
(page generated 2023-10-08 23:01 UTC)