Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs and Vim in the Age of AI

batsov.com

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Emacs and Vim in the Age of AI

#71

Post by minikomi »

chamomeal wrote: post #6
rgoulter wrote: post #4

May be splitting hairs, but I don't think it's the terminal-native part that's relevant, so much as that both LLMs and emacs/vim are text oriented in ways which e.g. VSCode isn't. (Or perhaps just the text-oriented nature is a result from initial constraint from being terminal-native). As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different task…

Not totally related to your point BUT I’d like to tack on that lisps and generally repl-friendly languages are in an interesting spot in the LLM-enabled world. The calva-backseat-driver vscode extension runs an MCP that lets LLMs manipulate and eval clojure expressions in a REPL. It provides a tighter feedback loop and lets LLMs do much more complicated stuff with much more confidence. They can test functions as they…

I don't let it execute emacs lisp itself, but elisp generated in org mode babel blocks which is instantly executable is a fine way to have gptel improve itself.

( See "meta tooling" in https://poyo.co/note/20260202T150723/ )

Re: Emacs and Vim in the Age of AI

#72

Post by jwr »

My time spent in Emacs has *increased* with the increased use of AI. I have to read, edit, accept and reject all those code changes and Emacs+Magit is pretty much the best interface for that.

Re: Emacs and Vim in the Age of AI

#73

Post by simianwords »

discardable_dan wrote: post #51
beemboy wrote: post #16

I'm not convinced that terminal orientedness of AI tooling itself will last. My hypothesis is that it was chosen by developers of the current generation building for developers of the current generation. I hypothesize that there is a future where command lines and terminals don't matter, and hence I feel the focus will shift to, as the author points out, to planning, reviewing and ideation tools none of which demands…

Coining this phrase now: "It's the tokens stupid" Hooking up to and generating calls across filesystem APIs cost multiple orders of magnitude more than calling `ls`. These tooling ideas are interesting, though. Maybe Kenneth_E._Iverson was right all along? Talking to another senior dev over drinks tonight, we both worried not about our work but about who might come up never having written a single line of code. Never…

>Hooking up to and generating calls across filesystem APIs cost multiple orders of magnitude more than calling `ls`. These tooling ideas are interesting, though. Maybe Kenneth_E._Iverson was right all along?

I don't think you understood what the idea was. Its not about calling `ls` vs not. I don't think UNIX commands are going away (or at least deterministic calls).

Its the interface itself that would go away. We won't work on terminals but some other interface which would use commands internally.

Re: Emacs and Vim in the Age of AI

#74

Post by simianwords »

rekrsiv wrote: post #38
beemboy wrote: post #16

I'm not convinced that terminal orientedness of AI tooling itself will last. My hypothesis is that it was chosen by developers of the current generation building for developers of the current generation. I hypothesize that there is a future where command lines and terminals don't matter, and hence I feel the focus will shift to, as the author points out, to planning, reviewing and ideation tools none of which demands…

A terminal still offers a more composable interface than a GUI. Analog feedback is still a concern for high level pilots. You are confusing power tools with entry-level instruments.

interesting, what do you mean by composable?

Re: Emacs and Vim in the Age of AI

#75

Post by hrmtst93837 »

beemboy wrote: post #16

I'm not convinced that terminal orientedness of AI tooling itself will last. My hypothesis is that it was chosen by developers of the current generation building for developers of the current generation. I hypothesize that there is a future where command lines and terminals don't matter, and hence I feel the focus will shift to, as the author points out, to planning, reviewing and ideation tools none of which demands…

[flagged]

Re: Emacs and Vim in the Age of AI

#76

Post by mchaver »

keithnz wrote: post #59
gdorsi wrote: post #52

Earlier quoted context omitted.

It really depends on what kind and of job you do. If it's not something very common LLMs could end up generating random code. Also if you work on something performance critical, you can get inspiration from LLMs, but they often don't write fast code.

not my experience, they write fast code, and if you ask them to optimize, can pull all kinds of tricks out of the bag. Even with some of the niche stuff I work on, they seem really good.

Without telling us what kind of code you are talking about it is hard to compare. I would say that is true for CRUD web code because there is so much out there that the LLMs can reference.

Re: Emacs and Vim in the Age of AI

#77

Post by mchaver »

jwr wrote: post #72

My time spent in Emacs has *increased* with the increased use of AI. I have to read, edit, accept and reject all those code changes and Emacs+Magit is pretty much the best interface for that.

I will have to checkout Magit, but, as an already heavy Emacs user, my time in Emacs has remained constant even with increased use of agentic coders.

Re: Emacs and Vim in the Age of AI

#78

Post by 1718627440 »

keithnz wrote: post #66
armchairhacker wrote: post #60

Earlier quoted context omitted.

AI can generate code much much faster. But do you never need a specific change (e.g. bugfix), that even describing in English is slower than just doing it? Especially in vim where editor movements are fast.

possibly there's cases where maybe you want to change some text or something, but I don't think its faster in vim given you likely don't have that file open, and by the time you get to the file, and location, you could have fixed it with your agent, not only that, you could have generated the test case and then fixed in your agent

I think you missed the point. It takes more time to write English prose than to open a file and just fix it, so unless the time the LLM needs is somehow negative, it's not going to be faster.

Re: Emacs and Vim in the Age of AI

#79

Post by keithnz »

mchaver wrote: post #76
keithnz wrote: post #59

Earlier quoted context omitted.

not my experience, they write fast code, and if you ask them to optimize, can pull all kinds of tricks out of the bag. Even with some of the niche stuff I work on, they seem really good.

Without telling us what kind of code you are talking about it is hard to compare. I would say that is true for CRUD web code because there is so much out there that the LLMs can reference.

I work on all sorts as we have an IoT product offering.... embedded bare metal systems, web, backend IoT servers, Gateways, APIs, Import/Export Systems, Integrations with Manufacturing systems, accounting systems, Automatic Test Equipment. I've been coding for nearly 50 years now, so pretty experienced. What peoples comments seem to imply to me is that they haven't really gone full agentic coding, where you hone your context, your tools, and how you iterate and test with an AI agent. Where any mistakes an AI makes you make sure it can't do it again, you have it setup so your AI code reviews are honed to focus on the things you care about etc.
Post reply on HN