2 ms·
I think your reading is fair considering what I actually wrote! It's just not quite what I had in mind. But what I wrote is still quite scrappy; that line is m
by ecjhdnc2025 2y ago
I think your reading is fair considering what I actually wrote!
It's just not quite what I had in mind. But what I wrote is still quite scrappy; that line is missing at least an "in general" to broaden that point out beyond iTerm 2 specifically. I need to slow down a bit more.
I don't really agree with you on the LLM side of the equation, and I am bothered by the idea that this is where we're all headed. But where I think this integration is not ridiculous is in doing this at the GUI level.
There is an argument for saying "why isn't this a utility at the remote (shell) end", but of course from the perspective of OpenAI API calls being added to everything and calling out from the command line, that would be worse, because you'd be installing it everywhere.
So if it belongs anywhere (colour me wholly unconvinced) it definitely belongs somewhere within the terminal client itself.
But as I say, I don't use iTerm 2. I did take this opportunity to look at what iTerm 2 offers, out of fairness to the author, and it is obviously an impressive bit of work. Maybe when I find a need for Python scripting like that I'll come back to it.
- int_19h 2y agoiTerm is a "kitchen sink" type of app in general. That is, it is definitely a terminal emulator, but it has lots of features, and I doubt that most users use even half of that. So in that sense, if you're using it, you're already at least tacitly accepting that philosophy as valid. So optional LLM integration is not really out of place there in the sense that it would be in a truly minimalist terminal emulator, IMO. With regard to LLMs, for what it's worth, I'm not suggesting that people use them to routinely drive their shell. This is the kind of stuff that you use very occasionally, when it is time to use that one command that is immensely useful for very specialized things, and which you can never in your life remember the syntax for precisely because it's not something you do every day. The canonical examples there are ffmpeg, ImageMagick, and similar tools. Remember https://linux.die.net/man/1/cdecl https://linux.die.net/man/1/cdecl? This is basically like that, just based on tech that allows it to be better generalized.
- ecjhdnc2025 2y ago> This is the kind of stuff that you use very occasionally, when it is time to use that one command that is immensely useful for very specialized things, and which you can never in your life remember the syntax for precisely because it's not something you do every day. Don't people make notes of that somewhere they can look it up? I mean, you're not going to use this to generate command line arguments for commands you've never heard of before, you're likely not going to use it for commands whose outputs are crucial or behaviours unsafe, and if you do you're going to need to use your actual knowledge to check it hasn't hallucinated something dangerous before you run it -- which means consulting the manual and doing the work. I get that man pages are a particularly rich, standardised form of training text, I just don't believe there is as much advantage in asking an LLM. This is one of those areas where I think people project success onto LLMs where there is none. It's like the songwriting example. Sure it can write a bad song fast, but so can literally anyone half-skilled, and if you want to help it write a good song, you're going to have to redo half the work. This is just like having a bad dishwasher.
- int_19h 2y agoThe workflow here is to generate the command line first, then consult the manual to see what exactly it does. Which is much easier than reading the whole thing end-to-end trying to find the exact combination for your needs to begin with.