Re: Some developement questions

[Ergus]

Hi:

When I asked about this I had in mind more or less what hd is proposing.

A simple config helper specially for newer users. I see for example what
Spacemacs does the first time I started it; and I thing it is a very
good approach for the new user. But I don't like the excess of
layers they added to the configurations after that; because it
that the configuration experience feels too different and
complicated.

On the other hand, if emacs starts without a config .emacs or init.el it
is a hint that probably is a new user or a new machine or a frequent
user in a hurry, time to configure everything. In this situations emacs
could ask if he wants some help to create a simple BUT personalized
configuration. **if yes** just start a dialog or interactive functions
calls that makes him some simple questions with comments about the
different choices. And then generate a basic init.el. Nothing more
complicated than that.

This could be useful not only because it can attract new emacs users
giving a better initial experience less intimidating (elisp seemed like
Sanskrit the first time I saw it), but also because the first time a new
user opens emacs he could get an idea about the potential without
needing to read a full manual to have line numbers, tutorial, google,
emacs wiki... Consider that many people come from limited editors, so
they don't even know that they can make much more with emacs.

Something like this could be useful because:

1) We could have some feedback about which options are most used and which 
packages are more suitable.

2) The default options and changes are not always properly documented or google 
gives older documentation for them.

3) Almost everybody changes some default options like C indentation, add 
packages, change colors or require some lisp lines which is
just too much for a user that wants probably to make his first hello world.

4) Many configurations available online like the availables on github are very complicated with many dependencies, with too many irrelevant details in some aspects; and the risk to become or being already abandoned. If its creator is a C programmer maybe he don't need to improve the python mode. 

5) Newer users will start looking for ways to improve they modes in google and 
they will end coping random code from random places to their config, ending 
with a broken/useless/inefficient or deprecated configuration; which means a 
bad user experience and a potential migration to vim or something worst.

6) There are multiple packages that do exactly the same thing and it is sometimes very confusing to pick one (or even to know if we need it) because the documentation is obsolete or incomplete. Imagine newer users installing flycheck+flymake+company+autocomplete because they just read all the recommendations and they copy from here and there. But without irony or gtags o ctags they don't really get the experience they are really looking for. Or maybe the user needs a python mode and he will install jedi, and copy the config from someone with company... Or installing ivy+helm and not using any of them because he didn't configure. Or downloading some packages and installing them manually because the don't know we have a package manager and the wiki says "download from bla bla bla". 

I thing we could even make like a survey or ask in the mailing list to the 
clients about what they include in their config usually. So we can know what to 
ask because is important, and what is not relevant in most of the cases. It is 
a good idea to ask what the actual users want to see in the next releases.

This is just my opinion. Sorry for the extension and not knowing how to write 
code for doing such a thing myself.



On Thu, Aug 23, 2018 at 12:17:11AM +0200, hw wrote:
> Eli Zaretskii <address@hidden> writes:
>
> > > 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.
> >
> > [...]
> >
> > > 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?
>
> The gain would be that the user can pick between *sets* of settings,
> guided by a description of what each set does.  He doesn't need to
> concern himself with any particular setting to figure out if changing it
> brings him closer to what he wants, and then experiment with the next
> and the next and the next until he tried all the ones he could find.
> That kind of learning can come later.
>
> I think I see your point to assume that the defaults are good and to
> present the user with the individual settings and to let him learn and
> make his own decisions because everyone is too different to do anything
> else.  That's great when the new user uses Emacs because he wants to
> learn how to use it, and it might not be so good when he wants to use
> Emacs to get some work done while the defaults happen not to be good for
> him: Even better when he can simply switch to a set of settings that
> helps him with his work without having to go through all the trial and
> error otherwise needed to get there.
>
> Does that make sense?