Re: A proposal for a friendlier Emacs

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

Hello,

I started using Emacs when I first installed Lucid Emacs on a
SPARCstation LX, must have been early 1990s, and I have gone through
quite a couple of Emacs configs since then (SunOS, Solaris, and now
macOS).

Since one of the topics on the Emacs 28/modern threads here was
"on-boarding" of new users, I thought I'd share a few experiences of
what some hard parts were while developing my configs.

----------------------------------------------------------------------

The first hurdle is that when developing a config (yes, its a
development task), is that you're essentially pulling yourself out if
the swamp by your own hair. I.e. you are using Emacs to edit its own
configuration files. Many settings have immediate effect, and that's
super cool. Some don't, however, (or maybe you forgot to eval-region)
and seem to be evaluated only once at start-up time.

Another aspect of this is that not every change I make is one I will
want to keep (I'm trying things out). So this is about "backing out"
changes and restoring state. Whatever I want to achieve, in order to be
able to revert things later, I'll have to make note of the values of
variables and hooks before I change them, so I'll be able to restore the
previous value. Lest I forgot to make note...

Both things together result in me restarting Emacs every now and then
when developing a config, so as to be able to start from a clean slate,
and make sure that all config changes have been applied. Restarting
brings with it a couple of inconveniences. Apart from the wait, it also
means that I will need to re-open all the files, custom buffers,
documentation, and what not I had open before.

Thus, in my ideal world I would like to be able to start a new Emacs
instance, that loads the new config, has debug-on-error set, verbose
logging, and perhaps some more things to help me debug my new config. In
the new Emacs instance, I can take my new config for a spin, and
terminate it when I'm done (or even kill it if I messed up badly). Then
I drop back into the initial Emacs instance (still all buffers open),
refine the config, and give it another round.

----------------------------------------------------------------------

As your config evolves, the next question everyone will be asking
themselves is "custom.el or init file?" While there is no one answer to
this, of course, but it hints to a wider issue. With flexibility (of
init files architecture), comes responsibility (to choose the right
architecture for my case).

Here is what I observed: when I start adding a new class of use-cases
(example: email), I start out with a single package, that does most of
what I want/need. In that phase, I tend to name the config file after
the package (because the use-case and the package are one and the same
in my mental model). As I keep refining, and adding features, other
packages will likely come into play. At this point I realise that the
config file name no longer fits, and rename it to reflect the use-case
class. Within this config file, I keep the setting for each package in a
different section (separated by comments).

Again, in my ideal world, each package would be classified into exactly
one main category (email, content completion, etc.). When I install
(package-list-packages) the first package from a category I haven't had
before, Emacs would create a new file in the init directory, named after
the category (example: email.el), with a (provide 'setup-category) at
the end, and a section for the new package that has a copy of the init
code proposed by the package's documentation, and would eval-region on
the init code. When I install the next package from that category, Emacs
would just drop a new section into the respective init file, and
eval-region that section. Oh, and of course a (require 'setup-category)
would also need to be automatically dropped into init.el.

Of course this will not make every experienced user happy, and people
with existing, sophisticated configs will want to switch this off. So
there should be a variable to turn the whole mechanism off. Maybe in
early-init.el? But I think it could be a subtle way of guiding new users
to starting with a structured approach to init files (searching for
"emacs.d" on GitHub as of this writing lists 10,521 repositories).

In the long run, this could also be a tool for doing away with
custom.el. Just have Custom insert a custom-set-variables with the
settings for that package in the section for that package in the
respective category config file. And the settings for Emacs itself would
live in init.el.

----------------------------------------------------------------------

The third area I'd like to touch on are faces. This is what certainly
everybody will want to customise at some point. The reality of
customising faces is: it's hard. Faces can inherit from one another, so
sometimes I end up changing a couple of faces, when it would have been
sufficient to customise one (the "parent"). An "inheritance tree" would
help here.

Also, 'C-u C-x =' (what-cursor-position; 10 points for choosing a
calling name, btw.) is your friend to find out which of the many many
faces to change (provided you discovered it). But then you'll have to
strike the key chord time again to discover the faces and overlays here
and there. Why couldn't what-cursor-position just split the window,
display its information in the other window, and let me move around in
my buffer, updating the face/overlay information in the other window as
I move the cursor around? And as most of us are on graphical desktops
these days, where's the option to hover with the mouse and get
face/overlay information for what's under the mouse?

One more thing on what-cursor-position: in the info buffer, there's a
link for the face that takes me to another info screen, which in turn
describes the face's attributes, and gives me a "you can configure this"
link. IMO, this is redundant. Just give me a direct link to the face's
customisation from the initial what-cursor-position infp screen. The
customisation buffer will also show me the current attributes, so the
"intermediate" face attributes info screen has no added value to me.

----------------------------------------------------------------------

Finally, a few thoughts on packages and curation. As of this writing,
the combined list of ELPA, MELPA, and builtin packages of my current
emacs lists 5,065 packages. Chances are, whatever topic you're looking
at, there's more than one package. Which one is the best for my
purposes?

The Comprehensive Perl Archive Network (CPAN), which as of this writing
offers 196,156 Perl modules, faces similar issues. It has a simple
mechanism, which I find very helpful for quickly narrowing down my
selection. Users can do "add to favourites" for a module. When one
browses the modules, the number of users who faved it is shown. Not
perfect, but a rule-of-thumb estimate for a module's popularity. In my
ideal world, such a favourite mechanism would be added to ELPA and
MELPA, too, and the favourite count be displayed in the package
details screen of package-list-packages.

----------------------------------------------------------------------


Looking forward to your thoughts,

  --alexander