radian-software / radian

🍉 Dotfiles that marry elegance and practicality.
MIT License
490 stars 47 forks source link

use-package with a local file #469

Closed haji-ali closed 3 years ago

haji-ali commented 3 years ago

I am migrating from Doom to Radian (trying to get closer to a pure Emacs experience since Doom is becoming too complicated/obscure for me).

I have multiple personal package that I defined in separate files in my emacs directory and I was able to load them in Doom using use-package. I tried loading them similarly in Radian as follows:

(radian-local-on-hook
    after-init
(add-to-list 'load-path (concat user-emacs-directory "/lisp/"))

(use-package 'al-mu4e  ;; My personal package to configure mu4e
   ;;  etc
))

This worked in Doom but in Radian I get the error error: Could not find package al-mu4e in recipe repositories: (org-elpa melpa gnu-elpa-mirror el-get emacsmirror-mirror). If I use (require 'al-mu4e) instead, everything works but I want to use use-package for the extra features.

Am I doing something wrong? Also, is this the correct way to write/load modular configuration in Radian?

raxod502 commented 3 years ago

Pass :straight nil as an argument to use-package, or use use-feature instead, which does this automatically.

is this the correct way to write/load modular configuration in Radian?

Splitting your local configuration across multiple files has the disadvantage that it's not byte-compiled, but if you're fine with that then it works perfectly well. It's really up to you.

haji-ali commented 3 years ago

Pass :straight nil as an argument to use-package, or use use-feature instead, which does this automatically.

Oh, thank you! I am not sure how Doom manages to have use-package working even when not passing :straight nil. In any case, I find it strange that :straight nil is not the default option and that even without a :straight argument, straight changes the behaviour of use-package. But I don't know enough about the internals of straight and this has probably been discussed before.

EDIT: Please disregard this comment, I started reading the radian source code (a pleasant reading as usual) and I found this is related to straight-use-package-by-default being t.

Splitting your local configuration across multiple files has the disadvantage that it's not byte-compiled, but if you're fine with that then it works perfectly well. It's really up to you.

I am assuming you mean it's not byte-compiled by Radian but would work if I byte compile my config myself.

haji-ali commented 3 years ago

Splitting your local configuration across multiple files has the disadvantage that it's not byte-compiled, but if you're fine with that then it works perfectly well. It's really up to you.

@raxod502, I actually have another question about this.

In one of my modules, I use

(eval-when-compile (require 'org-archive))

But when I then run emacs I get the non-fatal error Eager macro-expansion failure: (wrong-number-of-arguments (3 . 7) 0)

I am sure this is the source of the error since it disappears if I comment out eval-when-compile. Is this expected? Should I be concerned?

raxod502 commented 3 years ago

I am assuming you mean it's not byte-compiled by Radian but would work if I byte compile my config myself.

Yes, that's correct. You'll just have to take care of it yourself, whereas it's automatically recompiled asynchronously on changes if you let Radian do it. Of course you could set it up to work automatically yourself as well.

Eager macro-expansion failure

Unfortunately that can mean any number of things; byte-compilation in Emacs has very unintuitive failure conditions which often require "institutional knowledge" to debug successfully. I would suggest enabling debug-on-error and you may be able to obtain a stack trace.

haji-ali commented 3 years ago

Hmm... Setting debug-on-error did not produce a stack trace. If this is not a known issue I will try investigating more to try and pin down the issue.