iTerm2 beta adds Python API | Hacker News Reader

iTerm2 beta adds Python API

iterm2.com

145 points20after460 comments

Kitty terminal has a Python API too, and it's got images and high performance, etc.

https://sw.kovidgoyal.net/kitty/

Been using kitty on both osx and debian, I am very happy with the performance and out-of-the box features so far.

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

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.

[1] https://github.com/kovidgoyal/kitty/issues/887#issuecomment-...

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.

[1] https://github.com/jwilm/alacritty

Disclaimer: I am not associated with the project in any way. Just a fan.

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 use iterm2 + tmux + vim and there is noticeable latency compared to say a linux setup or using kitty

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.

[1] https://github.com/jwilm/alacritty#faq

Hm, interesting, thanks.

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.

[1] https://news.ycombinator.com/item?id=14798211

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.

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?

Maybe so folks could build web UIs to interact with a local instance? Can't do raw TCP/UDP from a web browser.

Then write a bloody wrapper.

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.

Manage processes with Doom you say...

Yes, I was specifically referring to this: https://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html

Or Kubecraft :) https://www.youtube.com/watch?v=A4qwsSEldHE

Ooh, nice! Been waiting for this for a while; now I can finally change my terminal's theme automatically when the system appearance changes: https://gist.github.com/saagarjha/9a99ed4bc68a37bab097cc6ee8...

Although, I clicked through the status bar stuff and now I can't figure out how to get it back :(

Under preferences -> appearance you can choose status bar position: bottom (or top).

Then you can right click on the status bar to get to the editor.

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.

Anyone found an off-button?

Go to Preferences > Profiles > Session and at the bottom there's a checkbox labeled "Status Bar Enabled".

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.

One thing I’d love to port to this:

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.

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.

It’s gonna sound super minor, but

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.

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)

Font ligatures are what’s keeping me on iTerm right now.

>What are the features in iTerm2 that you use the most?

Quake-like drop-down animation.

- Hot key to summon/dismiss persistent terminal session

- Ability to create arbitrary handlers for mouse click actions

- Ability to save my configuration in version-controlled JSON

- Autocomplete

- Conventional full screen mode (not the weird MacOS thing that creates a new desktop)

- Auto-summon of the Password Manager on password prompts

- Grep for things that look like IP address and color them in blue, or errors in red

- Auto-Complete based on the text in terminal

- Broadcast same keypresses into several panes (having SSH sessions to several servers)

- Making an icon jump when a long running command just finished

- etc.etc.

I know people who returned their company-issued X1 Carbons and bought an out-of-pocket MacBooks just so they can use iTerm.

Tangent: like Python in your terminal/shell? See also https://xon.sh

Love it and use it from some time! Scriptable status bar is also awesome feature. :)

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.

I don't think the main gripe people have with Electron has ever been performance, V8 is plenty fast after all, it's more about the memory footprint.

> 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.

How are you measuring?

Sometimes I've wished that Sublime Text's API used JS so that I didn't have to know Python just for one program.

It seems a waste having to keep a battalion of imperative OO languages in one's head just for incidental use.

I would say the same about JS, which I've never used once in my life.

Not everything is done in a browser.

Then we agree on the generalized problem.

Not the OP, just wanted to say that what you are suggesting is extremely unpopular and controversial here, would you care to expand on your reasoning?

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.

Learning other languages is not a waste. It actually makes you a better developer.

That's true if learning meaningfully different languages, but much less so if it's a 5th imperative OO language.

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

Like someone with keys to the world should spend time living in both Scotland and England to absorb the vast cultural differences?

Living in both? Certainly not. However I would advocate visiting Scotland if you’re English. It’s a beautiful country.

Likewise nobody says you need to be a full time developer in every language to get benefit from learning them.

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.

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.

I’ve never seen two languages so similar there was no didactic value to learning both. Hell I’ve never seen any language that offered nothing unique.

Except perhaps Java and early C#. before Linq.

I understand the concern, but how many scripting languages are really used embedded in applications? It's usually python or Lua.

... or Lisp.

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.

[0] https://docs.python.org/3/c-api/init.html#sub-interpreter-su...

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).

Reply on news.ycombinator.com