Get the top HN stories in your inbox every day.
mk12
rob74
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.
nikolay
I love Wez, but I hate the lack of macOS native tabs.
alwillis
+1 for WezTerm.
Switched from iTerm 2 like a year ago.
SadTrombone
Huge WezTerm fan, the dev is very friendly and responsive on GitHub as well.
KolenCh
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
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
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.
hn92726819
Is Kitty's startup time (~200ms) not unbearable for other people? Is it faster now or do people not spawn new terminals constantly?
fn-mote
Frankly, my shell startup time is that long. (fish, some configuration files, no effort at optimization)
That's a pretty hyper-optimized life, when 0.2 sec to get a command line is a problem.
hn92726819
> That's a pretty hyper-optimized life, when 0.2 sec to get a command line is a problem.
This made me chuckle :D. I supposed you're right. On my work rig, 200ms is a dream, so I suppose kitty would be great.
For personal programming, I use i3 and sway. The latency difference between my work mac and personal Linux is insane. Every little bit feels like molasses on Linux since it's the lowest latency system I've ever used.
lytedev
I open new tabs or panes in my single terminal window, personally FWIW.
hn92726819
Great point. I was using i3/sway which is not conducive to terminal tabs or panes, but on my mac, kitty does sound pretty good, and 200ms is way better than what I'm getting now
vluft
you can run it with `--single-instance` (or `-1`) and you only pay (most of) that startup cost once.
Razengan
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
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.
ljm
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
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.
ljm
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.
undefined
mardifoufs
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
Also, Microsoft has their own new terminal program.
p5a0u9l
> kitty I hate to be the sour consumer, but the kitty dev’s attitude I’d the main thing that turned me off kitty. Wanted to like it, couldn’t do it.
trapnii
There are even YT videos about that. Not kittyng :)
angra_mainyu
My favorite is alacritty, although kitty is a close second, not a big fan of how kitty handles fonts/colors compared to alacritty.
cout
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.
trapnii
simply put, yes. but I know very well that performance can be measured in many different dimensions and ways. I optimize for speed for my own personal use-cases (vim should be fluent as well as notcurses-demo as well as cat'ing large output).
Especially cat-style benchmarking is what YT-channels like to do, right next to `time tree /`.
We do not claim to be THE fastest (unless you find out why, but pssst, don't tell anyone), because I do not want to start a performance war on some metric that is almost useless for the regular and even power user.
Input latency, oof, last time I actually took the time to check, it was similar to KDE konsole. I used some Java based tool to measure this, IIRC I've got this from an LWN article. But now, I'm not having the time to do this again, especially since I feel like there's more important stuff on our plate, that I really want to get done in 2023 (e.g. getting out the next stable release). :)
If anyone of the power users opts to re-visit perf benchmarking on the modern TEs compared to the classic ones, I'd be one amongst the first to gladly read though ;)
malablaster
I don’t see the point of pitching “fast” as its first selling point. Are people frustrated by the latency of the incumbents?
hoherd
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
> 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.
anta40
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
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.
ghusbands
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
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
Spot on!
ur-whale
> 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
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
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.
cobbal
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.
user3939382
I’ve never been able to perceive the difference. I use iTerm2 and I can’t perceive how it could be faster.
vidarh
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.
undefined
kristopolous
Seems to be a windows/mac problem. In Linux I've never really been bothered by it in at least 20 years
tssva
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
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
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)
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
SoftTalker
I use xterm. Seems fine. Not sure what I'm missing I guess but I get my work done.
gusfoo
> 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.
IshKebab
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?
PhilipRoman
FYI for editing multiline inputs there is a readline key command edit-and-execute-command that opens your $EDITOR with the currently typed command. I mapped it to C-x C-e, not sure what is the default key, if any.
For history I recommend fzf, it's easy to integrate and has one of the most efficient interfaces I've seen. Replaced my ctrl-r with it.
For copying I personally use a tmux binding that dumps the current screen into vim, letting me navigate quickly with easymotion and a mapping that automatically synchronizes the @t register with tmux clipboard.
Macha
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.
trapnii
> It would be nice if someone worked on actually improving the terminal experience.
Contour. Oh, sorry, I mean: To be honest? There are plenty of young terminals that work on that, it's not just Contour, but also WezTerm, foot, Ghostty, Warp, and Terminal.click (even though I am strongly against their architecture). Also Charm and Fig should earn an honorable mention.
> Selecting, copying and pasting text is still pretty awful
Use the vi-like normal mode in Contour and that should(tm) fix almost all of the above problems. At least I have almost never touched a mouse again on Contour since I've implemented modal input in Contour. Well, I use the mouse, casually for scrolling and procrastinating by randomly clicking around. :)
> (why is the cursor an entire block rather than a I bar?).
this is configurable in recent terminals
> Editing multiline inputs is awful.
this should be implemented by your shell or readline, in case you want to improve here. your TE has nothing to do with this except that it provides the tools to realize that on the screen :)
> Navigating history is so-so (even with McFly etc.).
This is the job of the shell/readline.
> Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
I really cannot related that claim to anything I am experiencing in my own life. Sadly.
> Why are terminals always stuck in the 70s? Can I get a modern terminal?
To be fair, they are not named "emulator" for fun and giggles. But I agree, not every VT sequence or semantic should be blindingly implemented. Especially the Unicode case on Terminals were always a fight against the historian terminal emulator developers. I asked myself why a lot on that matter. My theory? Because it potentially requires those existing terminals to fully re-write their core code base in order to be fully (as full as it gets) Unicode aware.
Have a look here for a baby-step forward: https://github.com/contour-terminal/terminal-unicode-core
This is implemented by 4 terminals (Ghostty, WezTerm, foot, Contour). One bite at a time I guess. Let's just stay positive, we can't break the world! (Terminal.Click? You listening?) But we should certainly break here and there when it makes sense and also not blindingly implement the 70s again. The GUI has also good moments and can live next to the TUI ;)
indymike
> 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.
IshKebab
You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
> The terminal just takes commands from the host and does what it is told.
> 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 histor
I know!!!
My point was why is nobody working on fixing these issues?
The answer is not because it can't be done. That just shows lack of imagination.
indymike
> You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
If it was the end of the story, progress would stop. Saying we need a better terminal and then talking about things that run using a terminal ui, but are not the terminal really is the issue here.
> My point was why is nobody working on fixing these issues?
People are working on the problem. There are tons of shells, TUIs, command parsers, web interfaces for commands and interactive apps, some software even work in TUI and GUI mode.
Perhaps a better terminal would help, but I suspect that the problem is there's not really a medium between "better terminal" and "web browser" that won't just evolve into a web browser or something like X over time.
> The answer is not because it can't be done.
No one said it can't be done. You can argue it has been done many times... X11, the web, etc.. But I think the OP was confused about what a terminal is and what the software that runs in the terminal does.
paradox460
Fwiw, iTerm2 has a "copy mode" which lets you navigate around and yank the visible terminal and scrollback with vim bindings
blueflow
Prerequisites:
./scripts/install-deps.sh
jraph
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.
fefe23
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
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)
eviks
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
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
> 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.
undefined
sodapopcan
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.
da39a3ee
> 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.
NetOpWibby
I currently use iTerm AND Alacritty. If the latter supported tabs, I'd use that exclusively.
akdkfe223
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.
eviks
for one, being able to have an identical user experience across all platforms
bloopernova
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.
angra_mainyu
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.
whalesalad
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.
amitizle
> 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.
Gotcha. I'm using tmux sessions for that.
czottmann
> 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.
mgaunard
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.
whalesalad
Tmux is great even for local dev. I use it locally and remotely.
You might like to try kitty.
snapplebobapple
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
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?
abnry
The GUI style choices turn me off to terminator. Silly reason. Maybe I should look at changing defaults.
pmarreck
Wezterm is my jam
sprash
Really cool, the parallax background scrolling feature:
https://wezfurlong.org/wezterm/config/lua/config/background....
pmarreck
I didn't even know it had that feature until now, LOL, nice!
cormullion
Overall I think Wezterm has the best font support (and the best support).
masto
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.
mistercow
> 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.
ElCapitanMarkla
I hadn’t had this issue for years, about 4 months ago I started at a new company which had a big rails monolith. I’m now super conscious of ever resizing iterm, if I leave a terminal running for more than a day resizing the terminal brings the entire laptop to its knees.
trapnii
> What’s modal about it?
Modal? The various input modes. Think of them as if you're using vi/vim, except that it's a terminal. Insert mode is just like every other terminal. Press Ctrl+Shift+Space to move to normal mode (configurable) and use many of the vim motions you know to navigate through your history. The supported keys go way beyond what Termite and Alacritty implement. You might find that you'll never need a mouse again (or almost never). For anything that's missing, please file a ticket, and we're going to work on that.
> Certainly I’ve wished the things I run in it were faster, but that’s a different story.
I absolutely agree. Most of the performance metrics that people talk about is beyond visual perception anyways. In Contour we've only done some optimizations the way we did it because it was actually fun to implement, and a nice little challenge.
While I myself feel like i'm pretty much hard-lining into the terminal, I accept that some things are better left to the GUI world, e.g. daily web-browsing I should not be forced to use w3m or the likes. :)
maccard
> 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.
ftyers
Does it support Arabic/Devanagari and not do crazy things with BiDi? If so I'm sold!
Tmpod
It looks like it uses Qt under the hood, so it likely leverages it. Haven't tried yet though.
trapnii
Hey, we are using Qt only on the pure frontend GUI side. The rendering itself is using FreeType + HarfBuzz independantly of the GUI.
We chose this model explicitly to still be free to replace Qt with something else in the future - iff we have to. The reason behind that decision is, that we actually started with GLFW3, and epically failed, because GLFW3's input model was inferior and the API that I needed was actually marked deprecated by the GLFW3 devs and they also stated that their input model is not good and needs a rework. That led me to the decision to look around and find something else. I only wanted to keep the GUI framework dependency as minimal as possible.
We sadly do not have BiDi support just yet, I'd actually love to have that. So far I only know of 2 terminals capable of this: mlterm and gnome-terminal. Unfortunatily I lag the skills of hacking this in except doing it naively. I'd be more than happy for external contributors knowledgable enough in the domain of BiDi, to help us out here. :)
slim
do you think mlterm is slow?
ftyers
I've not used it, is it good?
kps
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).
slim
it's the best
Get the top HN stories in your inbox every day.
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.