I tried switching to Kitty last year, but then it stopped working properly with the OSX 10.14 release. It turns out this was a known issue from the beta, but the author decided not to do anything about it until the release [1]. I can't rely on a terminal that's maintained like that.
Give Alacritty [1] a try. I am very happy with its performance, it just feels fast and solid. The difference in latency is really noticeable to me compared to iTerm2 or Terminal.app. Alacritty just feels significantly faster.
People keep talking about the obvious latency difference. I don't notice any latency on iTerm2 and didn't see a difference when I was trying Kitty. What am I missing?
I notice the difference even when typing. The performance improvement is most noticeable for me when editing large files in vim or having a lot of tmux panes open. Alacritty and other GPU accelerated terminals perform a lot better here and things just feel smoother.
There's an older HN thread [1] on the subject with benchmarks and lots of interesting chatter. It's worth a read IMHO.
You might want to try iTerm with gpu acceleration enabled. The only caveat is you lose some visual features, like transparency, but I found it well worth it.
There actually is a known issue with using vim in tmux on macOS. From the Alacritty README [1]:
> This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty.
I may be doing it wrong but the lack of IME (Japanese) Input support and the refusal of the author to support it is quite sad and makes it a non-starter for me and I assume many others
On the Example Script page (https://iterm2.com/python-api/tutorial/example.html) it says that the script communicates with the application using websockets ("The underlying implementation uses Google protobuf and websockets"). This makes me think that it could support other languages and ways of scripting it in the future.
Wait, web sockets? Why not regular old sockets? Why not restrict it to Unix domain sockets so that only authorized users can talk to the iTerm instance?
Controlling my terminal emulators through a browser is like managing processes with Doom: something that, while interesting and certainly shouldn't be precluded, I am unable to think of a use case where I would actually do it. Making web sockets the scripting interface for a program that in most cases you do NOT want to actually expose to the web a) makes no sense; b) is a security incident waiting to happen.
I really want to turn off the status bar. I can tell I'm not going to use it, and now it's just taking up space and confusing my habituated eye as I scan the screen.
One api feature looks especially cool - that is CustomControlSequenceMonitor provides a way to implement custom terminal control sequences and extend the terminal with richer functionality.
I switch between a 4K monitor and my built-in. The same font size definitely doesn’t work between the two of them. I’ve got a script in my .bashrc that checks the resolution of the current monitor and sets the Profile of the session using the older control-code based API, flipping between a profile for each monitor resolution.
With the new API, I can see methods for overriding profile settings on an individual session, but not a method for changing the profile a session is using to another saved profile. Does such a method exist?
iTerm2 is great, thanks to George Nachman for the hard work.
I recently installed Mojave from scratch, fresh and clean environment. I'm trying to keep things pretty minimal. I'm giving Terminal (macOS) another shot - so far it's been great. I've only missed split panes but when I really needed I used tmux. Other than that I realize I didn't use much of the functionality offered by iTerm2.
What are the features in iTerm2 that you use the most?
Honestly, while it isn't a feature that's unique to iTerm2 by any means, I just appreciate how easy it is to theme the colors and appearance. I used Arch Linux for many years before moving to Mac OS and messing around with urxvt configuration files if I wanted full 256 color or font support was somewhat tedious. It's nice to just have something that's easy to setup and always works and looks the way I want given I'm looking at my terminal for 75% of my day.
Setting the background to the solarized dark or light color pallet works nicely with the same vim pallet setup. I wanted to use this as an example because I don't believe this worked in Terminal last time I tried it. But after a quick google search it seems like you can use Terminal for this setup as well.
Clicking on links in the terminal is a nice feature. If you press cmd + click it opens your browser or finder. I occasionally enjoy this convenience.
There are probably other conveniences that don't come to mind now.
> Clicking on links in the terminal is a nice feature. If you press cmd + click it opens your browser or finder. I occasionally enjoy this convenience.
On Terminal.app you can cmd + double click to open a link on the browser. (it doesn't open a path on finder though)
I tried the same thing a year or so ago and there were a few items that brought me back to iTerm2. They’re going to seem super minor, but I use them often enough that it made a difference.
Text selection is better and customizable. Makes it easier to select things like up addresses with a double click.
Hotkey window is just too damn convenient. I end up using it all the time when I just need to execute one-off commands.
I use Hammerspoon to hotkey Terminal (and a bunch of other apps with other shortcuts) with ctrl+` like I used to do with iTerm:
-- Give Terminal the same toggle as iTerm 2
hs.hotkey.bind('ctrl', '`', function()
if hs.application.title(hs.application.frontmostApplication()) == "Terminal" then
hs.eventtap.keyStroke('cmd', 'h')
else
hs.application.launchOrFocus("Terminal.app")
end
end)
I’m not opposed to iTerm, but I needed a break from heavy customized environments for a bit and this was the one feature I needed to replicate.
both iTerm2 and Terminal.app got so slow that I switched to Hyper which contrary to common sense is blazing fast for me. I’ve also started experimenting with URXVT via XQuartz but the native feel just isn’t there like it is for Hyper.
Who knew Electron apps could out perform native ones (even with GPU acceleration in iTerm2’s case)! I don’t know how or why but in this case it is so.
> Who knew Electron apps could out perform native ones (even with GPU acceleration in iTerm2’s case)! I don’t know how or why but in this case it is so.
Across different paradigms, sure. But many languages are very similar to one another while only differing a bit in syntax.
If you use a language with a similar paradigm, learning yet another language in that paradigm will not teach you much, it'll mostly just annoy you with its subtle differences (I'm talking to you, stored and mutable default variables of python functions).
Python and JavaScript are at very different ends of the OOP spectrum. JS encourages a functional approach while Py is more procedural. That small difference can - and does - have a profound effect of who you structure your code.
These different designs will teach you different techniques for problem solving that can be borrowed in different languages when you’re trying to solve a problem that isn’t easily solved using its classic idiom.
Python and JavaScript have vastly different idioms, and learning both makes you think different. Learn both still makes you a better programmer, even considering they're both OOP languages
The original comment that is evidently so objectionable mentioned keeping a language (and by implication its libraries) in one's head. It's a known fact that this type of knowledge is use-it-or-lose-it. So drawing on it only occasionally is terribly suboptimal.
I’ve not found that to be the case even after learning probably close on two dozen different languages.
I won’t deny that there is a short upskilling time where you need a quick refresher but that’s no different to picking up old code you’ve not touched in a while in a language you do use regularly. In fact often the time you spend familiarising yourself with an existing codebase or new API also serves as a catch up for the language too.
That said, I have personally found that it gets easier the more languages you learn because you get good at spotting similarities. Much like with spoken languages: people who are multilingual adapt to new languages quicker because they spot patterns to stuff they’ve learned previously.
You’re probably trying to be flippant but you’ve actually made an interesting point.
Americans and Canadians, for example, usually find uncanny-valley differences between their nations that get washed out if you visit somewhere radically different instead. The small-magnitude “it could’ve been something else” realizations are just as important.
1990s Microsoft solved this problem with COM. For example, cscript.exe exposes both VBScript and JS, and they can talk to c++ via the same COM interfaces.
My favourite language is guile scheme which makes me all too familiar with your feelings.
Not only that: embedding python is a shitty experience compared to embedding lua or guile, and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.
> Not only that: embedding python is a shitty experience compared to embedding lua or guile...
That's a "feature", they prefer for people to extend python over embedding it in other applications.
That said, it isn't too bad unless you maintain the python c-api binding by hand since there's a lot of boilerplate and they like to change the api often.
Almost all my blender hacking was on the python API and that's crazy complicated compared to a terminal emulator. For example, all of the (context sensitive) operators are callable from python since the UI is controlled by python scripts.
> ...and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.
Pretty sure python has threads;P and has had subinterpreters[0] for a long time. Haven't really messed with either one other than making sure my C extensions release the GIL though.
I did attempt to embed lua in an application once and from what I can remember it was...interesting. Having to control the stack took some getting used to and their boilerplate was just as full featured as python's. I also don't remember being able to find useful automation scripts, with python I usually just bang out a quick prototype with pybindgen then hand edit it until I'm happy.
No proper concurrent threads was of course what I meant. In that light the subinterpreter feature is also not very good, since all sib-interpreters share a GIL (but iirc there is a PEP out there that might make python properly multi-core through some kind of CSP-approach and independent subinterpreters).
https://sw.kovidgoyal.net/kitty/