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

[Tim Cross <theophilusx@gmail.com>]

xenodasein@tutanota.de writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00821.html
>> ...
>> > All arguments against Drew's proposals so far converge at "it is better
>> > to do nothing."
>>
>> No, that is not what is being said. I'm saying "There is nothing needing
>> to be done." It is an unnecessary change with little, if any, real
>> benefit for users and which will have unnecessary/unwanted impact on
>> some existing users.
>>
>> > Why not propose something even better?
>>
>> Better than what? Exactly what problem will this change address and how
>> does this problem impact users and how does the proposed change mitigate
>> that impact?
>
> Well, I think we are getting there on this thread.
>
>> > Throwing "where
>> > is your evidence?" around is easy, but one must consider we are far from
>> > the domain of scientific method here, or of law.
>>
>> IF you propose a change, it has to be backed up with justification. Just
>> saying it would be better is insufficient.  So far, the justification
>> seems to be it is better from a philosophical/theoretical standpoint not
>> to mix user generated and auto-generated code in the same file,
>> it could reduce accidental errors by the user editing the settings or the user
>> finds it
>> confusing and the warning scares them.
>>
>> > Is existence of people
>> > on Emacs related forums suggesting setting custom-file to /dev/null as a
>> > good solution evidence enough?
>>
>> I think all that is evidence of is bad advice. Why would you set your
>> custom file to /dev/null? If you don't like custom, don't use it. If you
>> do use it, that advice will likely just totally confuse you as now, if
>> when you do use custom, it won't work.
>
> Yes, but such advice is then also evidence to that some users are
> annoyed enough with the current (bad) behavior to do/talk about things
> like that.
>

It is this vagary which needs to be clarified. Exactly what is this
"bad" behaviour and how does it impact users?

So far, the only justification seems to be that some users feel it is
bad practice to have both user configuration code and auto generated
code (from custom) in the same file. This seems to be more a personal
preference rather than anything else. There is little actual evidence of
problems being caused by custom writing to the init file - no repeating
bug reports and posts to forums where this behaviour turned out to be
the source of some issue seem extremely rare.

This behaviour has been in place for decades and it seems reasonable to
expect that if it was causing problems, we would be seeing bug reports
and frequent messages about issues where the resolution was related to
the custom section being in the user's init file. If this was the case,
the conversation would be very different and I suspect we would have
clear change proposals which would be accepted more readily as they
would be changes addressing real problems being experienced by users. 

For those who don't like custom writing to their init file, there is a
perfectly workable solution. It has been suggested this solution should
be encouraged for all users as it is "better". However, it only seems
better if you are someone in the camp who believes writing the custom
section to the init file is bad practice. I suspect many users don't
even give it a thought. There are even arguments in favour of the
current behaviour which are as valid. It isn't at all clear that
changing the default behaviour is sufficiently 'better' than the current
behaviour. 

>> > How about split of early-init/creation
>> > of straight.el?
>>
>> iWhat about it? How is it relevant to this proposed change?
>
> Suffice it to say that Customize and package.el modifying init.el
> was used as a driving factor in creating some popular alternative
> package managers.
>

I'm not sure that statement can be justified. The big issue straight.el
had was with the package-initialise statement being written to the init
file. That has nothing to do with custom. Even the original post
regarding these issues from the straight.el author stated that custom
was not an issue because the user was asked if they wanted to save the
datga to their init file before it was saved. The straight.el github
page says that package.el saving data via custom into your init file is
'uncouth'. Again, this is really just a philosophical preference, not
evidence of the behaviour being problematic. 

>> > What you call "belief/ideology" is known as intuition,
>> > and it is the primary force behind any successful software.
>> > Or any
>> > kind of invention, really.
>>
>> What is being proposed here is an impacting change to existing
>> behaviour. Trying to claim such a change is 'innovative' or can be
>> justified by intuition is simply insufficient. If it is a good change,
>> then it should not be difficult to provide sufficient justification.
>> Intuition can be both good and bad. There has to be some way to assess
>> whether intuition (or an idea) is a good one - just saying it is
>> intuition is not enough. 
>>
>> In over 30 years of working on software projects, some successful, some
>> less so, I can say with confidence, those projects which failed were
>> frequently those projects which did not manage change and were
>> constantly making changes based on little else other than intuition. The
>> projects which succeeded were the ones which correctly assessed which
>> changes to do and which ones not to. Intuition seldom comes into it, but
>> when it does, it is backed up with sufficient justification to offset
>> any of the negative consequences.
>
> Apart from miscommunication, we actually think the same on this.  Good
> intuition and changes lead to success, bad to failure.  I doubt "ones
> which correctly assessed" used rigorous formal methods to arrive at their
> decisions, I presume they did what we do on this list, talk over it.
>
>> > If only concern is the cost of change, why
>> > not produce arguments for how to reduce that cost or to find a way
>> > forward?
>>
>> Well that is easy. Don't perform change which has not been justified.
>
> But it is justified for many, AFAICT.
>

and here we get to the crux of the matter. Maybe many do think the
change is justified, but it would seem many don't and I suspect many
more don't actually have an opinion. What is being proposed is a change
to long standing behaviour where there is little evidence the existing
behaviour is causing problems and the main justification is down to some
people think it would be better. If the change were to have absolutely
no impact on existing users, there would be little opposition. If the
proposed change could demonstrate concrete improvements for users, there
would likely be less opposition. It does neither. In its weakest form,
the proposed change is for emacs to encourage the use of a separate file
for custom. However, there is little argument to support why Emacs
should adopt any position in this area. There is existing support for
those who don't want to have custom store data in their init file and
discovering that feature is not hard. Those who want the different
behaviour can have it with little effort. There is no need for Emcs to
adopt any stance here. 

>> When the change involved has impact to existing users, that impact needs
>> to be justified. When the change modifies long standing behaviour, that
>> modification needs to be justified.
>>
>> I also think it is poor form to basically tell me to come up with a
>> better solution because I don't agree with the need for the change. Time
>> would be better spent coming up with justification for the change rather
>> than criticise me for not agreeing with you.
>
> What I find problematic here is that this is change would be a simplest
> breaking change as possible, and we should try to get better at handling
> these as there will be bigger ones, and we can't avoid them all the time.
>

I find that a very flawed argument. Each change, breaking or otherwise,
needs to be evaluated on its own merits. How we handle once change has
little baring on a different change.

From my experience with Emacs, there is little problem with changes,
even breaking changes, if the change has sufficient justification. More
often than not, change proposals which fail to gain traction have a
common theme - they lack sufficient, clearly articulated justification
or lack people actually willing to implement the change. 

My lack of support for this change is not fundamentally because it is a
breaking change, but because there is a lack of justification. It is
change being justified by an opinion that having custom write data to
the init file is a bad idea. There are other opinions which suggest
having custom write to the init file has advantages over using a
separate file and probably even more users who really don't have an
opinion at all.

If we had any evidence that the current behaviour was causing
actual problems, we would be able to focus on how to address those
problems. The solution might be to separate custom from the init file or
it may be something completely different. It would all depend on exactly
what the problem is which needs to be addressed. Instead, what we really
have is just an opinion it is a bad idea and the suggestion that opinion
is sufficient to warrant changing an established behaviour which has
been in place for decades. Some might feel such an opinion is
sufficient, I don't. Furthermore, some of the more 'advanced' aspects of
the proposed change I find problematic because it would add additional
complexity and to some extent muddies the water with respect to Emacs
initialisation and how custom fits into the process.