Re: Some developement questions

[hw]

Eli Zaretskii <address@hidden> writes:

>> From: hw <address@hidden>
>> Cc: Ergus <address@hidden>,  address@hidden
>> Date: Wed, 22 Aug 2018 14:34:26 +0200
>> 
>> > Exactly my point: you have just enumerated at least 3 different
>> > classes of users, and the solution is different for every one of them.
>> > Finding a way of being friendly to each class is the problem to solve.
>> > One possible solution could be groups of Custom options that are
>> > likely to be relevant to each class of users, and writing
>> > customization commands that target each class.  Patches are welcome.
>> 
>> How about including a number of ~/.emacs files, containing options
>> supposed to make things easier for a class of users --- or include
>> groups of ~/.emacs files so that for any given class, there can be many
>> configurations to pick from within a group?
>
> IMO, that would be too radical, because in an init file each option
> already has a value.  So we will have to decide for the users whether
> or not they want certain options to have certain values.  That might
> work for boolean options, but many options in Emacs are non-boolean.
> As just one example, consider display-line-numbers-mode -- it has
> between 3 and 4 different styles, so which one would you put in the
> .emacs?

Use the values you would you put for the particular use case the file is
designed for.

I didn´t know that there´s a mode displaying line numbers that has
styles; I´ve only used linum-mode so far.  It would be interesting to
learn about this from a file.

> By contrast, by creating a group of options, we don't need to decide
> for the users what values of which options they like; we just make the
> options we think are relevant for them more easily discoverable.

But then, the users can be overwhelmed by a multitude of options and
may have trouble figuring out which ones to change and which values to
set.


When customize was introduced, I tried it out and got totally lost in
it.  I got taken from one buffer to another and figured this isn´t
useful at all unless you already exactly know what you´re looking for.
Even then, it´s difficult to find.

The only thing I sometimes use customize for is setting the default
font, and that is /very/ difficult to find because I never think of
"face" when trying to pick a font.  (Only yesterday I found out that
setting the default font is now easy because there´s an entry in the
menu which works great.  A long time ago, I disabled the menu bar, and
I usually don´t run 'emacs -q' ...)

How do you customize key bindings and add your own elisp?


> I also think that browsing through a Custom buffer is more
> user-friendly than telling the users to find their way through several
> files.

They don´t need to do that.  You offer them to use one of the
configurations in the LaTeX group for working with LaTeX and to use one
of the configurations in the C++ group when writing C++ source code, and
so on.

Users may be happy when they can try some different configurations, pick
one they like and go from there --- rather than having to figure it out
all at once all by themselves.


Configuring Emacs is kinda like configuring fvwm, and it was
fvwm-crystal that brought me back to fvwm after using enlightenment for
a long time.  Fvwm-crystal is like a pre-defined configuration for fvwm,
with a few customization options to choose from.  It didn´t take long
before I wanted to create my own configuration, so I did, learning from
the docs and other configurations.  I ended up with a window manager
that *finally* manages the windows for me rather than forcing me to
manage the windows --- and any time I want to change something, I can
just do that.  Why would I put up with anything less?

So what I suggest is more like giving users a choice between fvwms
default configuration, fvwm-nightshade, fvwm-crystal and others for
Emacs, rather than forcing users to try to find their way through
configuration files or options.  They may discover Emacs over time,
starting from something useful they like, and it probably won´t take
long before they aren´t willing to put up with anything less than Emacs
(unless they like vi maybe).