Re: cl-lib warnings

[Tim Cross <theophilusx@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> On Mon, Dec 26, 2022 at 11:49 PM Milan Glacier <news@milanglacier.com> wrote:
>
>  >I'm afraid mode options will make this even more
>  >complicated.  And what's with that defvar?
>
>  use-package is really a magic. But nobody uses a blank `(use-package
>  foo)`, usually a simple and pracctical use-package call would be
>  something like this:
>
>       (use-package foo
>       :config (setq foo-1 nil)
>       :init (setq foo-2 nil)
>       :hook ((python-mode emacs-lisp-mode) . foo-mode))
>
>  which specifies the code to be evaluated before foo is loaded (:init
>  part), the code to be evaluated after foo is loaded (:config part), and
>  the hook related to this package, which expands to:
>
> My expansion of that same form is larger and harder to read, 
> with condition-case and variables and stuff.  But it would seem 
> that the fluff overhead is constant, which is good.
>
> So I get your point: with enough practice, it's easy to see the
> primitives in use.
>  
>  (I personally am not a fan of use-package, I don't think it brings any
>  thing new. Often I need to expand it to see if its behavior is expected,
>  then why shouldn't I just write plain setq, add-hook stuffs directly?)
>
> Exactly. 
>

I am a fan of use-package. I've been using it for years. I really don't
follow the reasoning of the argument against it on the basis that it
brings nothing new in the sense you can achieve the same result using
existing facilities. This could be argued about many things, especially
when it comes to code and programming. Many 'new' things are really just
further abstractions or alternative abstractions for
features/functionality which already exists. By definition, anything
achieved via a macro could also be done just by using 'existing
primitives'.

I also find the suggestion use package is not good because when you
expand the macro, it will be harder to read than if you had simply
implemented the code directly using existing primitives. This is true of
many macros and I think completely misses the point. In the many years
I've been using use-package, there has been exactly one instance where I
needed to expand the macro to understand what it was doing. Actually, I
didn't need to do it, I did it more out of interest.

What I like about use-package is it has made my init file more concise
and easier to manage and while I could achieve exactly the same outcome
writing a lot of additional elisp myself, I appreciate the fact I don't
have to and I can spend more time focusing on my real work. This is
especially true because much of that additional elisp I would be forced
to write if I didn't have use-package is very much 'boiler plate' code -
boring utility code to add hooks, update mode, interpreter, filename
magic, package installation, key bindings, setq etc. Essentially, I find
use-package does exactly what a useful macros does - it adds some sugar
which helps me avoid having to write boring repetitive code of low interest. 

I am completely neutral regarding the inclusion of use-package into
Emacs core. It is a relatively small package and having it there is
convenient.  However, having to install it from ELPA was trivial and
convenient as well. Having it as part of Emacs core has made no
significant difference for me - perhaps my init file is now 2 lines
smaller. I do admit not really understanding the need many seem to have
regarding getting stuff into 'core'.