~abcdw/rde-discuss

4 2

Loading emacs configuration in order

Demis Balbach <db@minikn.xyz>
Details
Message ID
<87fsr70wx7.fsf@minikn.xyz>
DKIM signature
pass
Download raw message
Hello,

I was wondering how you would load different emacs-related features, more
specifically their configuration in order.

So let's say I have two features that both use
`elisp-configuration-service`. AFAIK, the order in which I place the
features in my config doesn't matter, because emacs will load all files
in `$EMACSLOADPATH` alphabetically (I think?).

I want my second feature to rely on the first. At the moment, what I do
in the second feature is this:

=2D-8<---------------cut here---------------start------------->8---
;;; ...
(elisp-configuration-service
emacs-f-name
`((with-eval-after-load
;;; TODO: Improve this. We need to load feature-emacs-leader-keys
;;; first, otherwise we'll get a non-prefix key error.
'configure-leader-keys-autoloads
;;; ...
=2D-8<---------------cut here---------------end--------------->8---

where `configure-leader-keys-autoloads' are the autoloads provided by
the other feature. This works, however, I was wondering if this is
intended or if there is a better way?

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach
Details
Message ID
<87a6he4b0j.fsf@trop.in>
In-Reply-To
<87fsr70wx7.fsf@minikn.xyz> (view parent)
DKIM signature
missing
Download raw message
On 2021-12-05 18:43, Demis Balbach wrote:

> Hello,


Hi!)


>
> I was wondering how you would load different emacs-related features,
> more specifically their configuration in order.
>
> So let's say I have two features that both use
> `elisp-configuration-service`. AFAIK, the order in which I place the
> features in my config doesn't matter, because emacs will load all files
> in `$EMACSLOADPATH` alphabetically (I think?).
>
> I want my second feature to rely on the first. At the moment, what I do
> in the second feature is this:
>
> =2D-8<---------------cut here---------------start------------->8---
> ;;; ...
> (elisp-configuration-service
> emacs-f-name
> `((with-eval-after-load
> ;;; TODO: Improve this. We need to load feature-emacs-leader-keys
> ;;; first, otherwise we'll get a non-prefix key error.
> 'configure-leader-keys-autoloads
> ;;; ...
> =2D-8<---------------cut here---------------end--------------->8---
>
> where `configure-leader-keys-autoloads' are the autoloads provided by
> the other feature. This works, however, I was wondering if this is
> intended or if there is a better way?

I'm not an Elisp guru, but it seems like a way to go.  The possible
problem I see: configure-leader-keys is not declared as a dependency for
your other configure package, which can result in build warnings.

Probably, it will be nice to add provide derective to every configure-*
package generated by elisp-configuration-service, so you can require
configure-something instead of configure-something-autoloads.  I haven't
had use cases, where one configure package depends on the other yet, so
the proper way to do it is still an open question.  

I have an idea on this matter: Split function for generating configure-*
package out of elisp-configuration service, to make it possible to share
this package as rde values to make it possible for other configuration
package to depend on it.  Yep, probably it's a way.

Also, I'm not sure if making configure-* packages is a good idea overall
and a proper way to structure rde config (it abuses ###;;;autoload and
violates some principles defined in elisp manual), but it works and
there are no any visible problems with it so far.

Thank you for bringing up this topic, I'll come back to it after
finishing feature-notmuch refactoring.

-- 
Best regards,
Andrew Tropin
Demis Balbach <db@minikn.xyz>
Details
Message ID
<87wnkf6q6z.fsf@minikn.xyz>
In-Reply-To
<87a6he4b0j.fsf@trop.in> (view parent)
DKIM signature
pass
Download raw message
Hello,

> I have an idea on this matter: Split function for generating configure-*
> package out of elisp-configuration service, to make it possible to share
> this package as rde values to make it possible for other configuration
> package to depend on it.  Yep, probably it's a way.

if I understood you correctly, this is exactly what I tried first. I
should have said that before.
I know what the problem is but I have trouble explaining it.

In my first feature (feature-emacs-leader-keys), the user can set some
values with keywords and the will get saved into the config with

--8<---------------cut here---------------start------------->8---
   (values `((emacs-leader . ,leader)
             (emacs-localleader . ,localleader)))
--8<---------------cut here---------------end--------------->8---

In my second feature (feature-emacs-files) I retrieve those values from
the config with

--8<---------------cut here---------------start------------->8---
`((let ((rde-leader ,(get-value 'emacs-leader config)))
--8<---------------cut here---------------end--------------->8---

However, with key bindings it's a bit diffcult in emacs, take this code
snippet for example:

--8<---------------cut here---------------start------------->8---
(setq rde-test-leader "M-SPC")
(define-prefix-command 'rde-test-map)
(global-set-key (kbd (concat rde-test-leader " f")) 'rde-test-map)
--8<---------------cut here---------------end--------------->8---

The first line I will set in (feature-emacs-leader-keys), write it to
the config and use get-value in the other feature to use it (like in the
third line).

However, if you execute those three lines in a scratch buffer, you'll
get the error `global-set-key: Key sequence M-SPC f starts with
non-prefix key M-SPC'

I'm not exactly sure where this error comes from, but I can remedy it if
I start the three lines above with `(setq rde-test-leader nil)'. So this
is something I do in (feature-emacs-leader-keys).

This is no problem regarding rde, everyting works, but here is the
problem... because the elisp code from (feature-emacs-files) gets loaded
before (feature-emacs-leader-keys), the expression (setq rde-test-leader
nil) hasn't been evaluated yet, and I run in the error I mentioned.

I hope you understand the problem. Again I had trouble explaining it.

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach
Details
Message ID
<87ee6lg4q4.fsf@trop.in>
In-Reply-To
<87wnkf6q6z.fsf@minikn.xyz> (view parent)
DKIM signature
missing
Download raw message
On 2021-12-08 17:01, Demis Balbach wrote:

> Hello,
>
>> I have an idea on this matter: Split function for generating configure-*
>> package out of elisp-configuration service, to make it possible to share
>> this package as rde values to make it possible for other configuration
>> package to depend on it.  Yep, probably it's a way.
>
> if I understood you correctly, this is exactly what I tried first. I
> should have said that before.
> I know what the problem is but I have trouble explaining it.
>
> In my first feature (feature-emacs-leader-keys), the user can set some
> values with keywords and the will get saved into the config with
>
> --8<---------------cut here---------------start------------->8---
>    (values `((emacs-leader . ,leader)
>              (emacs-localleader . ,localleader)))
> --8<---------------cut here---------------end--------------->8---
>
> In my second feature (feature-emacs-files) I retrieve those values from
> the config with
>
> --8<---------------cut here---------------start------------->8---
> `((let ((rde-leader ,(get-value 'emacs-leader config)))
> --8<---------------cut here---------------end--------------->8---
>
> However, with key bindings it's a bit diffcult in emacs, take this code
> snippet for example:
>
> --8<---------------cut here---------------start------------->8---
> (setq rde-test-leader "M-SPC")
> (define-prefix-command 'rde-test-map)
> (global-set-key (kbd (concat rde-test-leader " f")) 'rde-test-map)
> --8<---------------cut here---------------end--------------->8---
>
> The first line I will set in (feature-emacs-leader-keys), write it to
> the config and use get-value in the other feature to use it (like in the
> third line).
>
> However, if you execute those three lines in a scratch buffer, you'll
> get the error `global-set-key: Key sequence M-SPC f starts with
> non-prefix key M-SPC'

You need to undefine prefix key first.

(global-set-key (kbd "M-SPC") nil)

>
> I'm not exactly sure where this error comes from, but I can remedy it if
> I start the three lines above with `(setq rde-test-leader nil)'. So this
> is something I do in (feature-emacs-leader-keys).
>
> This is no problem regarding rde, everyting works, but here is the
> problem... because the elisp code from (feature-emacs-files) gets loaded
> before (feature-emacs-leader-keys), the expression (setq rde-test-leader
> nil) hasn't been evaluated yet, and I run in the error I mentioned.
>
> I hope you understand the problem. Again I had trouble explaining it.

You can show the full implementation to make me understand your intent
better.

I have a task in my todo list about defining keymaps, which can be
reused across different features, I plan to do it in near future.  Seems
the example can help you to achive what you want, still not sure if it
completely relevant.

-- 
Best regards,
Andrew Tropin
Demis Balbach <db@minikn.xyz>
Details
Message ID
<877dcd7ijn.fsf@minikn.xyz>
In-Reply-To
<87ee6lg4q4.fsf@trop.in> (view parent)
DKIM signature
pass
Download raw message
On 2021-12-09 18:47, Andrew Tropin wrote:

> You can show the full implementation to make me understand your intent
> better.
>
> I have a task in my todo list about defining keymaps, which can be
> reused across different features, I plan to do it in near future.  Seems
> the example can help you to achive what you want, still not sure if it
> completely relevant.

Well I don't know if pressing this issue further is worth it at this
point. It's working at the moment, albeid not ideally. But if key
bindings is something you have an your todo list then I'll gladly wait
for it to be implemented, until then, I'll use this method. It's not a
pressing issue for me.

I learned how I can load elisp code in order (if I really need to) using
rde, I'll take that away.

Thanks!
-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach
Reply to thread Export thread (mbox)