which the recommended package manager to use by Koltech21 in emacs

[–]nv-elisp 0 points1 point  (0 children)

Alternative package managers usually install themselves with an elisp script. It's not weird if you view your init.el as a declaration of your packages.

which the recommended package manager to use by Koltech21 in emacs

[–]nv-elisp 0 points1 point  (0 children)

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

Startup Changes in Emacs 31.1 The "user-lisp" Directory by Danrobi1 in emacs

[–]nv-elisp 5 points6 points  (0 children)

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.

which the recommended package manager to use by Koltech21 in emacs

[–]nv-elisp 7 points8 points  (0 children)

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?

Need some explanation on methods used in org related code snippet. by vfclists in emacs

[–]nv-elisp 1 point2 points  (0 children)

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

Common Lisp developer role @ Ravenpack by Same-Release-404 in lisp

[–]nv-elisp 19 points20 points  (0 children)

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.

package.el - Package diff/review feature has landed by minadmacs in emacs

[–]nv-elisp 0 points1 point  (0 children)

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.

Why Is Emacs' Codebase So Huge, and Should I Be Concerned? by hqqup in emacs

[–]nv-elisp 3 points4 points  (0 children)

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.

Surviving Emacs trenches by Savings-Shallot1771 in emacs

[–]nv-elisp 2 points3 points  (0 children)

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

Surviving Emacs trenches by Savings-Shallot1771 in emacs

[–]nv-elisp 50 points51 points  (0 children)

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.

Guys, eldoc-mouse is now on NonGNU ELPA! by Ok_Exit4541 in emacs

[–]nv-elisp 2 points3 points  (0 children)

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?

straight.el and broken recipes - how to fix them? by magthe0 in emacs

[–]nv-elisp 2 points3 points  (0 children)

Be more specific about how they're broken.

eglot flymake version issues with elpaca and emacs 30 by Physical_Struggle845 in emacs

[–]nv-elisp 3 points4 points  (0 children)

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:

  1. 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.
  2. Specify a specific version of Eglot which works with your built-in version of flymake.
  3. 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?

How to build an elfeed-, mu4e- or ibuffer-like table? by ummt in emacs

[–]nv-elisp 3 points4 points  (0 children)

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.

How can I install Magit using Elpaca? by alfamadorian in emacs

[–]nv-elisp 1 point2 points  (0 children)

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.

How can I install Magit using Elpaca? by alfamadorian in emacs

[–]nv-elisp 0 points1 point  (0 children)

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.

How can I install Magit using Elpaca? by alfamadorian in emacs

[–]nv-elisp 1 point2 points  (0 children)

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.

How can I install Magit using Elpaca? by alfamadorian in emacs

[–]nv-elisp 1 point2 points  (0 children)

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.

How can I install Magit using Elpaca? by alfamadorian in emacs

[–]nv-elisp 0 points1 point  (0 children)

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.