help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: req-package


From: Alexander Shukaev
Subject: Re: req-package
Date: Thu, 13 Aug 2015 16:59:50 +0200

> Yes, sure, it will fail, because not all dependencies are satisfied. Why use
> cider without clojure-mode for example or why to try enable eldoc in
> clojure-mode if clojure mode failes to install?

It's all about the example you used.  Consider something like this:

(use-package recentf
  :defer
  :commands
  (recentf-mode)
  :init
  (recentf-mode)
  :config
  ;; *before*
  (with-eval-after-load 'evil
    (evil-make-overriding-map recentf-dialog-mode-map 'motion)
    (evil-set-initial-state 'recentf-dialog-mode 'motion)
    (evil-ex-define-cmd "rfm[enu]" #'recentf-open-files))
  ;; *after*
  )

Would you agree that in general, `evil' has nothing to do with
`recentf'?  I can have other configurations *before* and *after* the
`evil'-specific one (even involving more `with-eval-after-load' forms
depending on other packages).  As a result, if `evil' is not
present,then still the rest of the configuration of `recentf' will
function properly, and I don't get disturbed by an error message or
half-working configuration due to abortion.

It could still be avoided if one could write a boilerplate like

(req-package recentf
  :defer
  :commands
  (recentf-mode)
  :init
  (recentf-mode)
  :config
  ;; *before*
  )

(req-package recentf
  :defer
  :require (evil)
  :config
  (evil-make-overriding-map recentf-dialog-mode-map 'motion)
  (evil-set-initial-state 'recentf-dialog-mode 'motion)
  (evil-ex-define-cmd "rfm[enu]" #'recentf-open-files))

(req-package recentf
  :defer
  :config
  ;; *after*
  )

Will this work with `req-package'?  To be more specific, I guess you
understand what I mean here: I expect only the middle one to fail if
`evil' is not present, but *before* and *after* should still work.

> Basically yes. Also it provides you simplier api, because you do not pushed
> to write config in reversed way. You write what depends on what, instead of
> what is dependency of what. You can write much more modularised config in
> req-package way, because each package is configured with its own req-package
> form. Imaging how cumbersome your config will be with eval-after-load, if 10
> package are dependent on clojure-mode and some of them dependent on helm and
> some of them on flycheck and so on. I'm not even sure that it will be easy
> to support.

The only problem that I currently have with `use-package' is the
following.  Assume you have packages `a' and `b'.  Sometimes, when
configuring `b' with `use-package', I want to be absolutely sure that
not only `a' is loaded, but also that all the `(use-package a ...)'
forms have already been evaluated before the `(use-package b ...)'.  I
know 2 solutions to this problem.  (1) The dumb one, to arrange all
the `(use-package x ...)' into the corresponding, for example,
`init-x.el' and then of course `(require 'init-x)' in the right order
in some global configuration file (e.g. `init.el').  That is, for the
current example, it would be

(require 'init-a)
(require 'init-b)

Once again, this is dumb, and I don't do this, but rather stick with
the second option.  (2) Arrange all the `(use-package x ...)' into the
corresponding, for example, `init-x.el' and then do
`(with-eval-after-load 'init-x ...)' where necessary.  That is, for
the current example, it could either be

(require 'init-b)
(require 'init-a)

where the order appears to be wrong, but inside `(use-package b ...)'
I would use `(with-eval-after-load 'init-a ...)' which solves the
ordering problem; or

(require 'init-a)
(require 'init-b)

where the order is right, but `(with-eval-after-load 'init-a ...)'
inside `(use-package b ...)' still does no harm.  In other words, with
the approach (2), one does not have to care about the order of
execution of `(use-package x ...)' forms.

Now the question is whether your `req-package' does that automatically
with the `:require' keyword?  In particular, will

(req-package b
  :require a
  ...)

ensure that

(req-package a
  ...)

is evaluated before

(req-package b
  :require a
  ...)

regardless of the order in which they appear in the configuration files?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]