emacs-devel
[Top][All Lists]
Advanced

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

Re: [External] : Re: Adding use-package to core


From: Matthew Carter
Subject: Re: [External] : Re: Adding use-package to core
Date: Sun, 13 Nov 2022 18:13:34 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Drew Adams <drew.adams@oracle.com> writes:

>> To me, use-package and package.el are mainly orthogonal:
>> Package.el is for package management (installing, updating,
>> removing), while use-package is for customization beyond
>> what Customize provides -- or at least allows you to
>> concentrate changes related to the same package in one place.
>
> Speaking/asking from ignorance here...
>
> 1. "Customization beyond what Customize provides"
>
> What kinds of such customization, besides the
> one you call out next (#2)?
>
> 2. "allows you to concentrate changes related
> to the same package in one place"
>
> Can you be more specific here?  How does what
> you have in mind differ from what customize
> groups provide?
>
> _____
>
> For #2, a package can even have a group with
> subgroups.  And a package has parent groups.
> Seems to me that not only do Customize groups
> let you concentrate changes in one place, but
> they even let you do so in a hierarchical way
> (a graph, i.e., hierarchies with sharing),
> that is, change your focus of concentration.
> This applies for both browsing/discovering
> and changing settings.
>
> Examples at different ends of the grouping
> spectrum:
>
> `M-x customize-group bookmark-plus' shows 114
> options and faces.  Flat: no subgroups.
>
> On the other hand, group `Icicles' has nine
> subgroups. `M-x customize-group Icicles' shows
> the following, where each parent group and
> subgroup name links to its `customize-group'
> presentation:
> ______
>
> Parent groups: Matching Completion Apropos Dabbrev
>                Help Recentf Minibuffer Convenience
>
> Icicles group: 
>      State : visible group members are all at standard values.
>
>    Minibuffer input completion and cycling of completion candidates.
>
>    See also Doc-Part1, Doc-Part2, Description, Download, Other
>    Libraries by Drew, and Send Bug Report.
>
>  hexrgb-canonicalize-defined-colors-flag 
>    Non-nil means remove duplicate color names. More
>
>  icicle-completion-style-sets 
>    Possible 'completion-styles' values for when 'TAB' completion
>    method is 'vanilla'.
>
> Subgroups:
> Icicles-Buffers
>   Icicles preferences related to buffers.
> Icicles-Completions-Display
>   Icicles preferences related to display of completion candidates.
> Icicles-Files
>   Icicles preferences related to files.
> Icicles-Key-Bindings
>   Icicles preferences related to key bindings.
> Icicles-Key-Completion
>   Icicles preferences related to key completion
>   ('icicle-complete-keys').
> Icicles-Matching
>   Icicles preferences related to matching input for completion.
> Icicles-Minibuffer-Display
>   Icicles preferences related to minibuffer display during
>   completion.
> Icicles-Miscellaneous
>   Miscellaneous Icicles preferences.
> Icicles-Searching
>   Icicles preferences related to searching.
> _____
>
> A guess is that you have in mind other _kinds_
> of customizations, beyond options and faces.
> Is that it?
>
> Customize is limited, but it would be good to
> set straight which of its limitations
> `use-package' helps overcome.
>
> One guess would be key bindings.  (The Emacs
> manual has two completely separate sections,
> `Easy Customization Interface' and `Customizing
> Key Bindings', with eight and ten subsections,
> respectively.)  (`defcustom' now has :type
> `key-sequence', but that's of course only for
> customizing option values.)
> _____
>
> To be clear, I'm not making any statement about
> either `use-package' or Customize.  Certainly
> the Customize UI could be improved, and there
> are user customizations that Customize doesn't
> help with at all, OOTB.
>
> It might be good to match some of its limitations
> against what `use-package' offers to handle them.
> Maybe that's the best solution for them, or maybe
> it can serve as food for thought for improvement
> to Customize.
>

I have always found M-x customize lacking, in that it expects to store
my preferences in a machine readable way (albeit, still text, but ill
formatted and automatically appended to my files) and be set up via a
slow manual process (hopping through customize menus is much slower than
just editing elisp).

Conversely, use-package allows me to set up all the options I care about
in one area, share them with others, and tweak them via the plain old
text editing vs clunky menus (I use emacs in TTY mode, maybe in GUI mode
these are less clunky).

If all customs were equivalent to a setq, I could do the old way
(organize on my own, with various (setq some-thing some-value)), however
more and more packages seem to need actual M-x customize assignment (a
simple setq won't make the change take proper effect).

Thankfully use-package accommodates this, and I can set these up in a
plain old lisp format in the :custom block the use-package provides.

In close to 15 years of using Emacs, I've never opted for M-x customize
when other alternatives would do as a user (although I aim to support it
in the non-GNU packages I provide).

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com



reply via email to

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