Re: Some developement questions

[Eli Zaretskii]

> From: hw <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 22 Aug 2018 18:37:54 +0200
> 
> > 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.

They all are.  The selection depends on user preferences and habits.

> 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.

You can learn about it from the Emacs manual, of course.

> > 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.

They don't need to consider all of them.  They can take them one at a
time.  The documentation should tell them enough to make the decision,
perhaps after some experimenting.  Then they can go to the next
option.

IOW, the collection is just a device to enhance discoverability, in
presenting the options some class of users are likely to benefit from.

> 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.

That's the purpose of presenting a relatively small group of options,
out of many hundreds we have.

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

I write Lisp.  But I'm not a user of the kind we are talking about, so
what I do have little relevance here.

> 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.

We already have that: each mode file includes options for that mode.
What will we gain by having another file with those same options?