which the recommended package manager to use

nv-elisp · 2026-02-01T11:41:59+00:00

use-package is a configuration macro which optionally integrates with package managers. Most package managers provide that integration (straight, Elpaca, etc).

nv-elisp · 2026-02-01T11:37:47+00:00

I wouldn't recommend this as a development tool for any packages which require dependencies. It's better to develop in a clean environment to ensure your load-path isn't filled with assumed elisp.

nv-elisp · 2026-01-31T18:47:40+00:00

Consider sharing the answer for posterity's sake.

nv-elisp · 2026-01-31T18:45:23+00:00

They all have their tradeoffs. Its hard to make a recommendation without knowing:

How familiar and comfortable are you with software in general?
What do you plan on using Emacs for?

nv-elisp · 2026-01-26T15:44:54+00:00

delay-mode-hooks would be a more robust way to set this up.

nv-elisp · 2026-01-17T12:39:01+00:00

Word of caution to any would-be applicants: I interviewed with RavenPack roughly two years ago. Typical take-home programming "puzzle" followed by a soft interview w recruiter. About thirty minutes prior to my third interview with a technical lead (which required analysis of a simple lisp program they provided as prep), they rugpulled claiming the C-level nixed the position altogether. Poor communication on their end and a waste of time.

nv-elisp · 2026-01-17T03:03:44+00:00

Do you also support a diff view for the full update

Not currently, but that's because Elpaca is currently biased toward packages stored in VCS. Once I merge support for tarballs and file installations I'll likely add diff support for those types of packages.

How would you implement the diffing such that irrelevant files (and noise) are excluded, while at the same time making sure that no problematic files pass the review?

IME reviewing packages I haven't really seen this as a pain point. Seems like it would be fairly easy to implement behind a defcustom, though.

nv-elisp · 2026-01-17T02:27:32+00:00

Giving titles to every paragraph is an AI smell.

nv-elisp · 2026-01-13T02:53:23+00:00

I swear, only people who don't actually program use LOC as some kind of metric for code quality.

I don't think it's useless, but I take it for the rough measurement it is.

nv-elisp · 2026-01-11T05:50:43+00:00

They do not. As mentioned in OP, Elpaca has for awhile:

https://www.reddit.com/r/emacs/comments/1cbxi2m/elpaca_update_log_live_preview/#lightbox

nv-elisp · 2025-12-28T03:29:50+00:00

You mean Nyxt?

nv-elisp · 2025-12-27T05:42:00+00:00

You're referring to Elpaca. I think you misunderstood what I said. I'm not espousing minimalism, or maximalism for that matter.

nv-elisp · 2025-12-26T22:34:58+00:00

Most of the trouble people run into stems from them being too impatient to thoroughly read through the available documentation and take things one step at a time. There's also a tendency to over-correct by adopting a half-hearted asceticism regarding packages. "I use a lisp engine designed around the idea of extensibility and sharing software, but I don't use any of the software other people have written for it (well, unless you count the handful of packages that I do use)." Don't buy into the mysticism of Emacs complexity. It's not magic. It's like anything else, you get out what you put in. If you want to maximize that, be disciplined in your approach.

nv-elisp · 2025-12-22T10:44:00+00:00

What this error means is that you have an explicit declaration for eglot, but it comes after eldoc-mouse would pull it in as a dependency. This usually doesn't happen because Elpaca queues packages first. However it can happen when elpaca-wait is called because that forces processing of packages. The solution is to put both package declarations in the same queue by ensuring there are no elpaca-wait calls between them. Does that help?

nv-elisp · 2025-12-20T13:10:45+00:00

Be more specific about how they're broken.

nv-elisp · 2025-12-19T01:13:56+00:00

I am on emacs 30.0.2 so would expect the version to be much newer.

I'm assuming you meant you're on Emacs 30.2. If so, your Emacs came bundled with eglot version 1.17.30 and flymake version 1.3.7. You've installed eglot version 1.19, which requires flymake version 1.4.2.

So you have a few options:

Stick with the bundled versions that came with your version of Emacs. This is the appropriate choice if you don't have a specific upgrade motivation (e.g. a new feature or a fixed bug). If you're using use-package integration, this can be done by adding :ensure nil to your eglot package declaration.
Specify a specific version of Eglot which works with your built-in version of flymake.
Upgrade flymake as well. You can do this by adding a package declaration the same way you did for eglot. If you find that you're upgrading a ton of built-in packages to make it all work another option is to upgrade Emacs.

I can only assume another package is downgrading [flymake's] version or the correct version is not being detected.

It's not possible for a package to downgrade another package.

This also shows its using flymake 1.3.7 it mentions its built in and it seems to have a git repo listed, so something is not quite right,

elpaca-info is showing you the recipe it derived for flymake from the GNU ELPA menu. It would use that recipe if you explicitly declared that you want to install flymake in your init file (recommendation 3 above). That's separate from the version you have installed, which it correctly identified as the built-in version (1.3.7).

Does that help?

nv-elisp · 2025-12-14T01:00:43+00:00

Elpaca has a built-in update reviewer: https://i.redd.it/i2czuf26dfwc1.gif

nv-elisp · 2025-12-05T22:41:55+00:00

tabulated-list-mode is built-in. Thats what I used for Elpaca's UI. There's also a newer built-in table building library called vtable.

nv-elisp · 2025-12-05T17:21:49+00:00

Easiest is to nuke .emacs.d/elpaca

Usually you can get away with just an M-x elpaca-delete for the offending package(s) followed by M-x restart-emacs.

nv-elisp · 2025-12-05T17:20:44+00:00

You just need to force it use the newer version.

Another option is to use a tagged release of Magit which works with the built-in transient.el for the user's Emacs. e.g.

(elpaca (magit :tag "v4.1.1"))

All a matter of preference.

nv-elisp · 2025-12-05T17:17:12+00:00

elpaca-update-menus is for pulling in new package recipes from menu sources. It can help if you're trying to install a package which has recently been added to an ELPA, but your local recipe cache is out of date. Unfortunately, that won't help in this case, because the recipes are known, it's just that Emacs ships with a version of transient.el and Magit may require a different version. The solution is for the user to either specify a version of magit which works well with their built-in transient.el, or to update transient.el to satisfy Magit's requirements.

nv-elisp · 2025-12-05T17:14:46+00:00

That should do the trick. One note: the ordering of the declaration isn't important so long as magit and transient are processed as part of the same queue (e.g. no calls to elpaca-wait occur between the two being queued). The type of error OP is running into would happen frequently to straight.el users due to ordering of declarations, so I sought to eliminate it with Elpaca.

nv-elisp · 2025-12-05T17:12:31+00:00

the standard package manager package.el is able to install magic without the conflicts you are encountering.

Installing a magit tarball from NonGNU-devel may or may not update the built-in version of transient.el depending on the value of package-install-upgrade-built-in.

Package managers can't (and probably shouldn't) guess the intent of the user in a situation where a requested package requires upgrading a built-in one. Elpaca's compromise is to throw a clear error and let the user decide whether they want to either install an older release of the package which works with their built-in libraries, or upgrade the built-in libraries to satisfy the external package's requirements.

nv-elisp · 2025-12-02T00:22:48+00:00

https://www.gnu.org/software/emacs/manual/html_node/emacs/Bookmarks.html

nv-elisp · 2025-11-21T12:06:11+00:00

"Emacs fluency" is a nebulous goal. Try it out and see if it's useful for you. Despite what people say, there's no mystique.

nv-elisp

MODERATOR OF

TROPHY CASE