> agentic capabilities are very much on a roll-your-own-in-elisp basis
I use gptel-agent[1] when I want agentic capabilities. It includes tools and supports sub-agents, but I haven't added support for Claude skills folders yet. Rolling back the chat is trivial (just move up or modify the chat buffer), rolling back changes to files needs some work.
> It's definitely slower when doing any intensive background activities that Emacs would normally offload.
Emacs is single threaded and can't offload any elisp code. Even the stuff it can offload as background OS processes report in to the main loop and share time with editing, so a chatty background process can and does frequently lock up Emacs. So I'm surprised that VSCode, whose runtime is better suited to async jobs, ever feels slower than Emacs.
I think Neovim is more flexible -- a plugin you write for neovim can run in the terminal, in any Neovim GUI or in another application (like VSCode) that can embed Neovim.
I tried to use Neovim several times. However, it appears to not be very friendly for my usecase, which is using it with a Braille display. A lot of Neovim UI elements only use background/foreground color to indicate highlighted positions, instead of making use of the cursor. I couldn't even use the intial plugin menu. Emacs is much better in thsi regard.
pdf-tools is quite slow and a memory hog. emacs-reader is a replacement for it (still in development) that already blows every PDF reader I've ever used out of the water in performance:
> emacs org-mode: There is no live, inline LaTeX preview.
There is, but we haven't managed to merge it into Org mode yet because we (the feature authors) and the Org maintainer have been busy with other things.
Thanks! I followed the instructions to install it, they were super straight forward. This is exactly what I was looking for! Some notes:
- FYI there’s a typo in the docs of the sample use-package declaration, should be one dash instead of two in "org-latex-preview--mode”.
- Live preview works for me but only if I first do M-x org-latex-preview, it doesn’t do it automatically. Probably an issue of missing config on my end, but I haven't been able to figure it out yet.
- Unrelated issue is that org-cdlatex isn’t recognizing \begin{array} as math, e.g. it is inserting text mode latex there instead of math mode. No idea here, I don’t think I touched cdlatex from the built-in Doom Emacs version.
Unfortunately I’m out of time to spend configuring emacs… I’ll have to continue using Obsidian for now, but this is really cool! Hopefully I’ll have some time to come back to configuring emacs soon
> Live preview works for me but only if I first do M-x org-latex-preview, it doesn’t do it automatically.
Not an error on your end. Live previews for _new_ fragments are only supported when entering \[..\] and \(..\) delimiters, and not $..$ and $$..$$. With the latter you'll have to preview it manually once, and live previews will update from then on.
Is there _any_ other example? For years now, this is the only one I've ever seen brought up to support this point.
On the other side, there are many MacOS-specific features supported by Emacs, with the recently added dictation support being one of them. If a MacOS feature is missing, it's much more likely to be due to a lack of manpower than a desire to maintain feature parity with Linux.
For the entire 10 years I was a Mac user, a Japanese professor named Mitsuharu maintained a fork of Emacs with MacOS-specific features. I never came across any explanation for why the Emacs project didn't accept his changes (i.e., why he needed to maintain his own fork) other than some maintainers' wanting to discourage the use of non-Free OSes.
The good news is that this fork was very competently maintained, so I had a good experience in Emacs on OS X.
The 2 or 3 times I tried "vanilla" Emacs (the one published on fsf.org) it had bugs that weren't present in Mitsuharu Emacs. One of those times vanilla Emacs did not work at all: it displayed a window, but the window was very small (i.e., incapable of displaying more than a few characters) and the usual ways of enlarging a windows on OS X had no effect. My (typing blindly) evalling (set-frame-parameter frame 'fullscreen 'maximized) also had no effect.
The homebrew package named "emacs" got you vanilla Emacs. To get Mitsuharu Emacs, you needed to install the homebrew package named "emacs-mac" instead.
Maybe vanilla Emacs got better on OS X during the past 4.5 years. I haven't had access to a Mac during that time.
I have my own story over here[0], and I’m pretty sure that there’s going to be a lot of instances similar to what I’ve experienced — blocked from merging or just fizzling out due to the lack of push on features that work on non-free OSes. There’s a reason why there are so many forks and patches for Emacs on macOS that are maintained for years that are not getting upstreamed.
This is the only one that has bitten me personally, but I probably only noticed it because it was working and then taken away. I just assume there are more instances where something was never implemented in the first place for a political reason.
Edit: I also remember hearing that for a long time an ffi was forbidden because someone could use it to call proprietary software. Don't have a source on that one though.
> tried all the fancy context management stuff multiple times, but I mostly just have a chat buffer open and copy paste stuff manually.
As of last week you can insert a link to a plain-text file in a chat buffer to include its contents in the prompt. It must be on a line by itself. In Markdown it looks
[like this](/path/to/file)
with Org links in Org chat buffers.
This feature is disabled by default to minimize confusion. To enable it you can flip the header line button that says "ignoring media" to "sending media". This works for sending images and other media too, if the model supports it.
Do Cursor and co have better tools than the ones we write ourselves for lower-level interfaces like gptel? Or do they work better because they add post-processing layers that verify the state of the repo after the tool call?
Cursor is proprietary, but is known to index code for doing queries etc.
Cline is closer in spirit to GPTel, but since CLINE is an actual business, it does seem to do well off the bat. That said, I haven't found it to be "hugely better" compared to whatever you can hack in GPTel.
Quite frankly being able to hack the tools on the go in Elisp, makes GPTel far far better (for some of us anyway).
I use gptel-agent[1] when I want agentic capabilities. It includes tools and supports sub-agents, but I haven't added support for Claude skills folders yet. Rolling back the chat is trivial (just move up or modify the chat buffer), rolling back changes to files needs some work.
[1] https://github.com/karthink/gptel-agent