upvote
According to `git blame` the oldest surviving code in GNU emacs is:

    lisp/play/studly.el
being unchanged since 1986-09-12.

(It is said the Stallman maybe have kept some of Gosling's older code but I haven't gone back that far.)

reply
I like it infinitely more than anything, but it also still feels like a comparably slow, crufty pos that will probably die because of how anti-AI half the core community is. Regardless of how good magit is, it's slow.

I also can't understand how people like eca and agent-shell so much unless they've never actually used any decent harness. Neither seems to really fit with emacs. Acp is the exact opposite of extensible, and eca isn't really extensible either.

reply
[dead]
reply
Agreed with all of this! To date, agent-shell.el is my favorite AI coding experience.
reply
eca and gptel remain my main "bread-n-butter" atm.
reply
I'm using claude-code.el. What am I missing? (Aside from integration with other models of course).

I have used gptel a while ago which was great for completion-like workflow, but abandoned when I moved to more agentic stuff.

reply
The biggest value of gptel is its API. I can send a request anytime, anywhere, from pretty much any buffer. I sometimes ask things in the middle of typing a message, or I can ask a model to reword the prompt I'm about to send to another model.
reply
Doesn't work with my github enterprise with entra sso integration. I left a question on github gptel but no progress as of yet. That drove me to agent-shell which requires a cli but works.
reply
Yes, Emacs was designed almost perfectly 50 years ago to integrate with modern LLMs.
reply
We just got lucky. Emacs Lisp, unlike most other Lisps that are data-oriented is particularly text-oriented. If instead of LLMs we've gotten LGMs (Large Graphics Models), Emacs wouldn't have time to catch up and keep the pace with other graphics-oriented IGEs (that would've replaced IDEs)

Luckily (for us), Emacs is the king of text-processing and text manipulation.

reply
They had ELIZA and then the Emacs doctor, the rest is just scale.
reply
[flagged]
reply
I will say in regards to the electron editors, wrangling emacs frames and windows can range from a chore to painful. That is one area we can still improve on!
reply
I grokked display-buffer-alist and never had any problems since. With any other editor or IDE (and I used more than a few), it never occurred to me to even want to do anything complex with window placement. There are things I would love to see getting improved in Emacs, but managing windows and frames is not the one.
reply
I think your perspective is perfectly valid, and I'd never advocate for dumbing down display-buffer-alist, but I do think some sort of package which makes common buffer configurations easy for novices who haven't put the effort in would make a big difference without getting in the way for those who've already grokked it
reply
> some sort of package which makes common buffer configurations easy for novices

Experts often do forget their own "beginner's journey", but I honestly never remember struggling with where windows do appear in Emacs. Either because I never had any eccentric expectations of how this should work, or maybe because I had far bigger issues back in my beginnings. Maybe I didn't notice anything until I found Spacemacs, which had just started gaining some traction back then. I don't remember if they've done anything to improve beginner experience, but then, moving off Spacemacs I might have gotten annoyed, which iirc forced me to understand display-buffer-alist. And then trying Doom, I believe I had to explicitly disable all their novice-aimed improvements and rely on display-buffer-alist settings I was already comfortable with. So, I guess it's a difficult balancing game - need to make it intuitive for the beginners, while not screwing it up for the experts. I mean, if Emacs v32-33 ships with "improvements" that somehow mess with my display-buffer-alist, I'd probably get mad for like two minutes. But that's me, if anything like that to happen, I'm sure it will generate some 2000-message-long discussion thread on emacs.devel.

reply