Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[Tim Cross]

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

> I have a suspicion that what you're wary of, or
> objecting to, is perhaps really the automatic
> loading of `custom-file' if it isn't already
> loaded.  That's the only "complexity" I can
> imagine you think you see.  (I don't see that
> just giving `custom-file' a default value adds
> complexity.)
>

Yes, my main concern was certainly related to various suggestions
regarding automated detection and other proposals which appear to be
focused on minimising change impact on existing users etc.

However, having said that, I'm still not convinced this is a real
problem. I would agree that if I was implementing this feature now, I
don't think I would have the custom data written to the init file and
would probably write it to a custom specific file. However, we are not
implementing it now and it has been implemented in this way for over 20
years and I've seen few problem reports. I have seen a few people
comment that they think it was a bad decision and/or they don't like it,
but few actual problems. 

> If not - if you have a problem also with the
> aim of getting more users to use `custom-file',
> so as to separate Custom automatic editing of
> init files (when it saves) - then what is your
> critique of that aim?
>

I guess my main critique is two-fold. Firstly, it feels like work for
works sake which is largely being justified by an argument that
essentially boils down to "it isn't best practice". Such an argument
might have some weight if there was nothing the user could do, but that
isn't the case. This is my second critique - for those who don't like
having their custom variables in their init file, they can easily
change it. I'm sure some will argue that it isn't easy to change for
novices, but I find such an argument weak as novices are unlikely to
even know/care that the custom variable section is written to their init
file and those that do will likely find the standard solution pretty
quickly. 

> (If you agree with that aim, but not with any
> of the proposals to move toward it, please
> make that clear too.)
>

If the *only* change we are talking about is setting a default value for
custom-file, I probably wouldn't have any concerns. However, I think it
is a mis-characterisation to claim that is all that will change. There
has also been mention of adding new command line switches (like -Q and
-q) to turn off loading of custom file, questions around when the custom
file will be loaded and ability of the user to control that timing,
automated prompting of custom-file name/location etc. 

> To be clear, the aim is not at all "to make
> the Emacs startup process 'smarter'", and not
> at all to provide some kind of "optimization"
> (premature or otherwise).  And I don't think
> anything proposed so far does that.
>

Well, I guess we will disagree on that point. My response in this thread
was specifically triggered by proposals relating to auto-detection of
whether users have set a custom-file name, discussions regarding adding
additional command line switches and various other suggestions relating
to contgrol of when the custom-file is loaded (or not). 

> The problem to try to solve - particularly
> for new users or users unsure of Emacs Lisp
> - is to prevent users (accidentally or with
> good intentions) from messing with generated
> code, and (less likely) to prevent Customize
> from messing with user code.  That's all.
>
> Is that a purely "theoretical" problem?
>

OK, theoretical was probably a bad choice of words. Perhaps contrived
problem would be a better description. In 25 years of using Emacs, I
have never seen Emacs customize messing with user code. I think that one
is purely theoretical. With respect to users, especially new users,
intentionally or unintentionally messing with generated code, I think
that is just part of the normal learning process. There is a very clear
warning and if they choose to disregard it, that is their choice. If we
are going to go down the protect users from themselves road, then we
should remove the init file completely and only allow them to configure
the system using customize.

A better question is whether this is a significant enough problem to
justify the change, change management that will be required and
additional complexity (even if only small) it will add. I don't see this
as a significant issue and personally, prefer having the control to set
a custom file and load it when I see fit for my own configuration. In a
nutshell, the potential negatives seem to outweigh the benefits. If we
were seeing large numbers of reports from users having errors or
problems because of the current behaviour, my position would likely be
different.

There is also a positive side to having the custom variables stored in
your init file - one which is probably even more relevant for new users.
The benefit is that ALL configuration related settings are in the one
file. The new user does not need to know that in addition to their init
file, there is this other 'custom' file which will also impact on their
configuration. Right now, if, for example, I was having issues getting
some configuration relating to 'x' to work, I can search for 'x' in the
init file and there is a good chance I will find it even if it is being
set via a custom setting I had forgotten about. 

> As I asked earlier:
>
>  The default behavior of Emacs now is to have
>  a single file that mixes user coding and
>  Custom coding.  Why is that a great idea?
>                  ^^^^^^^^^^^^^^^^^^^^^^^^

I think that is an irrelevant question. Perhaps it wasn't a great idea
or perhaps it was a great idea at the time it was made. However, that is
irrelevant. The better question is whether it was a bad enough idea to
need change and I don't think it is. 

It is probably also worth noting that the extremely popular VS Code
editor actually does a very similar thing. That editor is configured via
JSON and has two interfaces - one which provides a sort of graphical
interface similar in flavor to customize and one where the user
writes/edits JSON directly. It is all stored in the same file (though
you can also have additional config files). The Emacs approach is IMO a
better solution because the two are clearly separated while in VS Code,
the user can screw up the manual code which will also screw up the GUI
interface to the config. 

>
> No one has answered that.  Forget, for a
> second (and no, I'm not saying this isn't
> important), that there is habit & legacy.
>
> Just imagine that you are designing from
> scratch.  Would you really want Customize
> (or any other code generation) to write
> to a file that users code also?
>

Well, if I was designing from scratch, I probably wouldn't have
customize in its current form either. But if we are going down that
road, I also would do font locking differently, use different key
bindings, use different terminology for many Emacs features, have real
namespaces, etc, etc, ... 

> We don't do that for any other generated
> Elisp code.  We write all such code to
> dedicated, separate files - not files
> that users code in.  (We don't _prevent_
> users from editing such files, of course.)
>
> Why do we do that?  Premature optimization?
> Paranoid theoretical problem-worrying?
>
> ___
>
> In order of decreasing priority (to me):
>
> 1. Let's agree on the problem, potential at
>    least.
>

Sorry, but no I cannot. I would characterise it as a contrived rather
than potential problem. This solution has been there for a long time -
if the problem had real potential, it would have been realised in
significant numbers by now. 

> 2. Given the problem, let's agree that, in
>    some way, we want to prevent mixing user
>    coding with automatic coding.
>

Given I cannot agree there is a real problem, obviously I cannot agree
we need to do anything. If we were all out of work to do and all other
issues were resolved, then this might be worth considering. 


> 3. Given that aim, let's agree that Customize
>    should - by default - save to a different
>    file from a user init file.

Cannot just agree to that either as I don't think it is that simple. At
the moment, I have full control over doing this and full control over
whether that custom file is loaded or not loaded and when. To maintain
that level of full control and automate it for new users, the startup
process will need to become more complex. I don't see how this
additional complexity is justified. 

>
> 4. Given that goal, how do we get there?
> ___
>
> On the road from 1 to 4, how far do you get?
>

I guess zero :-)

> Personally, I get as far as #4.  I proposed
> some concrete changes as solution, but #4 is
> an open question.
>
> Possible solutions include:
>
> a. At a minimum (I think) explicitly encourage
>    users - particularly new users - to define
>    `custom-file', and load it to get their
>    saved settings.

This seems to be in conflict with one of the justifications underpinning
this argument i.e. dealing with elisp code is hard for new users. 

>
> b. What I proposed, which I won't repeat but I
>    can summarize as `custom-file'-default-value.
>
> Please note that even poor (a) has never been
> done: we don't encourage use of `custom-file'.
>
> I don't think doing nothing is good (see 1-3).
> And I don't think that (a) alone (recommending
> use of `custom-file') is sufficient.

I guess that is the big stumbling point. I'm still unconvinced that we
need to do anything or that it is potentially as simple as just setting
a default value for custom file.  

This isn't an issue I will die in the gutter over. If sufficient numbers
agree the change is needed, then it will happen. My only real request is
that whatever change is put in place, ensure that I can still set the
name and location of my custom settings file and have full control over
when in the init process it is loaded. This includes setting and loading
the custom file in files outside of the main user init file (i.e. in
files loaded by my init file).