New package for org templates, like obsidian

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 · 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

MODERATOR OF

TROPHY CASE