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

31–40 of 155 posts

Re: Emacs and Vim in the Age of AI

#31

Post by globular-toast »

Emacs is a true bicycle for the mind. It sets you free in many ways, always wanting to be the tool that simply allows you to do your job more efficiently and effectively.

LLMs are like living with a depressed person who doesn't see the point in doing anything because it's all just been done before. Who cares if you do a good job? Just recycle some shit that others have done and it'll be passable. This isn't a bicycle for the mind, it's just going to drag you into depression with it.

Re: Emacs and Vim in the Age of AI

#32

Post by jurschreuder »

I'm not sure AI Agents can already beat the average VIM user.

I use VIM and I get some inspiration from LLMs sometimes, but me and other developers always after some time give up and just quickly do it manually.

AI Agents will just full the code with maaaassive swaths of texts it will just make a project unusable.

We even get paid to turn client's AI LLM Claude sketches into real programs.

Re: Emacs and Vim in the Age of AI

#33

Post by pjmlp »

I lived in XEmacs between 1995 and 2005, because in many UNIX variants having an IDE was a foreign word, not even something that could provide the affordances of a Turbo Pascal with Turbo Vision based IDE for MS-DOS.

Between Emacs, the improved XEmacs, and vi, the answer was obvious at the time, I joined the Emacs faction with XEmacs.

Mastered elisp good enough, had my configuration scripts, go to know enough vi to handle telneting (or sshing) into random UNIX servers without anything else installed.

Both are still kind of stuck in time, going back to them in random UNIX distribution feels like I am back in that UNIX decade.

Re: Emacs and Vim in the Age of AI

#34

Post by keithnz »

vim (neovim these days) for me is my text editor I use to look at code when dealing with AI, more often than not I'm working on a bug list as I test things. I haven't opened my IDE (Jetbrains tools) for nearly 2 weeks now. Only thing I often want is to be able to run sql queries, I used datagrip for that... Now I'm writing my own tui sql tool that is lightning quick and has most of the features I like from data grip, plus a bunch of new things that make my life easier. I've made it work as a MCP server also so that I can get my agent to directly inject queries and I can browse the result sets easily. I feel like the terminal, because its text based and super great at manipulating text is such a perfect match for these AI agents. But, yes, the need for code editing itself is really limited.

Re: Emacs and Vim in the Age of AI

#35

Post by keithnz »

jurschreuder wrote: post #32

I'm not sure AI Agents can already beat the average VIM user. I use VIM and I get some inspiration from LLMs sometimes, but me and other developers always after some time give up and just quickly do it manually. AI Agents will just full the code with maaaassive swaths of texts it will just make a project unusable. We even get paid to turn client's AI LLM Claude sketches into real programs.

This is not my experience at all, the AI agents are many many many times faster than what I can do. What anyone can do. It's crazy how quick I can create stuff these days.

Re: Emacs and Vim in the Age of AI

#36

Post by myrak »

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…

[dead]

Re: Emacs and Vim in the Age of AI

#37

Post by komali2 »

> Imagine an AI assistant that can read your org-mode agenda, draft email replies in mu4e, help you write commit messages in Magit, and refactor code in your source buffers – all within the same environment, sharing context. No other editor architecture makes this kind of deep, cross-domain integration as natural as Emacs does.

I've been a devout emacs amateur for 10 years, and recently learned nvim/lazy.vim because I was tired of web dev kinda sucking in emacs. Sure, you can get a setup with lint-on-save, inline TS errors, and all the other bells and whistles you get in vscode working on a react-tsx project, but then when you `helm-projectile-switch-project` to a vue project, suddenly you have to get a whole new config set up. And oops, for whatever reason, tab spacing isn't being pulled from the editor config for this directory...

But like the author says, LLMs fixed that. I pointed Warp at my emacs config, said my problems, and said "fix plz," and it did. No more "oops," just "fix plz" whenever I'm editing rust, or svelte, or golang, or whatever else for the first time in emacs.

I'm very excited for the possibility in the portion I quoted. I moved away from mu4e and org mode because managing it all was getting tedious: too much time procrastinating by tweaking org configs. Too many emails not rendered properly in mu4e or fat fingered by me and lost. But in world+llm, that's not really a problem anymore. I haven't migrated back to org mode yet but I did an experiment recently asking claude to set up org similar to my trilium set up, and it did a passable enough job that I was convinced it's possible.

So, now I'm back in emacs, trying out the various LLM tools, doing poorly at getting anything other than copilot to work well, and waiting with patience and desperation for someone to make an LLM completion experience in emacs that has a multiline completion experience at least 50% as good as Cursor's.

Re: Emacs and Vim in the Age of AI

#38

Post by rekrsiv »

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.

Re: Emacs and Vim in the Age of AI

#39

Post by flipped »

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

#40

Post by rtpg »

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…

This stuff stands on the foundations it's built off of. It's very hard to argue against the stoic determinism of an `ls` call.

And all the success stories I've seen in people using these tools have had a similar theme: top level might be LLM-y but you rush to get to deterministic straightforward building blocks so that you can have reliability.

That, to me, looks like writing up a bunch of small programs to help establish vocabularies and workflows to avoid just churning and getting lost in the weeds.

I'd be interested in seeing some future form of process orientation, but in the meantime.... shells in general have proven they are decently good at tying stuff together quite well.

`ls dir | grep thingy | process` gonna involve less possibility of annoying drift and churn than "run process on all the files with thingy in their name in directory"

Post reply on HN