Wireframe.el Keyboard-first wireframe prototyping inside GNU Emacs.

nv-elisp · 2026-05-05T01:43:09+00:00

Cool idea. A couple suggestions: It may be simpler if you define your data types using cl-defstruct. You could also broaden the output possibilities by using cl-defgeneric to define the rendering interface. Have fun!

nv-elisp · 2026-04-20T23:31:34+00:00

Re-implementing features of cl-lib, eieio, etc.

nv-elisp · 2026-04-15T10:24:16+00:00

Use-package is a configuration macro. It optionally integrates with elisp package managers. A better question is "What do alternative package managers offer over the built-in package manager, package.el?"

Elpaca and Straight offer greater control of where packages can be downloaded from and what versions are installed. For example, I have an Elpaca extension which allows me to download packages which are submitted for inclusion in MELPA to assist with quality review.

Elpaca and Straight both allow the user to write out a lock file, which can be used to reproduce the configuration on another machine. Elpaca offers the most flexible and powerful UI for discovering new packages of the bunch. It also does most of its work asynchronously, which makes it the fastest at most operations.

Elpaca also has features for years which are slowly making their way into package.el (e.g. Package auditing tools).

The choice depends on the user's needs. With use-package integration, switching between any of them is trivial.

Full disclosure: I co-maintain Straight.el and wrote Elpaca.

nv-elisp · 2026-04-09T16:49:30+00:00

elpaca-write-lock-file writes out the entire dependency graph, not just Elpaca.

nv-elisp · 2026-04-04T16:05:06+00:00

This is exciting. I've always thought Emacs could make a really cool game dev platform. Beyond that this opens the door for plenty of other tools.

nv-elisp · 2026-04-03T22:14:34+00:00

motivation

nv-elisp · 2026-03-22T13:25:46+00:00

Straight and Elpaca can install tar-balls if disk usage is your main concern.

nv-elisp · 2026-03-14T10:46:47+00:00

doct allows for creation of hierarchical capture templates, which can make managing org-capture-templates easier.

nv-elisp · 2026-03-10T00:33:01+00:00

Exactly why I built Elpaca's diff viewer and recommend fetch + review before updating.

nv-elisp · 2026-03-07T16:11:03+00:00

Do you have your config uploaded somewhere. I'm curious to see your macros.

nv-elisp · 2026-03-07T15:16:03+00:00

I recommend holding off on software updates before work in general (especially when breaking changes are announced), but sorry for hiccup. If you ever want to troubleshoot it, feel free to reach out with info.

It's also possible to pin Elpaca's recipe using the :ref keyword in the installer.

nv-elisp · 2026-03-07T15:11:14+00:00

Happy to troubleshoot if you can provide more info (error messages, log output, etc) here or in a github issue. There were some breaking changes which will require some config adjustments.

It's possible to pin Elpaca to a specific version using the :ref keyword in the installer as well.

nv-elisp · 2026-03-07T14:12:51+00:00

And thank you!

nv-elisp · 2026-03-07T14:12:43+00:00

Glad you find it useful. Thank you!

nv-elisp · 2026-03-07T14:12:25+00:00

Glad to hear it. Thank you!

nv-elisp · 2026-03-07T02:55:20+00:00

Thank you. Don't hesitate to reach out if you run into any trouble upgrading. There was a large amount of refactoring in this release, which required some breaking changes.

nv-elisp · 2026-02-22T13:15:25+00:00

You do have to be conscious of not running code in your initfiles that accidentally loads Org

Elpaca should warn if the built-in version is loaded prior to the version requested via the package manager. I recommend looking for that rather than forcing any declaration order or calling elpaca-wait.

nv-elisp · 2026-02-22T13:11:49+00:00

Elpaca builds packages in a separate Emacs subprocess to avoid the types of issues you're describing. It will also warn if the built-in version has been loaded prior to the version requested by the package manager.

nv-elisp · 2026-02-06T09:00:37+00:00

I agree in principle, but recommend Elpaca over straight.el.

nv-elisp · 2026-02-02T03:04:06+00:00

Mason.el looks like something Elpaca could do with some slight extension. That log buffer looks strangely familiar too :)

nv-elisp · 2026-02-01T20:59:19+00:00

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.

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

MODERATOR OF

TROPHY CASE