karthink

How do you sync your google calendar with org-agenda?

Once you hook up elisp evaluating MCP to your Emacs

gptel-agent ships with an elisp-eval tool out of the box, BTW.

As a clarification, you don't need elfeed-tube to subscribe to YouTube feeds (channels or playlists) with elfeed, or to watch the videos with mpv. elfeed-tube only adds text to the feed entries, in the form of more video metadata, transcripts and synced playback with mpv.

Also, mpv supports lua scripts for a variety of actions on YouTube (or other streaming) videos, such as showing you YouTube's recommended videos in the video player, clipping and downloading videos, sponsorblock and submitting sponsorblock segments, and so on.

I've been doing this for almost a decade, and I do recommend it. In my experience, just importing my YouTube subscriptions into a feed reader was a positive experience. I've had a daily digest of mostly interesting videos and rarely (if ever) the urge to browse YouTube.

But with YouTube's recommendation algorithm out of the picture, it does mean that you'll have to find some other way of discovering new channels.

It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.)

...

One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.

I started using Emacs on a Mac recently and was pleased to discover that it is, in fact, consistent with other programs.

- Cmd-C/X/V work as expected (copy/cut/paste from system clipboard)

- Cmd-Z undoes,

- Cmd-O brings up the open-file dialog, Cmd-T opens a new tab,

- Cmd-F invokes search and Cmd-L goes to line, and so on.

It uses the same global menu bar as other programs, and setting the font from the menu works. The only thing that didn't work is using Cmd-Shift-? to search through menu bar options. This is GNU's official MacOS build, not the custom-built emacs-mac or emacs-plus packages.

Last year I helped a non-programmer get started with Emacs (for the first time) on a Mac. After a couple of weeks their only remarks were that the customize interface looks a little dated and the config/custom file has a weird format. They never brought up the keybindings or other UI as an issue. Now I understand why -- Emacs is a reasonably good citizen on MacOS.

In the meantime we're all stuck waiting for package downloads.

I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates.

package.el is catching up to Elpaca in features, but async installs/updates is not one of them.

https://github.com/progfolio/elpaca

There's some miscommunication here.

How does eat detect a visual command in eshell?

eat-eshell-mode doesn't detect visual commands and launch a separate eat buffer, like eshell-visual-commands do. It filters all process output in eshell and handles term codes. It turns the eshell buffer itself into a terminal, so that vim or whatever runs in eshell.

It sounds from your description like vterm is faster than eat.

vterm is faster than eat, but a dedicated eat buffer is fast enough for most common TUIs. An eshell buffer with eat-eshell-mode is slower.

You have to turn on eat-eshell-mode to enable Eat's terminal emulation in eshell.

It runs full-fledged TUIs like vim and ncmpcpp in Eshell slowly, but is good enough for quick fzf uses. It's perfectly fine for "small" dynamic elements like the spinners and progress bars used by package managers.

Just remember to use system pipes (with "*|") instead of Elisp pipes (with "|") if you're piping data into an interactive TUI application like fzf in Eshell.

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.

[1] https://github.com/karthink/gptel-agent

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.

pdf-tools in Emacs is much faster

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:

https://tv.dyne.org/w/wcedffVATJGwLSCqta6pk1

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.

Fixed the typo, thank you for reporting it.

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.

Here are some screencasts:

- https://share.karthinks.com/olp-auto-mode-env-1.mp4

- https://share.karthinks.com/olp-auto-mode-inline-1.mp4

Here's a longer explainer (this is part 2/2): https://www.youtube.com/watch?v=u44X_th6_oY

Here are instructions if you want to try the fork of Org mode that provides this feature: https://abode.karthinks.com/org-latex-preview/

would be happy if I could also trim the video while I am at it.

You can, see the command subed-crop-media-file.

https://github.com/sachac/subed/blob/main/subed/subed-common...

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.

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?

I would be interested especially in Emacs integrations.

gptel can use MCP server tools in Emacs by integrating with the mcp.el package, here's a demo: https://i.imgur.com/WTuhPuk.mp4.

mcp.el: https://github.com/lizqwerscott/mcp.el

Relevant gptel README section (you'll have to unfold the details block): https://github.com/karthink/gptel?tab=readme-ov-file#model-c...

I'm curious to know if this is what lproven meant in their comment above. Alt + a-z to access menu items is available in every OS and all "native" apps, but you can't "drive the OS and all apps" this way.

For example, I would like to set options that are a few menus/button clicks deep in the Windows control panel (either the "classic" or new variant) using keyboard shortcuts/navigation. Or navigate the Windows registry editor. I'm not aware of a way to do this.

Learn Windows' keyboard UI and you can drive the whole OS and all its apps with the speed of a genius Vim user

Do you have a reference for this? I've often needed to control Windows using only a keyboard and failed to do so. I'm aware of most shortcuts in this list[1] but these are for a few very specific things. (As an aside, I also remember controlling the mouse with the numpad using the Mouse Keys accessibility setting but this is worse than both keyboard shortcuts and the mouse.)

[1] https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts

I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.

Everyone including the maintainers would like this to happen. The arguments against it are technical hurdles. Emacs is a large ball of global state and the lisp evaluator hooks into everything, including the display engine, so it's not clear to anyone how to disentangle things to the point where the interpreter lock can be released.

It's the one powerful feature that has yet to be replicated in Emacs.

Emacs cannot do this. There are many Emacs libraries or packages that need this feature (Org babel is a big one, transclusion is another), and have to work around its absence in hacky ways.

You didn't mention a mobile app or cloud sync as one of your priorities, so any offline, desktop RSS feeder should provide most of these features.

I use Elfeed in Emacs, which satisfies all your requirements -- except bypassing paywalls -- and is the best RSS reader I've ever used. For context, I've used at least ten RSS readers since 2005 before finding Elfeed in 2018.

Removing the interpreter lock for a few specialized tasks (without sweeping runtime changes to Emacs) would be enough to fix most of these issues -- parsing JSON from process output into lisp data in a background thread is one candidate. [1]

Installing packages does not need to block either, there is no architectural limitation here. The Elpaca package manager for Emacs provides async, parallel package updates. Loading packages into the Lisp image will block though, there's no way around that.

The other big source of input lag is garbage collection, and there are some ongoing efforts to use the MPS library in Emacs for a copying, concurrent GC. This is a big change and I don't know if this experiment will go anywhere, but Eli Zaretskii and co are trying.

[1] https://github.com/emacs-lsp/emacs

Something this old shouldn't have this property.

It's not an accident -- reading through the emacs-devel mailing list, it's easy to see how much effort the maintainers pour into backward compatibility. It's one of Emacs' unspoken guiding principles[1].

At the same time, it's not that surprising either. Emacs does not have other objectives that more modern languages/ecosystems do: no revenue or growth targets, corporations or VCs breathing down its neck, or a mandate to be "modern". Its most vocal and experienced users, who are also its volunteer maintainers, decide what its priorities should be. Since they've been using it for decades, backward compatibility is high on the list.

[1]: It's "spoken" guiding principles being to further the goals of the GNU project.

For a REPL-like interface, you could try the chatgpt-shell package. It can execute code generated by the LLM. It too does this by using org-babel though, it just calls org-babel functions under the hood. It's also OpenAI-only right now, although the author plans to add support for the other major APIs.

gptel has a buffer-centric design because it tries to get out of your way and integrate with your regular Emacs usage. (For example, it's even available _in_ the minibuffer, in that you can call it in the middle of calling another command, and fill the minibuffer prompt itself with the text from an LLM response.)

I think the web chat history is separate from API use, so you can't combine them. OpenAI claims not to retain a history of your API queries and responses.

For organizing LLM chat logs in Emacs, there are many solutions. Here are a few:

As a basic solution, chats are just text buffers/files, so you can simply store your conversations in files in a single directory. You can then see them in dired etc -- and they are ripgrep-able, can be integrated into Org-roam or your choice of knowledge management system.

If you use Org mode, you can have branching conversations in gptel where each path through the document's outline tree is a separate conversation branch. This way you can explore tangential topics while retaining the lineage of the conversation that led to them, while excluding the other branches. This keeps the context window from blowing up and your API inference costs (if any) down.

If you use Org mode, you can limit the scope of the conversation to the current heading by assigning a topic (gptel-set-topic). This way you can have multiple independent conversations in one file/buffer instead of one per buffer. (This works in tandem with the previous solution.)

-----

Tools tend to compose very well in Emacs. So there are probably many other solutions folks have come up with to organize their LLM chat history. For instance, any feature to handle collections of files or give you an outline/ToC view of your Markdown/Org documents should work well with the above -- and there are dozens of extensions like these.

You can add a prefix arg to replace the region with the result. (Any numeric prefix works, so I usually do M-0 M-| since that's easy to type with the meta key held down, and 0 and | are close together.)

Emacs can do that quite easily[1]. But this code is not merged into the trunk yet, it should be some time this year.

[1] https://share.karthinks.com/prog-preview-3.mp4

I am one of the authors, should have mentioned. It's not part of Org yet, but should be some time this year.