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.
On macOS some of the Emacs keybindings also work system-wide. You can e.g. use C-a/e, C-k, and C-n/p/f/b in every macOS text field, like e.g. in browser text fields. This is one of the main macOS features I miss on GNU/Linux. (Actually, that subset of Emacs keybindings even works on iPad with an external keyboard.)
Aside from keybindings, there are also some packages that provide deeper integration with macOS. For example, org-mac-link can save Org-mode links to currently open emails in Mail.app. And the built-in `C-x m` can author emails that are then sent to Mail.app for further processing, if you’re not able to use mu4e and similar (e.g. strict Exchange email servers).
> 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.
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.
How does eat detect a visual command in eshell? I use vterm in Emacs for visual commands like nvim and htop. But it's triggered manually with a simple custom prefix command (just 'v') added to the actual command. I wonder if that trigger could be automated. It sounds from your description like vterm is faster than eat. If so, a similar automatic trigger for vterm could be very beneficial.
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.
Visual commands only differs from normal commands by the escapes code they use (like enabling the alternate buffer, clearing the screen,..). Eshell can't deal with those (and shouldn't as it's a shell, not a terminal). Eat adds a layer that does process those escape codes and that's all you need to handle visual commands.
> 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.
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.
reply