What did the dinosaurs think in their twilight years as their numbers dwindled and small scurrying mammals began to challenge their dominance? Did they reminisce of the glory days when Tyrannosaurus Rex ruled the land and Pteranodon soared through the air? Probably not. They were, after all, just dumb animals.
Our company has decided to buy in to Cursor as an AI coding tool. Cursor is one of many AI coding tools that have recently been brought to market, and it is a fine tool. It is based on a fork of VSCode and has AI coding capabilities built in to it. One of the more useful ones (and one that is available in many other AI tools) is AI code completion. This anticipates what you are going to type and tries to complete it for you. It gets it right maybe 10-20% of the time if you are lucky, and not far wrong maybe 80% of the time. You can get into a flow where you reflexively keep or discard its suggestions or accept the near misses and then correct them. This turns out to be faster than typing everything yourself, once you get used to it. It isn't for everyone, but it works for me.
Our company has been using GitHub Copilot for several months now. There is an Emacs package that allows you to use the Copilot code completion in Emacs, and I have been using it for these past few months. In addition to code completion, it will complete sentences and paragraphs in text mode and html mode. I generally reject its suggestions because it doesn't phrase things the way I prefer, but I really like seeing the suggestions as I type. It offers an alternative train of thought that I can mull over. If the suggestions wildly diverge from what I am thinking, it is usually because I didn't lay the groundwork for my train of thought, so I can go back and rework my text to make it clearer. It seems to make my prose more focused.
But now comes Cursor, and it has one big problem. It is a closed proprietary tool with no API or SDK. It won't talk to Emacs. So do I abandon Emacs and jump on the Cursor bandwagon, or do I stick with Emacs and miss out on the latest AI coding tools? Is there really a question? I've been using Emacs since before my manager was born, and I am not about to give it up now. My company will continue with a few GitHub Copilot licenses for those that have a compelling reason to not switch to Cursor, and I think Emacs compatibility is pretty compelling.
But no one uses Emacs and Lisp anymore but us dinosaurs. They all have shiny new toys like Cursor and Golang. I live for the schadenfreude of watching the gen Z kids rediscover and attempt to solve the same problems that were solved fifty years ago. The same bugs, but the tools are now clumsier.
Are there any Emacs packages which do AI autocompletions like Cursor?
ReplyDeleteI only aware of Aider.el but it does work in chat mode. Also there is GPTel which also seems work by respoding to a given prompt.
There is copilot.el which uses a node program to interface between Emacs and Copilot for AI autocompletion. That's what I use now.
DeleteFWIW, I've been using Cursor + Emacs for the last half-year or so. I have one screen running Cursor, which I use almost exclusively for agent chat and rarely, if ever, for direct editing of code and certainly not for code completion. Then I have another screen running Emacs, where I edit code, review diffs, commit to git (with Magit, of course).
ReplyDeleteI have been making more use of GPTel lately, though. It is capable of chat-driven coding much like Cursor if you give it enough tools. The only thing missing is the agent definition, which (between Ollama and some custom plumbing) I'm getting closer to reproducing locally. It definitely still needs some work, but in the end I'll have something that I completely understand and control for myself (and if that wasn't a goal, then what was I doing using Emacs in the first place).
I don't know about the dinosaurs, but when a lumberjack swinging an axe sees young guns show up with chainsaws, he can lay down the axe...or give it a sharper edge.
For my personal use, I have gptel connected to Gemini. For work use, I want to be sure to use the AI solutions that my company has legally vetted so that I don't expose them to any weird liability issues.
DeleteI'm not ready to lay down my axe yet, but the time is approaching where I'm going to stop swinging it for other people.
I once told a notable programming language creator that my plan was to "retire to Scheme" when I got too old. His response was, "well, I guess some people like to go off into the woods and build themselves a log cabin."
DeleteI always thought that was a rather apt metaphor.
> The only thing missing is the agent definition, which I'm getting closer to reproducing locally.
Delete@Josh could you explain what you mean by reproducing the agent definition? Are you writing LLM tools for gptel?
> my plan was to "retire to Scheme"
DeleteMine as well, maybe earlier than I thought. I was trying to wean my self off Phil Greenspun's blog, started reading Joe Marshall again, and found he's into LLM. Sometimes a dinosaur just has to say, "Let the mammals reinvent the wheel with modern vibe programming or whatever."
@karthink GPTel is relatively flexible in how you can adjust context, adjust prompts, and supply tools (implemented as elisp functions). As Joe Marshall has pointed out in the last few blog posts, that's really all you need to be able to implement an arbitrarily complex agent, as you can make tools call the LLM, and the LLM call tools, according to whatever instructions you assemble. For my part, I'm currently at the point of having a series of tools for searching the web, reading files in a project, writing/updating files in a project, and executing arbitrary shell commands (with user confirmation, obviously). The next step is to create tools that can generate a plan, extract a ToDo list, feed the plan steps and ToDo items back one at a time, and update the plan/list. These are the sorts of tools where the tool will need to call the LLM (which is why I haven't gotten to them yet).
Delete@Josh From what I've seen many users appear to be writing gptel tools to do these things (filesystem/web/shell/elisp-eval access), and it's leading to a lot of repeated work. gptel tool collections are also not very discoverable. This is mostly my fault for not clearly directing users to a single, crowdsourced source of tools, or not bundling tools with gptel itself.
DeleteThere is currently https://github.com/skissue/llm-tool-collection, but it hasn't taken off. You could try building on it. Several more listed here: https://github.com/karthink/gptel/wiki/Tools-collection#external-tool-sources
I'm looking for one comprehensive, high-quality repository of tools (easily installable from (M)ELPA) that I can officially promote it in gptel. Tools to create a plan and track progress are available via MCP, but an elisp implementation would be part of this repo.
> These are the sorts of tools where the tool will need to call the LLM
Sure, the tool just has to call `gptel-request`.
In my last job, I was the only Emacs user among a sea of vim and VSCode users.
ReplyDeleteEmacs is less of a dinosaur than a Mark III Type 40 TARDIS. Perhaps not as flashy as the newer models, but nonetheless quite sophisticated and functional in the right hands.
ReplyDelete