@karthink@fosstodon.org, @yantar92@fosstodon.org and I took over as maintainers of the Elfeed, the Emacs feed reader!
Remote
Daniel Mendler
@minad@mastodon.world
mastodon 4.7.3338 Followers
37 Following
26 Posts
Joined November 30, 2025
Today I have released version 4.0.0 of Elfeed, the Emacs feed reader.
The release includes many new features, bug fixes and improvements across all parts of the package. Take a look at the extensive changelog:
https://github.com/emacs-elfeed/elfeed/blob/main/NEWS.org#version-400-2026-06-06
The commit:
https://github.com/emacs-elfeed/elfeed/commit/d9ec8b93a61f6653bf9bcc929dbfa5e49133d37f
I have just added a new feature to my Jinx spell-checking package. The new command jinx-remove-word removes words from the personal dictionary, file-local variables and so on. Reuben Thomas (the maintainer of the Enchant library backing Jinx) suggested this addition. He is also an #emacs and #jinx user!
https://github.com/minad/jinx/discussions/269
So glad that MELPA is getting a new versioning scheme, such that all ELPA snapshot archives become compatible. Snapshot package versions have the form release.0.date.count, starting with the version number of the last release.
https://snapshots.melpa.org/
https://releases.melpa.org/
#doom running on #emacs via the canvas API
https://github.com/minad/doom-on-emacs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=80281
Find the mistake! #emacs
Replying to
The thing is - one of the affected #emacs package maintainers @tarsius@fosstodon.org has stated explicitly that he wants to continue maintaining his package transient as is, with the cond-let dependency. Like it or not. I think Emacs package maintainers should retain their freedom to maintain packages in a way which they see fit, giving them the chance to experiment and advance Elisp (dash, llama, cond-let, whatever, ...).
Please consider enabling `package-review-policy` on Emacs 31, and help reviewing package updates.
This will help to catch supply chain attacks on the Emacs package archive like this one:
https://github.com/kubernetes-el/kubernetes-el/commit/09e06af093bc3b5c98076177c359b812f86d371f
Emacs doom scaling
The canvas has an original size of 320x200 and is scaled up by Cairo or XRENDER. Works better than expected.
Replying to
@yantar92@fosstodon.org Another bottleneck are function calls. Automatic inlining is not possible, since advices can hook into each function. Even pure code can suddenly become effectful.
@screwlisp@gamerplus.org @marcoxa@mastodon.social @mdhughes@appdot.net @me
Replying to
@jameshowell@fediscience.org Embark is easy to get started with. For example move point to a symbol and run M-x embark-act. It should display the available actions. If you want to invoke the standard action, e.g., jump to symbol, invoke M-x embark-dwim on a symbol to point. Of course Embark recognizes many more object types at point than symbols. This means we get lots of context dependent commands.
@oantolin@mathstodon.xyz
Replying to
@tchauhan@mastodon.mit.edu What do you find difficult about Cape?
Cape basically provides a bunch of completion backends, so called Capfs. You can either add the Capfs to the completion-at-point-functions list, or invoke them directly, for instance M-x cape-emoji or M-x cape-file.
Another way to think of it - Cape is to Corfu what Consult is to Vertico.
Replying to
@lens_r@mastodon.social I think I don't have any other #emacs merch than the cup, but this one has survived for many years.
Replying to
@tusharhero@mathstodon.xyz I wasn't working on a full drawing API. The feature that I actually wanted to propose was a "memimage", since this enables plenty of use cases. So this was kind of a miscommunication from my side when I initially called the feature "canvas". A full drawing API could then be implemented on top. We could try multiple different APIs, since there are many different high-quality drawing libraries we could take advantage of. See https://yhetil.org/emacs-bugs/87jyuux3qx.fsf@daniel-mendler.de/
@pkal@social.sdfeu.org @divyaranjan@mathstodon.xyz
@mekeor@mastodon.catgirl.cloud @tusharhero@mathstodon.xyz @divyaranjan@mathstodon.xyz As long as Gtk depends on Cairo, Emacs can continue to use it. But of course it is possible to replace it if necessary. The canvas intentionally only gives access to a simple pixel buffer. Right now it works with and without Cairo on X. I did not test other platforms.
Replying to
@tchauhan@mastodon.mit.edu @jameshowell@fediscience.org @oantolin@mathstodon.xyz You could try Drepl for a Python REPL with better completion. I have not used it so far, so I don't know how well it works in practice.
https://github.com/astoff/drepl
Replying to
@tchauhan@mastodon.mit.edu cape-dabbrev is similar to dabbrev-capf, but a little more polished. dabbrev-capf had bugs in the past, but I think they are fixed at least in Emacs 31. Regarding Python REPL completion I cannot help. All I know is that the Capf is broken. @jameshowell@fediscience.org @oantolin@mathstodon.xyz
Replying to
@oantolin@mathstodon.xyz I use consult-history for both (repl and minibuffer), but mainly because I've bound it to the more convenient key (M-r).
@tchauhan@mastodon.mit.edu @jameshowell@fediscience.org
Replying to
@tchauhan@mastodon.mit.edu Another example is cape-history vs consult-history, which you can use in Comint, Shell or Eshell buffers. cape-history displays the candidates via in-buffer completion (e.g. Corfu) while consult-history displays the candidates via completing-read (e.g. Vertico).
@jameshowell@fediscience.org @oantolin@mathstodon.xyz
Replying to
@jameshowell@fediscience.org I definitely recommend to add Embark to the mix. Embark is like a left click or right click menu for objects at point (or in the completion minibuffer), but keyboard driven. @oantolin@mathstodon.xyz
Replying to
@shegeley@fosstodon.org Too bad. I am working on Emacs with the goal of making it better, such that we don't have to hate it as much. Maybe it is hopeless. ;)
Replying to
@divyaranjan@mathstodon.xyz Sounds like a good compromise. @tusharhero@mathstodon.xyz @pkal@social.sdfeu.org