←back to thread

310 points skarat | 1 comments | | HN request time: 0.391s | source

Things are changing so fast with these vscode forks I m barely able to keep up. Which one are you guys using currently? How does the autocomplete etc, compare between the two?
Show context
welder ◴[] No.43960527[source]
Neither? I'm surprised nobody has said it yet. I turned off AI autocomplete, and sometimes use the chat to debug or generate simple code but only when I prompt it to. Continuous autocomplete is just annoying and slows me down.
replies(27): >>43960550 #>>43960616 #>>43960839 #>>43960844 #>>43960845 #>>43960859 #>>43960860 #>>43960985 #>>43961007 #>>43961090 #>>43961128 #>>43961133 #>>43961220 #>>43961271 #>>43961282 #>>43961374 #>>43961436 #>>43961559 #>>43961887 #>>43962085 #>>43962163 #>>43962520 #>>43962714 #>>43962945 #>>43963070 #>>43963102 #>>43963459 #
imiric ◴[] No.43960839[source]
This is the way.

All this IDE churn makes me glad to have settled on Emacs a decade ago. I have adopted LLMs into my workflow via the excellent gptel, which stays out of my way but is there when I need it. I couldn't imagine switching to another editor because of some fancy LLM integration I have no control over. I have tried Cursor and VS Codium with extensions, and wasn't impressed. I'd rather use an "inferior" editor that's going to continue to work exactly how I want 50 years from now.

Emacs and Vim are editors for a lifetime. Very few software projects have that longevity and reliability. If a tool is instrumental to the work that you do, those features should be your highest priority. Not whether it works well with the latest tech trends.

replies(3): >>43961064 #>>43961518 #>>43962105 #
zkry ◴[] No.43961064[source]
Ironically LLMs have made Emacs even more relevant. The model LLMs use (text) happens to match up with how Emacs represents everything (text in buffers). This opens up Emacs to becoming the agentic editor par excellence. Just imagine, some macro magic acound a defcommand and voila, the agent can do exactly what a user can. If only such a project could have the funding like Cursor does...
replies(2): >>43961109 #>>43961447 #
throwanem ◴[] No.43961109[source]
Nothing could be worse for the modern Emacs ecosystem than for the tech industry finance vampires ("VCs," "LPs") to decide there's blood enough there to suck.

Fortunately, alien space magic seems immune, so far at least. I assume they do not like the taste, and no wonder.

replies(1): >>43961503 #
imiric ◴[] No.43961503[source]
Why should the Emacs community care whether someone decides to build a custom editor with AI features? If anything this would bring more interest and development into the ecosystem, which everyone would benefit from. Anyone not interested can simply ignore it, as we do for any other feature someone implements into their workflow.
replies(1): >>43961824 #
tough ◴[] No.43961824[source]
what i find interesting is why is nobody building llms trained on using the shell and PTY at its full

right now its dumb unix piping only

I want an AI that can use emacs or vim with me

replies(3): >>43961967 #>>43962164 #>>43963543 #
1. throwanem ◴[] No.43963543[source]
Elnode should make this very easy, given the triviality of the MCP "protocol."

I would take care. Emacs has no internal boundaries by design and it comes with the ability to access files and execute commands on remote systems using your configured SSH credentials. Handing the keys to an enthusiastically helpy and somewhat cracked robot might prove so bad an idea you barely even have time to put your feet up on the dash before you go sailing through the windshield.