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

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

> Message: 1
> Date: Sun, 02 Jan 2022 20:03:13 +0800
> From: Po Lu <luangruo@yahoo.com>
> To: xenodasein--- via "Emacs development discussions."
   <emacs-devel@gnu.org>
> Cc: xenodasein@tutanota.de
> Subject: Re: Propose to add setup-wizard.el to ELPA
> Message-ID: <87v8z2jqf2.fsf@yahoo.com>

If the default custom file has always been the init file, maybe the idea could be to create the custom file separately in a default location instead and keep init and custom files separated. I don't remember when I started using <emacs_dir>/custom.el as my custom file. Maybe something like that could be made the new default custom file and <emacs_dir>/init.el the default init file instead of ~/.emacs

Just some thoughts before being completely awake ;-)
/PA


Enviado desde mi iPad

[-- Attachment #2: Type: text/html, Size: 1799 bytes --]

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

[Robert Pluim]

>>>>> On Mon, 3 Jan 2022 07:13:22 +0100, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    >> Message: 1
    >> Date: Sun, 02 Jan 2022 20:03:13 +0800
    >> From: Po Lu <luangruo@yahoo.com>
    >> To: xenodasein--- via "Emacs development discussions."
    Pedro>    <emacs-devel@gnu.org>
    >> Cc: xenodasein@tutanota.de
    >> Subject: Re: Propose to add setup-wizard.el to ELPA
    >> Message-ID: <87v8z2jqf2.fsf@yahoo.com>

    Pedro> If the default custom file has always been the init file, maybe the
    Pedro> idea could be to create the custom file separately in a default
    Pedro> location instead and keep init and custom files separated. I don't
    Pedro> remember when I started using <emacs_dir>/custom.el as my custom
    Pedro> file. Maybe something like that could be made the new default custom
    Pedro> file and <emacs_dir>/init.el the default init file instead of ~/.emacs

The latter is already kind of the case: if <emacs_dir>/init.el exists
and ~/.emacs doesnʼt, init.el is used. If youʼre proposing swapping
that so that init.el is used even if .emacs exists, then thatʼs never
going to fly, but I for one would have no objections to customize
saving stuff to init.el if the user has no config at all. But Iʼd let
someone else write and test the code :-)

Robert
-- 

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

Hi,

I know that dropping .emacs altogether might be radical. I was trying to
tease in order to start a discussion.
However, my point is that currently, if you want to have a separate custom
file, all you have do is to set and load the custom-file in your init.el
I have this at the end of my init-el (as I think many have)

;;
;; Customisations
;;
(setq custom-file (locate-user-emacs-file "custom.el"))
(load custom-file 'noerror)

What I propose is to agree on a default value for custom-file that could
potentially be changed by the user in  init.el or .emacs
and do the (load custom-file 'noerror) after loading the init file as a
default behaviour for Emacs

Having a separate customisation file by default can ease debugging,
resetting customisations, bookkeeping, etc. etc.
/PA




On Mon, 3 Jan 2022 at 15:47, Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Mon, 3 Jan 2022 07:13:22 +0100, Pedro Andres Aranda Gutierrez <
> paaguti@gmail.com> said:
>
>     >> Message: 1
>     >> Date: Sun, 02 Jan 2022 20:03:13 +0800
>     >> From: Po Lu <luangruo@yahoo.com>
>     >> To: xenodasein--- via "Emacs development discussions."
>     Pedro>    <emacs-devel@gnu.org>
>     >> Cc: xenodasein@tutanota.de
>     >> Subject: Re: Propose to add setup-wizard.el to ELPA
>     >> Message-ID: <87v8z2jqf2.fsf@yahoo.com>
>
>     Pedro> If the default custom file has always been the init file, maybe
> the
>     Pedro> idea could be to create the custom file separately in a default
>     Pedro> location instead and keep init and custom files separated. I
> don't
>     Pedro> remember when I started using <emacs_dir>/custom.el as my custom
>     Pedro> file. Maybe something like that could be made the new default
> custom
>     Pedro> file and <emacs_dir>/init.el the default init file instead of
> ~/.emacs
>
> The latter is already kind of the case: if <emacs_dir>/init.el exists
> and ~/.emacs doesnʼt, init.el is used. If youʼre proposing swapping
> that so that init.el is used even if .emacs exists, then thatʼs never
> going to fly, but I for one would have no objections to customize
> saving stuff to init.el if the user has no config at all. But Iʼd let
> someone else write and test the code :-)
>
> Robert
> --
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 3527 bytes --]

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

On Tue, Jan 04, 2022 at 07:13:59AM +0100, Pedro Andres Aranda Gutierrez wrote:
> Hi,

[...]

> (setq custom-file (locate-user-emacs-file "custom.el"))
> (load custom-file 'noerror)
> 
> What I propose is to agree on a default value for custom-file that could
> potentially be changed by the user in  init.el or .emacs
> and do the (load custom-file 'noerror) after loading the init file as a
> default behaviour for Emacs
> 
> Having a separate customisation file by default can ease debugging,
> resetting customisations, bookkeeping, etc. etc.

Late to the party, but...

I do a similar thing anyway. I can see recommending such a thing. But I
wouldn't like Some Obscure Magic nearly forcing people to do it this
way?

(Yes, the last bit of your proposal: "do the ... as a default behaviour"
counts to me as Some Obscure Magic. I much prefer to have the load down
there in my init file explicitly).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Stefan Kangas]

<tomas@tuxteam.de> writes:

> I do a similar thing anyway. I can see recommending such a thing. But I
> wouldn't like Some Obscure Magic nearly forcing people to do it this
> way?
>
> (Yes, the last bit of your proposal: "do the ... as a default behaviour"
> counts to me as Some Obscure Magic. I much prefer to have the load down
> there in my init file explicitly).

You would have something like .emacs.d/init.el and .emacs.d/custom.el.
I don't think that looks obscure at all.

It would certainly be easier to explain than the current state of
affairs: "init.el is for any customizations you write yourself,
custom.el is for anything you edit with M-x customize".

If the name "custom.el" is the obscure part, you could name it
"options.el" or whatever is considered more explanatory.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Tue, Jan 04, 2022 at 02:29:49AM -0500, Stefan Kangas wrote:
> <tomas@tuxteam.de> writes:
> 
> > I do a similar thing anyway. I can see recommending such a thing. But I
> > wouldn't like Some Obscure Magic nearly forcing people to do it this
> > way?
> >
> > (Yes, the last bit of your proposal: "do the ... as a default behaviour"
> > counts to me as Some Obscure Magic. I much prefer to have the load down
> > there in my init file explicitly).
> 
> You would have something like .emacs.d/init.el and .emacs.d/custom.el.
> I don't think that looks obscure at all.

Let's agree to differ on that. Why two? Why in an implicitly defined
order?

Why not just one central config (which ideally does little itself) where
the loading order of the others is explicit?

> It would certainly be easier to explain than the current state of
> affairs: "init.el is for any customizations you write yourself,
> custom.el is for anything you edit with M-x customize".

The explanation is not quite right. I do edit custom.el by hand, I've
just to be aware that customize has to understand what I do there.

> If the name "custom.el" is the obscure part, you could name it
> "options.el" or whatever is considered more explanatory.

No, it's not the name. It's the implicitness of the mechanism. I'd very
much prefer the "top-level" to be explicit (and thus more visible to the
user).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Drew Adams]

> > You would have something like .emacs.d/init.el and .emacs.d/custom.el.
> > I don't think that looks obscure at all.
> 
> Let's agree to differ on that. Why two? Why in an
> implicitly defined order?

Why two separate files?  That's what this whole
discussion is about: preventing Custom from
writing generated code to the same file where
you write code manually.

The "implicitly defined order" would be explicitly
defined (doc'd).  And it would only be the default.

Why should the default be to load your init file
before `custom-file'?  To give your handwritten
code priority.  In your code, you can load
`custom-file' at the outset, or at any other
place you like.

> Why not just one central config (which ideally does
> little itself) where the loading order of the others
> is explicit?

Your init file (and any code it loads) is the
one central place where you control when file
`custom-file' gets loaded, and that's done
explicitly.

> I do edit custom.el by hand, I've just to be
> aware that customize has to understand what I do there.

Nothing would prevent you from doing that.
That's similar to doing everything in init.el,
but at least it has the advantage of not
mixing `custom*' code with other code.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Tue, Jan 04, 2022 at 04:44:36PM +0000, Drew Adams wrote:
> > > You would have something like .emacs.d/init.el and .emacs.d/custom.el.
> > > I don't think that looks obscure at all.
> > 
> > Let's agree to differ on that. Why two? Why in an
> > implicitly defined order?
> 
> Why two separate files?  That's what this whole
> discussion is about: preventing Custom from
> writing generated code to the same file where
> you write code manually.

OK, I was somewhat ambiguous: I do have more than two init files, but
each one is explicitly loaded from ~/.emacs.d/init.el.

What I meant with "why two?" was why two "load" processes from whithin
Emacs's guts when one suffices?

> The "implicitly defined order" would be explicitly
> defined (doc'd).  And it would only be the default.

We seem to have different notions of explicit :-)

I meant specifically explicit in the init file.

[...]

> Nothing would prevent you from doing that.
> That's similar to doing everything in init.el,
> but at least it has the advantage of not
> mixing `custom*' code with other code.

TBH I started off with ~/.emacs (or how it was called back then). I
hadn't any qualms with customize writing stuff into it -- on the
contrary, it gave me hints on what I could do myself :-)

Later, once the init file got more complex, I moved things to ~/.emacs.d
and separated different parts. That was the moment where custom.el got
separated out.

This gave me a chance to learn I perhaps wouldn't have taken otherwise.

But I get that this is a kind of mileage which varies wildly :)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Drew Adams]

> > The "implicitly defined order" would be explicitly
> > defined (doc'd).  And it would only be the default.
> 
> We seem to have different notions of explicit :-)
> 
> I meant specifically explicit in the init file.

As mentioned, you can explicitly load `custom-file'
from your init file.  You control where/when you do
that.  This means you can do it in any order you
like, relative to other code you load or otherwise
evaluate.  IOW, loading `custom-file' is as
"explicit in the init file" as you want it to be.

> > Nothing would prevent you from doing that.
> > That's similar to doing everything in init.el,
> > but at least it has the advantage of not
> > mixing `custom*' code with other code.
> 
> TBH I started off with ~/.emacs (or how it was called back then). I
> hadn't any qualms with customize writing stuff into it -- on the
> contrary, it gave me hints on what I could do myself :-)
> 
> Later, once the init file got more complex, I moved things to ~/.emacs.d
> and separated different parts. That was the moment where custom.el got
> separated out.

What do you mean by the moment of custom.el
separation?

`custom-file' has been Emacs practically forever
(it's in Emacs 20, for instance).

If you meant file `custom.el', that's not a user
file.  It's one of the main standard files for
Customize.

If you meant `~/.emacs-custom.el', which is referred
to in the doc: that's an imaginary/example file name.
That file exists only if a user creates it.  There's
nothing special about its name at all.  There's no
automatic looking for a file of that name, for instance.

The doc just suggests that name as a possible value
for var `custom-file', as seen in `C-h v custom-file'
(the same text is in (emacs) `Saving Customizations'):

 write something like the following in your init file:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 (setq custom-file "~/.emacs-custom.el")
 (load custom-file)

(And yes, it's unfortunate that whoever wrote that
doc chose a file name the ended in "custom.el", as
that invites confusion with the standard file of
that name.)

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Tue, Jan 04, 2022 at 05:30:33PM +0000, Drew Adams wrote:
> > > The "implicitly defined order" would be explicitly
> > > defined (doc'd).  And it would only be the default.
> > 
> > We seem to have different notions of explicit :-)

> As mentioned, you can explicitly load `custom-file'
> from your init file.

We are still mis-communicating. If `custom-file' isn't loaded explicitly
from the init file, what you propose is that it's loaded implicitly
anyway. *That*'s what I perceive as "Magic".

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Drew Adams]

> > > > The "implicitly defined order" would be explicitly
> > > > defined (doc'd).  And it would only be the default.
> > >
> > > We seem to have different notions of explicit :-)
> 
> > As mentioned, you can explicitly load `custom-file'
> > from your init file.
> 
> We are still mis-communicating. If `custom-file'
> isn't loaded explicitly from the init file, what
> you propose is that it's loaded implicitly anyway.

Only under particular circumstances.

1. `custom-file' is nil by default.  Loading
   that is a no-op.

2. You can set `custom-file' to your init file.
   No change from current behavior, once you've
   done that.  End of story.

3. No automatic loading of `custom-file' if
   it's already been loaded.

4. You'll be able to set a variable, to prevent
   any automatic loading of `custom-file'.

IF you define a `custom-file' different from
your init file, and IF you use Customize, to
fill that file, and IF you don't load it from
your init file, and IF you don't set the var
to prevent it from being loaded automatically,
THEN it'll be loaded just after your init file.

And this will be documented.

> *That*'s what I perceive as "Magic".

Not what I'd call hidden magic.  But magic's
in the eye of its believer.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Tue, Jan 04, 2022 at 06:27:32PM +0000, Drew Adams wrote:

> IF you define a `custom-file' different from
> your init file, and IF you use Customize, to
> fill that file, and IF you don't load it from
> your init file, and IF you don't set the var
> to prevent it from being loaded automatically,
> THEN it'll be loaded just after your init file.
> 
> And this will be documented.
> 
> > *That*'s what I perceive as "Magic".
> 
> Not what I'd call hidden magic.  But magic's
> in the eye of its believer.

Absolutely.

At least now we worked out the diff :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Stefan Kangas]

"tomas@tuxteam.de" <tomas@tuxteam.de> writes:

> We are still mis-communicating. If `custom-file' isn't loaded explicitly
> from the init file, what you propose is that it's loaded implicitly
> anyway. *That*'s what I perceive as "Magic".

FWIW, I don't see it as more magic than automatically loading any other
file in .emacs.d such as bookmarks, bbdb, or .emacs.desktop.  YMMV.

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

[Drew Adams]

> I do a similar thing anyway. I can see recommending
> such a thing.

Yes, that's a first step.  It should have been done
long ago.

> But I wouldn't like Some Obscure Magic nearly forcing
> people to do it this way?

+1 to no obscure magic.

But yes, preventing Custom from writing to init file
should be done ("forcing", if you prefer that word).

> (Yes, the last bit of your proposal: "do the ... as a default behaviour"
> counts to me as Some Obscure Magic. I much prefer to have the load down
> there in my init file explicitly).

(See my reply to Pedro.)

Users should have complete control, including the
ability to (e.g. conditionally) not load
`custom-file' at all.  (E.g., the file might not
make sense when the moon is full.)

By default, `custom-file' (in some default
location) should be empty, in which case loading
it by default is a no-op.

It should never be loaded automatically if it's
already been loaded.  And we should even have a
variable that can prevent automatic loading
altogether.
___

All such details can be worked out.  The general
idea is that Custom should not write to your
init file (unless of course you explicitly set
`custom-file' to it for some, typically unwise,
reason).

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

[Stefan Kangas]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> What I propose is to agree on a default value for custom-file that could
> potentially be changed by the user in  init.el or .emacs
> and do the (load custom-file 'noerror) after loading the init file as a
> default behaviour for Emacs

FWIW, I support this proposal.

With such a default, I agree that we should load it after init.el by
default (so you don't need to type that into your init.el).

A function `load-custom-file' that loads the custom file if it isn't
already loaded might also make sense, to allow controlling the exact
time when it is loaded.

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

[Robert Pluim]

>>>>> On Tue, 4 Jan 2022 02:14:18 -0500, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
    >> What I propose is to agree on a default value for custom-file that could
    >> potentially be changed by the user in  init.el or .emacs
    >> and do the (load custom-file 'noerror) after loading the init file as a
    >> default behaviour for Emacs

    Stefan> FWIW, I support this proposal.

    Stefan> With such a default, I agree that we should load it after init.el by
    Stefan> default (so you don't need to type that into your init.el).

What would you do for users who already have 'custom-set-variables' in
their init file? You'd have to arrange for custom-file *not* to be set
for them, since otherwise subsequent saves of custom variables end up
in the wrong file.

Iʼm not 100% sure you'd want it loaded after the init file either: how
would you then do further changes that depend on the values set in
your custom file?

Robert
-- 

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

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 4 Jan 2022 02:14:18 -0500, Stefan Kangas <stefankangas@gmail.com> said:
>
>     Stefan> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>     >> What I propose is to agree on a default value for custom-file that could
>     >> potentially be changed by the user in  init.el or .emacs
>     >> and do the (load custom-file 'noerror) after loading the init file as a
>     >> default behaviour for Emacs
>
>     Stefan> FWIW, I support this proposal.
>
>     Stefan> With such a default, I agree that we should load it after init.el by
>     Stefan> default (so you don't need to type that into your init.el).
>
> What would you do for users who already have 'custom-set-variables' in
> their init file? You'd have to arrange for custom-file *not* to be set
> for them, since otherwise subsequent saves of custom variables end up
> in the wrong file.
>
> Iʼm not 100% sure you'd want it loaded after the init file either: how
> would you then do further changes that depend on the values set in
> your custom file?
>
> Robert

FWIW, I don't think any change to the default custom file would be a
good idea.  It's too well-established a default to be changed because
several people find it ugly.

Thanks.

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

[Robert Pluim]

>>>>> On Tue, 04 Jan 2022 18:30:53 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> FWIW, I don't think any change to the default custom file would be a
    Po> good idea.  It's too well-established a default to be changed because
    Po> several people find it ugly.

Plenty of people also object to Emacs writing stuff to their init file
by default.

How about: "use a separate custom file if the init file contains no
custom-set-variables nor custom-set-faces".

Of course, then weʼd have to add "(load custom-file)" to .emacs, so
people might still object :-)

Robert
-- 

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

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> Plenty of people also object to Emacs writing stuff to their init file
> by default.

I know that, mostly because I'm one of the people who object.  What I'm
saying is that the status quo seems to have kept people reasonably happy
for a long time, so there isn't a reason to change it.  There will also
be people who object to the new default, and in 15 years there might
even be a proposal to change the default back to the init file, and
things will start becoming confusing then.

> Of course, then weʼd have to add "(load custom-file)" to .emacs, so
> people might still object :-)

Indeed.

Thanks.

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

[Robert Pluim]

>>>>> On Tue, 04 Jan 2022 18:59:39 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Robert Pluim <rpluim@gmail.com> writes:
    >> Plenty of people also object to Emacs writing stuff to their init file
    >> by default.

    Po> I know that, mostly because I'm one of the people who object.  What I'm
    Po> saying is that the status quo seems to have kept people reasonably happy
    Po> for a long time, so there isn't a reason to change it.  There will also
    Po> be people who object to the new default, and in 15 years there might
    Po> even be a proposal to change the default back to the init file, and
    Po> things will start becoming confusing then.

I think that were we to automatically use and load a custom-file for people
with no config at all, that such a proposal would not arise.

Robert
-- 

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

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> What would you do for users who already have 'custom-set-variables' in
> their init file? You'd have to arrange for custom-file *not* to be set
> for them, since otherwise subsequent saves of custom variables end up
> in the wrong file.

Sounds like a good idea, yes.

> Iʼm not 100% sure you'd want it loaded after the init file either: how
> would you then do further changes that depend on the values set in
> your custom file?

What did XEmacs do?  ISTR that they had a separate custom file.

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

[LdBeth]

>>>>> In <CADwFkm=CkQZyr6wcSkBH0Vj6T+TKxLEPnWw0akC5iTH0LSWiDQ@mail.gmail.com> 
>>>>>	Stefan Kangas <stefankangas@gmail.com> wrote:

Robert> Iʼm not 100% sure you'd want it loaded after the init file either: how
Robert> would you then do further changes that depend on the values set in
Robert> your custom file?

Stefan> What did XEmacs do?  ISTR that they had a separate custom file.

Yes, as of XEmacs 21.4.7 they started saving to ~/.xemacs/custom.el
(specified by `custom-file' variable), and does not write anything
untill user has explicitly saved from the custom buffer (well, it
doesn't have package.el but instead something called package-get).

And custom.el is loaded after init.el, btw.

-- 
LDB

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

[Drew Adams]

> What would you do for users who already have 'custom-set-variables' in
> their init file?

Not a problem.  If they want `custom-file' to be
loaded at some explicit point, they do that in
the init file.  If they don't load it themselves
then - by default - it will be loaded after the
init file.  If they don't want it loaded
automatically at all, then they set a var that
prevents automatic loading.

> You'd have to arrange for custom-file *not* to
> be set for them, since otherwise subsequent
> saves of custom variables end up in the wrong file.

They would make any such arrangements themselves,
if they wanted.  Just set the var to never, ever,
load `custom-file'.

But what if they _want_ Customize changes to write
to their init file, and not to a `custom-file'
that they've configured to never get loaded?

(setq custom-file "/LOCATION/OF/MY/INIT-FILE")

> Iʼm not 100% sure you'd want it loaded after the init file either: how
> would you then do further changes that depend on the values set in
> your custom file?

Again, you control when, and even if, `custom-file'
gets loaded.  If you don't ever load it explicitly,
and if you don't set the variable to prevent it
from ever being loaded, then it's never loaded.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 4 Jan 2022 02:14:18 -0500
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> 
> > What I propose is to agree on a default value for custom-file that could
> > potentially be changed by the user in  init.el or .emacs
> > and do the (load custom-file 'noerror) after loading the init file as a
> > default behaviour for Emacs
> 
> FWIW, I support this proposal.
> 
> With such a default, I agree that we should load it after init.el by
> default (so you don't need to type that into your init.el).
> 
> A function `load-custom-file' that loads the custom file if it isn't
> already loaded might also make sense, to allow controlling the exact
> time when it is loaded.

What would that mean for users that currently save their
customizations through Custom in .emacs?  Would it mean that the next
time they save customizations, they will be written to another file
and removed from .emacs?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> What would that mean for users that currently save their
> customizations through Custom in .emacs?  Would it mean that the next
> time they save customizations, they will be written to another file
> and removed from .emacs?

Good question.

I imagine that we would just leave things in place for such users.  It
would be slightly jarring to have things moved around behind the users
back.

But maybe it would be a good idea to provide a migration command to
conveniently move things.

Or we could prompt the user about moving it.  To avoid being annoying,
we could record the answer, and not prompt again if the question was
already asked.

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

[Robert Pluim]

>>>>> On Tue, 4 Jan 2022 10:17:46 -0500, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Eli Zaretskii <eliz@gnu.org> writes:
    >> What would that mean for users that currently save their
    >> customizations through Custom in .emacs?  Would it mean that the next
    >> time they save customizations, they will be written to another file
    >> and removed from .emacs?

    Stefan> Good question.

    Stefan> I imagine that we would just leave things in place for such users.  It
    Stefan> would be slightly jarring to have things moved around behind the users
    Stefan> back.

    Stefan> But maybe it would be a good idea to provide a migration command to
    Stefan> conveniently move things.

    Stefan> Or we could prompt the user about moving it.  To avoid being annoying,
    Stefan> we could record the answer, and not prompt again if the question was
    Stefan> already asked.

Didnʼt XEmacs have a "would you like to move .emacs to
.xemacs/init.el" startup thingy? Itʼs been a while since I used
XEmacs. *If* we did this, weʼd have to be very careful when it got
triggered, lest hordes of pitchfork-wielding users descend.

Robert
-- 

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

<LoL> I think it was like that in XEmacs and always +1 to doing things
carefully :-)

On Tue, 4 Jan 2022 at 16:48, Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Tue, 4 Jan 2022 10:17:46 -0500, Stefan Kangas <
> stefankangas@gmail.com> said:
>
>     Stefan> Eli Zaretskii <eliz@gnu.org> writes:
>     >> What would that mean for users that currently save their
>     >> customizations through Custom in .emacs?  Would it mean that the
> next
>     >> time they save customizations, they will be written to another file
>     >> and removed from .emacs?
>
>     Stefan> Good question.
>
>     Stefan> I imagine that we would just leave things in place for such
> users.  It
>     Stefan> would be slightly jarring to have things moved around behind
> the users
>     Stefan> back.
>
>     Stefan> But maybe it would be a good idea to provide a migration
> command to
>     Stefan> conveniently move things.
>
>     Stefan> Or we could prompt the user about moving it.  To avoid being
> annoying,
>     Stefan> we could record the answer, and not prompt again if the
> question was
>     Stefan> already asked.
>
> Didnʼt XEmacs have a "would you like to move .emacs to
> .xemacs/init.el" startup thingy? Itʼs been a while since I used
> XEmacs. *If* we did this, weʼd have to be very careful when it got
> triggered, lest hordes of pitchfork-wielding users descend.
>
> Robert
> --
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2238 bytes --]

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

It's a really good question...
I started on an HP700, it created the .emacs file and I was always confused
about what I had written myself and what emacs was doing. Then I started on
an Sun Workstation and there they had installed XEmacs. It was there where
i stumbled across the .emacs.d/custom.el file and I found the idea cool. I
investigated a bit and adopted loading the custom file. <mea culpa>I never
investigated how customisation where added to .emacs </mea culpa>
I don't know how common my way of working is but I try out things using
Custom and then, if I adopt them, they become a part of my permanent
config.
Maybe Custom wlll need to check and eventually remove customisations from
.emacs if custom-file is defined... would that be feasible? IT isn't
something you do 10 times a second, right?

Best, /PA

On Tue, 4 Jan 2022 at 16:17, Stefan Kangas <stefankangas@gmail.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > What would that mean for users that currently save their
> > customizations through Custom in .emacs?  Would it mean that the next
> > time they save customizations, they will be written to another file
> > and removed from .emacs?
>
> Good question.
>
> I imagine that we would just leave things in place for such users.  It
> would be slightly jarring to have things moved around behind the users
> back.
>
> But maybe it would be a good idea to provide a migration command to
> conveniently move things.
>
> Or we could prompt the user about moving it.  To avoid being annoying,
> we could record the answer, and not prompt again if the question was
> already asked.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2390 bytes --]

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

[Drew Adams]

> What would that mean for users that currently save their
> customizations through Custom in .emacs?  Would it mean that the next
> time they save customizations, they will be written to another file
> and removed from .emacs?

See my previous replies about this.

If you want to continue to use only the init
file, just set `custom-file' to that file.
Or set a variable (TBD) to tell Emacs to never
load `custom-file' automatically.

If you want to change, to use only `custom-file'
for `custom*' stuff, move such settings from
your init file to your `custom-file'.  (And yes,
we should have a command that does that moving.)

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

[Robert Pluim]

>>>>> On Tue, 4 Jan 2022 16:44:44 +0000, Drew Adams <drew.adams@oracle.com> said:

    >> What would that mean for users that currently save their
    >> customizations through Custom in .emacs?  Would it mean that the next
    >> time they save customizations, they will be written to another file
    >> and removed from .emacs?

    Drew> See my previous replies about this.

    Drew> If you want to continue to use only the init
    Drew> file, just set `custom-file' to that file.
    Drew> Or set a variable (TBD) to tell Emacs to never
    Drew> load `custom-file' automatically.

    Drew> If you want to change, to use only `custom-file'
    Drew> for `custom*' stuff, move such settings from
    Drew> your init file to your `custom-file'.  (And yes,
    Drew> we should have a command that does that moving.)

Making people who wish to retain long-standing behaviour set a
variable or edit a config file for something as fundamental as loading
and saving customizations is not something I would want, ever. The
*only* case I can see where we could set custom-file to eg
~/.emacs.d/custom.el (and maybe load it automatically) is for people
with no customizations.

Robert
-- 

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

[Drew Adams]

>     Drew> If you want to continue to use only the init
>     Drew> file, just set `custom-file' to that file.
>     Drew> Or set a variable (TBD) to tell Emacs to never
>     Drew> load `custom-file' automatically.
> 
>     Drew> If you want to change, to use only `custom-file'
>     Drew> for `custom*' stuff, move such settings from
>     Drew> your init file to your `custom-file'.  (And yes,
>     Drew> we should have a command that does that moving.)
> 
> Making people who wish to retain long-standing behaviour set a
> variable or edit a config file for something as fundamental as loading
> and saving customizations is not something I would want, ever. The
> *only* case I can see where we could set custom-file to eg
> ~/.emacs.d/custom.el (and maybe load it automatically) is for people
> with no customizations.

It sounds like what you're really saying is that you
don't want Emacs to use `custom-file' for Custom
stuff, by default.

The advantages, for the great majority of users, and
in particular for new users, vastly outweigh the
inconvenience to anyone who _really_ wants to keep
things as they are for themselves.

They/you need only (setq custom-file THE-INIT-FILE).

They could always have done that.  And it's always
been essentially a no-op in similar situations -
see _function_ `custom-file', which is used by
`custom-save-all'.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

> The *only* case I can see where we could set custom-file to eg
> ~/.emacs.d/custom.el (and maybe load it automatically) is for people
> with no customizations.

Hmmm??? I don't get it... really and humbly sorry. My initial take is that
things will be clearer if you
split things between init.el and custom.el.
Customising and initialising are two different although related things.
I think it is less dangerous to delete the custom.el file and leave the
init.el file untouched than to edit
the .emacs or the init.el file. More so for novice users.

/PA

On Tue, 4 Jan 2022 at 18:14, Drew Adams <drew.adams@oracle.com> wrote:

> >     Drew> If you want to continue to use only the init
> >     Drew> file, just set `custom-file' to that file.
> >     Drew> Or set a variable (TBD) to tell Emacs to never
> >     Drew> load `custom-file' automatically.
> >
> >     Drew> If you want to change, to use only `custom-file'
> >     Drew> for `custom*' stuff, move such settings from
> >     Drew> your init file to your `custom-file'.  (And yes,
> >     Drew> we should have a command that does that moving.)
> >
> > Making people who wish to retain long-standing behaviour set a
> > variable or edit a config file for something as fundamental as loading
> > and saving customizations is not something I would want, ever. The
> > *only* case I can see where we could set custom-file to eg
> > ~/.emacs.d/custom.el (and maybe load it automatically) is for people
> > with no customizations.
>
> It sounds like what you're really saying is that you
> don't want Emacs to use `custom-file' for Custom
> stuff, by default.
>
> The advantages, for the great majority of users, and
> in particular for new users, vastly outweigh the
> inconvenience to anyone who _really_ wants to keep
> things as they are for themselves.
>
> They/you need only (setq custom-file THE-INIT-FILE).
>
> They could always have done that.  And it's always
> been essentially a no-op in similar situations -
> see _function_ `custom-file', which is used by
> `custom-save-all'.
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

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

[Drew Adams]

>> The *only* case I can see where we could set
>> custom-file to eg ~/.emacs.d/custom.el (and
>> maybe load it automatically) is for people
>> with no customizations.
>
> Hmmm??? I don't get it... really and humbly sorry.
> My initial take is that things will be clearer if
> you split things between init.el and custom.el.

Definitely.  Your initial take is correct.

> Customising and initialising are two different
> although related things.   I think it is less
> dangerous to delete the custom.el file and leave
> the init.el file untouched than to edit the
> .emacs or the init.el file. More so for novice users.

Definitely.  This is a case where requiring those
users who insist on keeping things as they are
(living dangerously) would suffer a  v e r y  mild
one-time inconvenience.  They'd just make a simple
addition to their init files: (setq custom-file
MY-INIT-FILE).

I often defend _not_ changing default behavior,
especially when it's longstanding (and often to
no avail, alas).

This is a rare case where the advantages of a
simple change vastly outweigh the disadvantages.

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

[Robert Pluim]

>>>>> On Tue, 4 Jan 2022 18:32:14 +0100, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    >> The *only* case I can see where we could set custom-file to eg
    >> ~/.emacs.d/custom.el (and maybe load it automatically) is for people
    >> with no customizations.

    Pedro> Hmmm??? I don't get it... really and humbly sorry. My initial take is that
    Pedro> things will be clearer if you
    Pedro> split things between init.el and custom.el.
    Pedro> Customising and initialising are two different although related things.
    Pedro> I think it is less dangerous to delete the custom.el file and leave the
    Pedro> init.el file untouched than to edit
    Pedro> the .emacs or the init.el file. More so for novice users.

Iʼm not arguing against splitting custom and init. Iʼm saying you
canʼt do that automatically except in very specific circumstances,
since you will surprise and inconvenience people accustomed to the
current behaviour.

Robert
-- 

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

[Pedro Andres Aranda Gutierrez]

Ahh got it and yes you are right
/PA

Enviado desde mi iPhone

> El 4 ene 2022, a las 18:56, Robert Pluim <rpluim@gmail.com> escribió:
> 
> 
>> 
>>>>>> On Tue, 4 Jan 2022 18:32:14 +0100, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:
> 
>>> The *only* case I can see where we could set custom-file to eg
>>> ~/.emacs.d/custom.el (and maybe load it automatically) is for people
>>> with no customizations.
> 
>    Pedro> Hmmm??? I don't get it... really and humbly sorry. My initial take is that
>    Pedro> things will be clearer if you
>    Pedro> split things between init.el and custom.el.
>    Pedro> Customising and initialising are two different although related things.
>    Pedro> I think it is less dangerous to delete the custom.el file and leave the
>    Pedro> init.el file untouched than to edit
>    Pedro> the .emacs or the init.el file. More so for novice users.
> 
> Iʼm not arguing against splitting custom and init. Iʼm saying you
> canʼt do that automatically except in very specific circumstances,
> since you will surprise and inconvenience people accustomed to the
> current behaviour.
> 
> Robert
> -- 

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 04 Jan 2022 17:49:22 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>  Stefan Kangas <stefankangas@gmail.com>,
>  "paaguti@gmail.com" <paaguti@gmail.com>
> 
>     Drew> If you want to change, to use only `custom-file'
>     Drew> for `custom*' stuff, move such settings from
>     Drew> your init file to your `custom-file'.  (And yes,
>     Drew> we should have a command that does that moving.)
> 
> Making people who wish to retain long-standing behaviour set a
> variable or edit a config file for something as fundamental as loading
> and saving customizations is not something I would want, ever. The
> *only* case I can see where we could set custom-file to eg
> ~/.emacs.d/custom.el (and maybe load it automatically) is for people
> with no customizations.

Agreed.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

If something is long-standing, I'd rather have it in init.el and leave
custom.el for "experiments".
Wouldn't that make interacting with emacs more dynamic/attractive to new
users?

/PA

On Tue, 4 Jan 2022 at 18:30, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Pluim <rpluim@gmail.com>
> > Date: Tue, 04 Jan 2022 17:49:22 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <
> emacs-devel@gnu.org>,
> >  Stefan Kangas <stefankangas@gmail.com>,
> >  "paaguti@gmail.com" <paaguti@gmail.com>
> >
> >     Drew> If you want to change, to use only `custom-file'
> >     Drew> for `custom*' stuff, move such settings from
> >     Drew> your init file to your `custom-file'.  (And yes,
> >     Drew> we should have a command that does that moving.)
> >
> > Making people who wish to retain long-standing behaviour set a
> > variable or edit a config file for something as fundamental as loading
> > and saving customizations is not something I would want, ever. The
> > *only* case I can see where we could set custom-file to eg
> > ~/.emacs.d/custom.el (and maybe load it automatically) is for people
> > with no customizations.
>
> Agreed.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]

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

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Tue, 4 Jan 2022 18:35:19 +0100
> Cc: Robert Pluim <rpluim@gmail.com>, Drew Adams <drew.adams@oracle.com>, 
> 	emacs-devel <emacs-devel@gnu.org>, Stefan Kangas <stefankangas@gmail.com>
> 
> If something is long-standing, I'd rather have it in init.el and leave custom.el for "experiments".
> Wouldn't that make interacting with emacs more dynamic/attractive to new users?

Robert's and mine concern in this case is about old users who have
their customizations written to .emacs/init.el.  We shouldn't move the
customizations behind their backs.

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

[Robert Pluim]

>>>>> On Tue, 04 Jan 2022 19:47:55 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
    >> Date: Tue, 4 Jan 2022 18:35:19 +0100
    >> Cc: Robert Pluim <rpluim@gmail.com>, Drew Adams <drew.adams@oracle.com>, 
    >> emacs-devel <emacs-devel@gnu.org>, Stefan Kangas <stefankangas@gmail.com>
    >> 
    >> If something is long-standing, I'd rather have it in init.el and leave custom.el for "experiments".
    >> Wouldn't that make interacting with emacs more dynamic/attractive to new users?

    Eli> Robert's and mine concern in this case is about old users who have
    Eli> their customizations written to .emacs/init.el.  We shouldn't move the
    Eli> customizations behind their backs.

Exactly. Although we could offer a migration command (and when I say
'offer', I mean 'describe in NEWS', not 'prompt when they run Emacs').

Robert
-- 

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

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> Exactly. Although we could offer a migration command (and when I say
> 'offer', I mean 'describe in NEWS', not 'prompt when they run Emacs').

If we do this job right, I expect that people will be happily having
their customize specifications in init.el for years to come without any
issues.  It also doesn't seem important enough to be bothering people
about.

I therefore think you're right that we shouldn't prompt about it, and
that calling it out in NEWS is enough.

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

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> Making people who wish to retain long-standing behaviour set a
> variable or edit a config file for something as fundamental as loading
> and saving customizations is not something I would want, ever.

Agreed, and I also think that long-standing behaviour should never
change as well, even for sites that have Emacs freshly installed.

Thanks.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

Let me try to put it another way: as I envisage the whole process

1.- On startup:
a) Get the startup file from [ .emacs, .emacs.d/init.el,
.config/emacs/init.el ] or whatever set of files we decide and load it
b) if custom-file is not nil and wasn't already loaded, load custom-file.
If is was already loaded, maybe tell the user (???)

2.- When saving the customisations
if custom-file is not nil, save them there else save them in the startup
file whatever it is

AFAIK, the only new thing is to include 1b) in the emacs code, because 1a)
and 2) are already in the code (it's how emacs behaves today, right?)

So someone not defining custom-file would not see anything changing
(long-standing behaviour respected)

Just my .2 cents, /PA


On Wed, 5 Jan 2022 at 02:01, Po Lu <luangruo@yahoo.com> wrote:

> Robert Pluim <rpluim@gmail.com> writes:
>
> > Making people who wish to retain long-standing behaviour set a
> > variable or edit a config file for something as fundamental as loading
> > and saving customizations is not something I would want, ever.
>
> Agreed, and I also think that long-standing behaviour should never
> change as well, even for sites that have Emacs freshly installed.
>
> Thanks.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2048 bytes --]

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

PS: to 1b)
if custom-file was already loaded, it will be in variable load-history

/PA

On Wed, 5 Jan 2022 at 08:03, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> Let me try to put it another way: as I envisage the whole process
>
> 1.- On startup:
> a) Get the startup file from [ .emacs, .emacs.d/init.el,
> .config/emacs/init.el ] or whatever set of files we decide and load it
> b) if custom-file is not nil and wasn't already loaded, load custom-file.
> If is was already loaded, maybe tell the user (???)
>
> 2.- When saving the customisations
> if custom-file is not nil, save them there else save them in the startup
> file whatever it is
>
> AFAIK, the only new thing is to include 1b) in the emacs code, because 1a)
> and 2) are already in the code (it's how emacs behaves today, right?)
>
> So someone not defining custom-file would not see anything changing
> (long-standing behaviour respected)
>
> Just my .2 cents, /PA
>
>
> On Wed, 5 Jan 2022 at 02:01, Po Lu <luangruo@yahoo.com> wrote:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>> > Making people who wish to retain long-standing behaviour set a
>> > variable or edit a config file for something as fundamental as loading
>> > and saving customizations is not something I would want, ever.
>>
>> Agreed, and I also think that long-standing behaviour should never
>> change as well, even for sites that have Emacs freshly installed.
>>
>> Thanks.
>>
>
>
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2794 bytes --]

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

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> So someone not defining custom-file would not see anything changing
> (long-standing behaviour respected)

I thought the proposal was to make custom-file default to
"~/.emacs.d/custom.el" or some variant thereof.

If all you want is to add a prompt the first time a user saves some
customizations asking him to choose whether or not to use a custom file,
then I'm happy.

Thanks.

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

[Drew Adams]

> > So someone not defining custom-file would not see
> > anything changing (long-standing behaviour respected)
> 
> I thought the proposal was to make custom-file default to
> "~/.emacs.d/custom.el" or some variant thereof.

Right.  That was my proposal, at least.

Currently we implicitly have `custom-file' =
init file.  (That's the default behavior, and
it's only implicit - the value of `custom-file'
is not the location of your init file.

My proposal would force you to make that
identification explicit, setting `custom-file'
to your init file location.

> If all you want is to add a prompt the first time a user saves some
> customizations asking him to choose whether or not to use a custom file,
> then I'm happy.

You're happy in that case, but I'm not. ;-)

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

[Po Lu]

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

> You're happy in that case, but I'm not. ;-)

Most people were certainly happy for at least the past decade.

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

[LdBeth]

>>>>> In <87bl0q8vfa.fsf@yahoo.com> 
>>>>>	Po Lu <luangruo@yahoo.com> wrote:

> Most people were certainly happy for at least the past decade.

I think saving custom set variables to init file somehow prevents
using byte compiled init.el file effectively (unless the user hooks
auto compile whenever it is changed by emacs). From that perspective,
I'm happy to see that this behavior is to be changed.

-- 
LDB

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

[Robert Pluim]

>>>>> On Wed, 05 Jan 2022 17:17:12 +0800, LdBeth <andpuke@foxmail.com> said:

>>>>> In <87bl0q8vfa.fsf@yahoo.com> 
    >>>>>> Po Lu <luangruo@yahoo.com> wrote:

    >> Most people were certainly happy for at least the past decade.

    LdBeth> I think saving custom set variables to init file somehow prevents
    LdBeth> using byte compiled init.el file effectively (unless the user hooks
    LdBeth> auto compile whenever it is changed by emacs). From that perspective,
    LdBeth> I'm happy to see that this behavior is to be changed.

This is one of the two things that people do with Emacs that I just
donʼt understand. My init file contains setq and custom-set-variables
and key bindings. Any actual code that would benefit from
byte-compilation is stored in separate files. So why do people
byte-compile their init files?

Robert
-- 

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

[Colin Baxter 😺]

>>>>> Robert Pluim <rpluim@gmail.com> writes:

>>>>> On Wed, 05 Jan 2022 17:17:12 +0800, LdBeth <andpuke@foxmail.com> said:
>>>>> In <87bl0q8vfa.fsf@yahoo.com> 
    >>>>>>> Po Lu <luangruo@yahoo.com> wrote:

    >>> Most people were certainly happy for at least the past decade.

    LdBeth> I think saving custom set variables to init file somehow
    LdBeth> prevents using byte compiled init.el file effectively
    LdBeth> (unless the user hooks auto compile whenever it is changed
    LdBeth> by emacs). From that perspective, I'm happy to see that this
    LdBeth> behavior is to be changed.

    > This is one of the two things that people do with Emacs that I
    > just donʼt understand. My init file contains setq and
    > custom-set-variables and key bindings. Any actual code that would
    > benefit from byte-compilation is stored in separate files. So why
    > do people byte-compile their init files?

Well, I can't speak for "people" but I can say why I byte compile my
~/.emacs, which I've done for many years. I have found it to be a useful
check on my lisp in finding silly errors. It has also on more than one
occasion allowed me to run emacs when my ~/.emacs was either corrupted
or "helpfully" over-written by some application. I wouldn't tell other
users to do the same - what they do is up to them.

Colin

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

[Po Lu]

Colin Baxter 😺 <m43cap@yandex.com> writes:

> Well, I can't speak for "people" but I can say why I byte compile my
> ~/.emacs, which I've done for many years. I have found it to be a useful
> check on my lisp in finding silly errors.

IMSHO the thing to do in that case is to byte-compile your init file,
then delete the resulting .elc.

That's what I've been doing for a long time, and it's worked admirably
all the way through.

Thanks.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1.1: Type: text/plain, Size: 2045 bytes --]

Say we go a conservative approach and we only load custom-file
automatically if set by the user.
We wait to see if people like it and then include a message when
custom-file was already loaded by the user.
And finally we attempt the 'revolution' setting a default value for
custom-file and requiring users to set it to nil if they want the original
emacs behaviour.

Attached is an attempt at a patch for the first step:

/PA

On Wed, 5 Jan 2022 at 11:54, Colin Baxter 😺 <m43cap@yandex.com> wrote:

> >>>>> Robert Pluim <rpluim@gmail.com> writes:
>
> >>>>> On Wed, 05 Jan 2022 17:17:12 +0800, LdBeth <andpuke@foxmail.com>
> said:
> >>>>> In <87bl0q8vfa.fsf@yahoo.com>
>     >>>>>>> Po Lu <luangruo@yahoo.com> wrote:
>
>     >>> Most people were certainly happy for at least the past decade.
>
>     LdBeth> I think saving custom set variables to init file somehow
>     LdBeth> prevents using byte compiled init.el file effectively
>     LdBeth> (unless the user hooks auto compile whenever it is changed
>     LdBeth> by emacs). From that perspective, I'm happy to see that this
>     LdBeth> behavior is to be changed.
>
>     > This is one of the two things that people do with Emacs that I
>     > just donʼt understand. My init file contains setq and
>     > custom-set-variables and key bindings. Any actual code that would
>     > benefit from byte-compilation is stored in separate files. So why
>     > do people byte-compile their init files?
>
> Well, I can't speak for "people" but I can say why I byte compile my
> ~/.emacs, which I've done for many years. I have found it to be a useful
> check on my lisp in finding silly errors. It has also on more than one
> occasion allowed me to run emacs when my ~/.emacs was either corrupted
> or "helpfully" over-written by some application. I wouldn't tell other
> users to do the same - what they do is up to them.
>
> Colin
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #1.2: Type: text/html, Size: 3023 bytes --]

[-- Attachment #2: auto-load-custom.diff --]
[-- Type: text/x-patch, Size: 698 bytes --]

diff --git a/lisp/startup.el b/lisp/startup.el
index d90e7a7..157b2fd 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1410,6 +1410,13 @@ command-line
           "init.el"
           startup-init-directory))
        t)
+      ;; if the user defined the custom-file
+      (when custom-file
+          ;; make sure that you get the expanded custom-file name
+          (let* ((real-custom-file (expand-file-name custom-file)))
+            ;; if it was loaded, assoc will return non-nil
+            (unless (assoc real-custom-file load-history)
+              (load real-custom-file t))))
 
       (when (and deactivate-mark transient-mark-mode)
         (with-current-buffer (window-buffer)

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

[Colin Baxter 😺]

>>>>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

    > Say we go a conservative approach and we only load custom-file
    > automatically if set by the user.  We wait to see if people like
    > it and then include a message when custom-file was already loaded
    > by the user.  And finally we attempt the 'revolution' setting a
    > default value for custom-file and requiring users to set it to nil
    > if they want the original emacs behaviour.

For me, I'd prefer the other way round, i.e. the default is nil.

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

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Say we go a conservative approach and we only load custom-file
> automatically if set by the user.

I have this in init.el:

  (setq custom-file (expand-file-name "custom.el"
  				      user-emacs-directory))
  (load custom-file)

I don't understand what's so bad about the third line that warrants
loading the custom file by default.

That method of loading the custom file is even documented in the doc
string of `custom-file', so everyone who changes his custom file should
know about it.

Besides, since the original discussion was about a setup wizard, we
could arrange for that setup wizard to set up the custom file for the
user if he so desires.

> We wait to see if people like it and then include a message when
> custom-file was already loaded by the user.

Sometimes it is important for the user to manually control when the
custom file is loaded.  Having such a message would lead to an
unreasonable amount of false positives, just like highlighting all
bidirectional reordering characters in source code would.

Thanks.

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

[Drew Adams]

> I have this in init.el:
>   (setq custom-file (expand-file-name "custom.el"
>                                       user-emacs-directory))
>   (load custom-file)
> 
> I don't understand what's so bad about the
> third line that warrants loading the custom
> file by default.

Just to be sure, in case you misunderstood
something about what I (at least) proposed:

In what I wrote, `custom-file' would only be
loaded automatically, just after the init file,
_IF it was NOT already loaded_.

Your scenario/code is _exactly_ what I think
should be encouraged.

It's what I do too.  (But I actually load it
twice in my init file, to pick up settings
before, and after, particular libraries get
loaded.)

I don't think we should _require_ explicit
loading of `custom-file' in init file (or in
a file loaded by init file etc.).

I think `custom-file' should get loaded
automatically, once its default value gets
changed to something agreed on, such as
"~/.emacs-custom.el".

But I don't think it's bad to encourage
_loading it explicitly_ from one's init file.

And certainly we should point out that you
_can_ do that, and that gives you control
over just when it gets loaded.

> That method of loading the custom file is
> even documented in the doc string of
> `custom-file', so everyone who changes his
> custom file should know about it.

Absolutely.

> Besides, since the original discussion was
> about a setup wizard, we could arrange for
> that setup wizard to set up the custom file
> for the user if he so desires.

Sure, maybe.  And I think that thread talked
about the possibility of multiple such wizards,
or configuring the wizard?  Such things are
possible, if/when we get to defining wizards.

The devil will be in the details of what is
decided for such wizard design.

> > We wait to see if people like it and then
> > include a message when custom-file was
> > already loaded by the user.
> 
> Sometimes it is important for the user to
> manually control when the custom file is loaded.

Absolutely.  And it's always preferable, IMO,
to load it explicitly.  It's good for users
to see where/when they're loading it.

> Having such a message would lead to an
> unreasonable amount of false positives

I agree that such a message would be bad, not
good.  (I also don't think a message saying
that it was loaded automatically would be good.)

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

[Drew Adams]

[Please use plain-text email for the list.]

> Say we go a conservative approach and we only load custom-file automatically if set by the user. We wait to see if people like it and then include a message when custom-file was already loaded by the user. And finally we attempt the 'revolution' setting a default value for custom-file and requiring users to set it to nil if they want the original emacs behaviour.

This is a bit long, but I think it's relatively succinct.

1. Whether to load `custom-file' automatically after the init file is an open question.

2. That should never be done if it's already been loaded.  In that case, it's clear that the user, one way or another, is controlling when to load it.

3. If, after loading the init file, `custom-file' has not yet been loaded, `custom-file' is loaded (automatically).  (Obviously this can only be the case when it's not the same file as the init file.) 

#3 is a no-op if the `custom-file' is empty.  If you never use Customize (or its functions) to save customize changes - e.g., you use `custom(ize)-set-variable(s)' only in your init file etc. - then Customize is out of the picture wrt writing.

4. There would be a new variable that you can set or test, which will prevent #3: no automatic loading of `custom-file'.  

Why?  Just as you might want to explicitly control where/when, and how many times, you load `custom-file', so you might want to prevent loading it altogether in some (probably uncommon) situations.

5. `emacs -q' and `emacs -Q' should not load the `custom-file'.  That is, the (conditional) automatic loading after the init file should happen only when the init file is actually loaded.

In addition, we should add a new switch that suppresses (only) loading of the `custom-file', i.e., does the same thing as the variable of #4.  It wouldn't prevent loading the init file, and it wouldn't prevent loading `custom-file' explicitly from the init file.

6. `custom-file' should have a default value/location. E.g. 

 (defcustom custom-file "~/.emacs-custom.el" ...)

This change would make it so that even _users doing nothing_ get a separate `custom-file'.  That's the right thing as the default behavior.

Any users who really want/need to have Customize use their init file would need to make a tiny change, yes.

Currently a nil value of `custom-file' has the effect of using the init file.  That's the situation to be avoided as the default scenario.

We could, however, keep the longstanding nil-means-use-init-file behavior, so that if you _explicitly_ set `custom-file' to nil it's the same as setting it to the value of `user-init-file'. 

Would that be a good idea?  It's maybe not as clear as explicitly specifying the init file location, but it would work.

Explicitly setting to nil means, of course, that users who want to continue having Customize use their init file would still need to make a change: set `custom-file' to either nil or the init file location.

7. Suppose a longtime user doesn't read the NEWS etc., and _does nothing_.  What happens then?  Is there a problem?

a. Any `custom*' stuff in the init file is respected when that file is loaded.

b. If the init file doesn't load `custom-file', then it gets loaded automatically (from its default location).  If that file doesn't exist, this step is a no-op.

c. If the user then makes some custom* changes and saves them, they're saved to the default `custom-file' location, _not_ to the init file.

d. In the next Emacs session, steps (a) and (b) are repeated.  This time, the `custom-file' exists, so that any saved changes for custom vars and faces are respected.

If the init file still contains some custom* setting, it's still respected, unless that same var/face was saved to `custom-file' with a different value.  In effect, `custom-file' settings override any for the same vars/faces in the init file.

8. #7 is the case some people have howled about.  Is it really a problem?  It could be, in this scenario:

Suppose that at some point in the past you set option `foo' to 10 in your init file.  And you later used Customize to change `foo' to 42 and save it (to your `custom-file' - the new default behavior).  You might have been thinking that Customize was still saving to your init file, replacing that previous setting of 10.

Still later (e.g. from habit) you edit your init file, to change the value of `foo' from 10 to 314.  Next session, `foo' is 42, not 314 (assuming `custom-file' still gets loaded automatically after the init file).

That's what comes from possibly having two locations where you set custom* stuff.  At that point (once you figure out what happened), you can do either of the following, to get straight:

a. Move your custom* stuff from your init file to your `custom-file' (or just delete it from your init file).

From now on, you use only `custom-file' for saving custom* stuff.

b. Set `custom-file' to your init file (or to nil, if we allow that to give the same behavior).

From now on, you use only your init file for custom* stuff, just as you did in the past.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Robert Pluim <rpluim@gmail.com>, LdBeth <andpuke@foxmail.com>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>         Po Lu <luangruo@yahoo.com>, Stefan Kangas <stefankangas@gmail.com>,
>         Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 5 Jan 2022 19:02:15 +0000
> 
> [Please use plain-text email for the list.]

There's no such requirement on this list.

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

[Drew Adams]

> > [Please use plain-text email for the list.]
> 
> There's no such requirement on this list.

Right.  And no one said there's such a requirement.
But it's good to point out what you did.

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

[Po Lu]

LdBeth <andpuke@foxmail.com> writes:

> I think saving custom set variables to init file somehow prevents
> using byte compiled init.el file effectively (unless the user hooks
> auto compile whenever it is changed by emacs). From that perspective,
> I'm happy to see that this behavior is to be changed.

Why byte-compile your init file?  It usually makes no measurable
difference whatsoever, except it breaks things like custom-set-variables
and inhibit-startup-echo-area-message.

Thanks.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

OK, lots of things to react to.

> Not defining `custom-file' _would_ change the
> behavior.  Setting `custom-file' to your init
> file would keep the current default behavior of
> Customize using your init file.

IMHO, that's a bit more disruptive (Po Lu, you made me think about that ;-)
)...
And using the NEWS to explain the change might have people getting mad.

My approach, as detailed above. might be less "aggressive", right? Wouldn't
be people happier with it?
Like in "I didn't say anything about custom-file, so if I don't, nothing
changes"
Then they can eventually set custom-file to "~/.emacs.d/custom.el" to
migrate (NEWS might be a nice place to advertise this)

With that I'd be more than happy, because I would be able to define my OS
specific custom-file and have it loaded.

> Why byte-compile your init file?
That was something I wasn't thinking about. I never byte-compiled my init
file, nor would I think that custom-file should be byte-compiled either :-)

/PA

On Wed, 5 Jan 2022 at 10:35, Po Lu <luangruo@yahoo.com> wrote:

> LdBeth <andpuke@foxmail.com> writes:
>
> > I think saving custom set variables to init file somehow prevents
> > using byte compiled init.el file effectively (unless the user hooks
> > auto compile whenever it is changed by emacs). From that perspective,
> > I'm happy to see that this behavior is to be changed.
>
> Why byte-compile your init file?  It usually makes no measurable
> difference whatsoever, except it breaks things like custom-set-variables
> and inhibit-startup-echo-area-message.
>
> Thanks.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2519 bytes --]

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

[xenodasein--- via Emacs development discussions.]

Jan 5, 2022, 12:58 by paaguti@gmail.com:

> ...
> > Why byte-compile your init file?
> That was something I wasn't thinking about. I never byte-compiled my init file, nor would I think that custom-file should be byte-compiled either :-)
>

Many Emacs users seem to have a fascination with squeezing even more
milliseconds out of a faster start up.  One could consider it trainspotting,
but an IDE user who is only concerned with brutal efficiency could accuse
us of the same.

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

[LdBeth]

>>>>> In <8735m28qzr.fsf@yahoo.com> 
>>>>>	Po Lu <luangruo@yahoo.com> wrote:

ldb> I think saving custom set variables to init file somehow prevents
ldb> using byte compiled init.el file effectively (unless the user
ldb> hooks auto compile whenever it is changed by emacs). From that
ldb> perspective, I'm happy to see that this behavior is to be
ldb> changed.

PL> Why byte-compile your init file?  It usually makes no measurable
PL> difference whatsoever, except it breaks things like
PL> custom-set-variables and inhibit-startup-echo-area-message.

PL> Thanks.

In case heavy macros like `use-package' are used in the init file, and
by taking advantages of `eval-when-compile' a lot, byte-compiled init
file does make some difference.

I can't tell if writing custom-set-variables to init file by default
has made many people prefer a structured hierarchy instead of a single
init.el file. Having a single well debugged .emacs.elc been copied
across instances could be a choice.

Occasionally I see people using one Org-mode file to generate their
Emacs config files#1#, that's another kind of over engineering.

> inhibit-startup-echo-area-message

That's a hack :-) And the docstring already tells us a hackish
workaround:

> If your init file is byte-compiled, use the following form
> instead:
> (eval '(setq inhibit-startup-echo-area-message "YOUR-USER-NAME"))

And I would not get very disappointed by either way, because I've
already went with a structured config directory.

-- 
LDB

#1#=(I trend to not make judgment on the usefulness of Literate
Programming, but it is certainly meaningless to use it on something
that nobody else would read)

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

[Po Lu]

LdBeth <andpuke@foxmail.com> writes:

> In case heavy macros like `use-package' are used in the init file, and
> by taking advantages of `eval-when-compile' a lot, byte-compiled init
> file does make some difference.

That does seem like a problem with use-package and not a problem with
custom.  Either way, I think supporting the byte-compilation of the init
file by default is not good enough a reason to change behavior that has
stood for long enough to have placated many.

Thanks.

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

[Eli Zaretskii]

> Date: Wed, 05 Jan 2022 17:17:12 +0800
> From: LdBeth <andpuke@foxmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>,
> 	Pedro Andres Aranda Gutierrez <paaguti@gmail.com>,
> 	Robert Pluim
>  <rpluim@gmail.com>,
> 	Eli Zaretskii <eliz@gnu.org>,
> 	Stefan Kangas
>  <stefankangas@gmail.com>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >>>>> In <87bl0q8vfa.fsf@yahoo.com> 
> >>>>>	Po Lu <luangruo@yahoo.com> wrote:
> 
> > Most people were certainly happy for at least the past decade.
> 
> I think saving custom set variables to init file somehow prevents
> using byte compiled init.el file effectively (unless the user hooks
> auto compile whenever it is changed by emacs). From that perspective,
> I'm happy to see that this behavior is to be changed.

Byte compiling init.el is not a very good idea; natively-compiling
them is an even worse idea.

So I'm not sure we should make that easier, because it makes easier
for people to make mistakes like that.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

> I don't understand what's so bad about the third line that warrants
> loading the custom file by default.

If there's something bad, I missed it. It's been in my init.el for ages ;-)
However, providing for emacs to do it might help people separate init.el
from custom.el which I think is good
And making sure it is loaded by default after init.el may help debugging,
right? I mean, you know when the customisations
were loaded, and that may be more than what we have today, right?

> So I'm not sure we should make that easier, because it makes easier
> for people to make mistakes like that.

I don't think this helps people byte-compiling anything ;-)

On Wed, 5 Jan 2022 at 14:06, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 05 Jan 2022 17:17:12 +0800
> > From: LdBeth <andpuke@foxmail.com>
> > Cc: Drew Adams <drew.adams@oracle.com>,
> >       Pedro Andres Aranda Gutierrez <paaguti@gmail.com>,
> >       Robert Pluim
> >  <rpluim@gmail.com>,
> >       Eli Zaretskii <eliz@gnu.org>,
> >       Stefan Kangas
> >  <stefankangas@gmail.com>,
> >       "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> >
> > >>>>> In <87bl0q8vfa.fsf@yahoo.com>
> > >>>>> Po Lu <luangruo@yahoo.com> wrote:
> >
> > > Most people were certainly happy for at least the past decade.
> >
> > I think saving custom set variables to init file somehow prevents
> > using byte compiled init.el file effectively (unless the user hooks
> > auto compile whenever it is changed by emacs). From that perspective,
> > I'm happy to see that this behavior is to be changed.
>
> Byte compiling init.el is not a very good idea; natively-compiling
> them is an even worse idea.
>
> So I'm not sure we should make that easier, because it makes easier
> for people to make mistakes like that.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 3312 bytes --]

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

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> If there's something bad, I missed it. It's been in my init.el for
> ages ;-) However, providing for emacs to do it might help people
> separate init.el from custom.el which I think is good

Isn't it already separate if you want to?  IOW, can't you already change
the custom file?

> And making sure it is loaded by default after init.el may help
> debugging, right? I mean, you know when the customisations were
> loaded, and that may be more than what we have today, right?

I don't think it would be easier for debugging.

Thanks.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

> This is a bit long, but I think it's relatively succinct.

Thanks for putting everything together :-) looks like a 'letter to Santa'
or to the three Wise Men, which would be just in time in places like Spain
;-)

> 1. Whether to load `custom-file' automatically after the init file is an
open question.
Agree, but it would be a nice place, right? You have setup all the code you
use in your emacs, you are sure that all variables have been defined and
then you initialize them with the values you want/have customized

> 2. That should never be done if it's already been loaded...
100%, see my patch as a simple way of accomplishing that

> 3. ...(Obviously this can only be the case when it's not the same file as
the init file.)
Hmm, right, I was missing that part :-)

> #3 is a no-op if the `custom-file' is empty...
Right, I was assuming that, but it's better if we write this out

> 4. ... Why?  Just as you might want to explicitly control where/when, and
how many times,...
That sounds fair

> 5. `emacs -q' and `emacs -Q' should not load the `custom-file'.
So we put in in the same (progn) that loads the init file

> In addition, we should add a new switch that suppresses (only) loading of
the `custom-file'
Don't get that one

> 6. `custom-file' should have a default value/location.
Jup

> We could, however, keep the longstanding nil-means-use-init-file
behavior, so that if you _explicitly_ set `custom-file' to nil it's the
same as setting it to the value of `user-init-file'.

I'd favour that

> 7. Suppose a longtime user doesn't read the NEWS etc., and _does
nothing_.  What happens then?  Is there a problem?
> 8. #7 is the case some people have howled about.  Is it really a
problem?  It could be, in this scenario:

Good analysis...

Thx, /PA

On Thu, 6 Jan 2022 at 01:37, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > If there's something bad, I missed it. It's been in my init.el for
> > ages ;-) However, providing for emacs to do it might help people
> > separate init.el from custom.el which I think is good
>
> Isn't it already separate if you want to?  IOW, can't you already change
> the custom file?
>
> > And making sure it is loaded by default after init.el may help
> > debugging, right? I mean, you know when the customisations were
> > loaded, and that may be more than what we have today, right?
>
> I don't think it would be easier for debugging.
>
> Thanks.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 3688 bytes --]

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

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

>> 7. Suppose a longtime user doesn't read the NEWS etc., and _does
>> nothing_.  What happens then?  Is there a problem?

How about ignoring all of that, and asking the user where to save his
customizations when he tries to save them for the first time?

That seems like the best solution to me.

Thanks.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

> How about ignoring all of that, and asking the user where to save his
> customizations when he tries to save them for the first time?

Define "first time", please :-)

 First time s/he is using an emacs with the new 'custom-file' handling?
Then, where do you record this to define the behavior for a 'second time'?

Best, /PA

On Thu, 6 Jan 2022 at 08:24, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> >> 7. Suppose a longtime user doesn't read the NEWS etc., and _does
> >> nothing_.  What happens then?  Is there a problem?
>
> How about ignoring all of that, and asking the user where to save his
> customizations when he tries to save them for the first time?
>
> That seems like the best solution to me.
>
> Thanks.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1597 bytes --]

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

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Define "first time", please :-)

If he has no custom file set and no custom-set-variables form in
his init file.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Robert Pluim <rpluim@gmail.com>,
>  emacs-devel <emacs-devel@gnu.org>,  Stefan Kangas
>  <stefankangas@gmail.com>,  Drew Adams <drew.adams@oracle.com>
> Date: Thu, 06 Jan 2022 15:23:56 +0800
> 
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> 
> >> 7. Suppose a longtime user doesn't read the NEWS etc., and _does
> >> nothing_.  What happens then?  Is there a problem?
> 
> How about ignoring all of that, and asking the user where to save his
> customizations when he tries to save them for the first time?

How do you define "the first time", exactly?

Users can use several different systems and/or user accounts.  Some of
them start a session and keep it running for long times, others start
very short sessions for specific jobs, then exit Emacs.  A user could
start Emacs for the first time in his/her life, or he/she could be a
veteran Emacs users with many customizations.  The definition of the
"first time" should reasonably support all of these use patterns, and
possibly others as well.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> How about ignoring all of that, and asking the user where to save his
>> customizations when he tries to save them for the first time?

> How do you define "the first time", exactly?

> Users can use several different systems and/or user accounts.  Some of
> them start a session and keep it running for long times, others start
> very short sessions for specific jobs, then exit Emacs.  A user could
> start Emacs for the first time in his/her life, or he/she could be a
> veteran Emacs users with many customizations.  The definition of the
> "first time" should reasonably support all of these use patterns, and
> possibly others as well.

I think it can be reasonably assumed to be the "first time" if there is
no custom file already set, and no custom-set-variables form in the init
file.

WDYT?  Thanks.

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

[Robert Pluim]

>>>>> On Thu, 06 Jan 2022 17:40:05 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> Eli Zaretskii <eliz@gnu.org> writes:
    >>> How about ignoring all of that, and asking the user where to save his
    >>> customizations when he tries to save them for the first time?

    >> How do you define "the first time", exactly?

    >> Users can use several different systems and/or user accounts.  Some of
    >> them start a session and keep it running for long times, others start
    >> very short sessions for specific jobs, then exit Emacs.  A user could
    >> start Emacs for the first time in his/her life, or he/she could be a
    >> veteran Emacs users with many customizations.  The definition of the
    >> "first time" should reasonably support all of these use patterns, and
    >> possibly others as well.

    Po> I think it can be reasonably assumed to be the "first time" if there is
    Po> no custom file already set, and no custom-set-variables form in the init
    Po> file.

And custom-set-faces. If we do it that way, I (and other old grouches
like me) can ignore this issue until I decide to do something about
it.

Robert
-- 

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

[Colin Baxter 😺]

>>>>> Robert Pluim <rpluim@gmail.com> writes:

>>>>> On Thu, 06 Jan 2022 17:40:05 +0800, Po Lu <luangruo@yahoo.com> said:
    Po> Eli Zaretskii <eliz@gnu.org> writes:
    >>>> How about ignoring all of that, and asking the user where to
    >>>> save his customizations when he tries to save them for the
    >>>> first time?

    >>> How do you define "the first time", exactly?

    >>> Users can use several different systems and/or user accounts.
    >>> Some of them start a session and keep it running for long times,
    >>> others start very short sessions for specific jobs, then exit
    >>> Emacs.  A user could start Emacs for the first time in his/her
    >>> life, or he/she could be a veteran Emacs users with many
    >>> customizations.  The definition of the "first time" should
    >>> reasonably support all of these use patterns, and possibly
    >>> others as well.

    Po> I think it can be reasonably assumed to be the "first time" if
    Po> there is no custom file already set, and no custom-set-variables
    Po> form in the init file.

    > And custom-set-faces. 

Me too +1. I neither use c-s-f nor c-s-v.

    > If we do it that way, I (and other old 
    > grouches like me) can ignore this issue until I decide to do
    > something about it.

That will be never for me :-)

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

[Drew Adams]

> Po> I think it can be reasonably assumed to be the "first time" if
> Po> there is no custom file already set, and no custom-set-variables
> Po> form in the init file.
> 
> > And custom-set-faces.
> 
> Me too +1. I neither use c-s-f nor c-s-v.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > If we do it that way, I (and other old
> > grouches like me) can ignore this issue until
> > I decide to do something about it.
> 
> That will be never for me :-)

Huh?

If you don't have `custom-set-variables' or
`custom-set-faces' in your init file then the
proposed change to default `custom-file' (to
something like ~/.emacs-custom.el) should have
no effect on you.  You're presumably not using
Customize anyway.

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

[Drew Adams]

> > How about ignoring all of that, and asking the user where to save his
> > customizations when he tries to save them for the first time?
> 
> How do you define "the first time", exactly?
> 
> Users can use several different systems and/or user accounts.  Some of
> them start a session and keep it running for long times, others start
> very short sessions for specific jobs, then exit Emacs.  A user could
> start Emacs for the first time in his/her life, or he/she could be a
> veteran Emacs users with many customizations.  The definition of the
> "first time" should reasonably support all of these use patterns, and
> possibly others as well.

Exactly.
___

And _why_ should the first-time-save (however
you might define it) be the criterion?

And what if there's a `custom-set-variables',
`customize-set-variable', `customize-set-value',
`custom-save-variables', customize-save-variable,
`customize-save-all', `custom-save-all',
`custom-save-faces', `customize-save-customized', 
or `customize-saved' in the init file?

What if such is not in the init file but in
some file that's loaded by the init file?

What if such files get loaded conditionally?
Are you going to analyze the code and then
search through all the possible source code
for occurrences?  What if some such code is
generated?

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:

>
> And what if there's a `custom-set-variables',
> `customize-set-variable', `customize-set-value',
> `custom-save-variables', customize-save-variable,
> `customize-save-all', `custom-save-all',
> `custom-save-faces', `customize-save-customized', 
> or `customize-saved' in the init file?
>
> What if such is not in the init file but in
> some file that's loaded by the init file?
>
> What if such files get loaded conditionally?
> Are you going to analyze the code and then
> search through all the possible source code
> for occurrences?  What if some such code is
> generated?

I think this is one of the more important and easily overlooked issue
raised in this thread. I've noticed in recent times a growing use of
the various customise functions in a programatic manner within user
initialisation code. Such code is often spread across multiple files
which are loaded by the user's init file at startup.

For this issue, I do have to put myself in the very conservative camp.
I'm not convinced we have a real issue here and may be either
creating problems that are more theoretical than actual or guilty of
premature optimisations.

For new users, I don't think there are any real issues with the existing
situation. Most of the issues raised seem to be more issues that arise
once the user has become more experienced and wants to delve deeper into
their Emacs configuration. By that point, they will typically have the
skills to use the existing facilities to break off the custom data into
its own file and load it at whatever point is appropriate for their
style of configuration. 

I fear that if we try to make the Emacs startup process 'smarter', we
are likely to actually make it more frustrating for those who like to
have fine grained control and unnoticeable by those who don't care. In
the end, all we get is more complexity wiht little improved
functionality.  

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

[Drew Adams]

> > And what if there's a `custom-set-variables',
> > `customize-set-variable', `customize-set-value',
> > `custom-save-variables', customize-save-variable,
> > `customize-save-all', `custom-save-all',
> > `custom-save-faces', `customize-save-customized',
> > or `customize-saved' in the init file?
> >
> > What if such is not in the init file but in
> > some file that's loaded by the init file?
> >
> > What if such files get loaded conditionally?
> > Are you going to analyze the code and then
> > search through all the possible source code
> > for occurrences?  What if some such code is
> > generated?
> 
> I think this is one of the more important and easily overlooked issue
> raised in this thread. I've noticed in recent times a growing use of
> the various customise functions in a programatic manner within user
> initialisation code. Such code is often spread across multiple files
> which are loaded by the user's init file at startup.
> 
> For this issue, I do have to put myself in the very conservative camp.
> I'm not convinced we have a real issue here and may be either
> creating problems that are more theoretical than actual or guilty of
> premature optimisations.
> 
> For new users, I don't think there are any real issues with the existing
> situation. Most of the issues raised seem to be more issues that arise
> once the user has become more experienced and wants to delve deeper into
> their Emacs configuration. By that point, they will typically have the
> skills to use the existing facilities to break off the custom data into
> its own file and load it at whatever point is appropriate for their
> style of configuration.
> 
> I fear that if we try to make the Emacs startup process 'smarter', we
> are likely to actually make it more frustrating for those who like to
> have fine grained control and unnoticeable by those who don't care. In
> the end, all we get is more complexity wiht little improved
> functionality.

Thanks for your input, Tim.

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

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?

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

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.

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?

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?
                 ^^^^^^^^^^^^^^^^^^^^^^^^

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?

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.

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

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

4. Given that goal, how do we get there?
___

On the road from 1 to 4, how far do you get?

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.

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.

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

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

[Drew Adams]

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

Thanks for the clarification.  I too disagree
with, or am wary of, those proposals with an
emphasis on not impacting existing users.

I think the impact on them of what I proposed
is quite minimal: just set `custom-file' to
init file (or even perhaps just to nil, after
its default change to some standard file name.

But I didn't focus on minimizing impact on
existing users.  A main aim is to help new
users.
 
> 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.

Thanks for clarifying that too.  Dunno whether
or how much the problem has actually manifested.

But I think the downside is minimal.  Only those
users who _really_ need to use their init file
for Customize are inconvenienced, and only by
a one-time setting of `custom-file' to the init
file (or to nil).

And the upside is big: everyone else (including,
but not limited to novices) gets clean separation,
which we apparently agree is beneficial in itself.

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

What's the "work"?  (1) setting up the default,
and (2) a tiny number of users needing to set
`custom-file' to their init file.  (Or perhaps
a larger but still small number of users who for
some reason (what?) prefer that Customize use
their init file.)

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

They need to realize the advantage, to take it.
And, so far at least, Emacs isn't even telling
them about it - not even recommending it.  And
if Emacs were to recommend it then the obvious
question would be that if it's recommended, why
isn't that the default behavior?

> I'm sure some will argue that it isn't easy 
> to change for novices,

It's easy enough - it's just as easy for everyone
to set `custom-file' to a file name as it is for
a tiny number of people to set it to their init
file name. ;-)

It's not that it's difficult for anyone to set
up a `custom-file'.  It's that the awareness of
it isn't there.

> 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

If they never edit their init file then there's
no problem - then it's essentially a file only
for Customize.  But many (most?) users, even
novices, copy stuff from here and there and
stick it in their init files.  And it goes on
from there.

The virgin state you refer to isn't problematic,
right, but few remain virgin long. ;-)

> and those that do will likely find the standard
> solution pretty quickly.

What's the standard solution?

I suspect that relatively few Emacs users use
`custom-file', and even relatively few are aware
of it.  Based on what do I say that?  Not a lot,
but Q & A here & there.

Again, it would be better if Emacs at least
recommended using `custom-file' - in the manual,
and maybe even in a tutorial that does some minor
customizing (a face or a common option).

If most Emacs users were aware of it, and had an
idea of why they might want to use a separate
file, then I'd maybe agree that "those who do
will likely find the standard solution pretty
quickly", assuming using `custom-file' is the
standard solution you had in mind.

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

Mea culpa.  I suggested a number of things, yes.
But I also ranked them in priority, and I made
clear that what really matters (to me) is that
we get more/most users to use a separate file
for Customize.  How that happens, and anything
else related that might happen - to me that's
secondary.

Wrt -q and -Q turning off loading of `custom-file':
No, not at all.

What I suggested was having them turn off the
(proposed) _automatic_ loading of it after the
init file.

If the init file isn't loaded (-q and Q), I
think it makes sense not to load `custom-file'
(which by the proposal would be at a default
location, and which might well contain some
customizations).

This was a detail.  I perhaps shouldn't have
covered such details till we get past the main
aim and proposal.)

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

I haven't see that proposal.  How is that even
possible?

> discussions regarding adding additional command
> line switches

That was me - the detail I tried to clarify above.

> and various other suggestions relating
> to contgrol of when the custom-file is loaded (or not).

OK.

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

No, I don't have a problem with that word here.
I really meant to pose the question.  Maybe it
is a solution looking for a problem.  I don't
think so, but maybe it is.

I addressed this above: we may not have evidence
of it having been manifested; I grant you that.

But I've seen plenty of questions about this or
that happening because of things people do to
their init files.

> Perhaps contrived
> problem would be a better description. In 25 years of using Emacs, I
> have never seen Emacs customize messing with user code.

Nor have I.  It's users messing with generated
code that I think can be problematic.  And
maybe that's just hypothetical; dunno.

As I said, it doesn't make sense to mix the
two - nothing is gained by that design (as the
default at least, and probably in general).

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

OK.  They can certainly learn some things that
way.  Whether that's the normal, or a necessary,
way to learn, I doubt.  That sounds like trying
to make a virtue out of necessity (status quo).

> There is a very clear warning

Hm.  An obvious question is that if we need to
warn about that then why is it in the init file?

> and if they choose to disregard it, that is their choice.

Or accident.  People who go through red lights
don't always choose to do so.

> If we are going to go down the protect users
> from themselves road, 

There's no reason to exaggerate.  There's no
baked-in choice of going down some road, just
because we might do some little thing to avoid
dumb mistakes.  We ask you to confirm deletion
of files flagged for deletion in Dired?  That
doesn't imply any obligation to convert Emacs
to a "nanny-state" editor.

> then we should remove the init file completely
> and only allow them to configure
> the system using customize.

That doesn't follow.

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

We seemingly have greatly different views of
the change and complexity required.

Even if our little warning were to tell users
about `custom-file' and recommend using it, that
in itself would be an improvement.  Is that a
big change or complex?  And yet it hasn't been
done.

This is not the first time I've suggested this
kind of thing (but it's the first time I've
said so much about it).  And I don't think I'm
the only one who's brought it up before.

[And XEmacs apparently did it, without the world
coming to an end.  (XEmacs itself came to an end,
but not because it defaulted to using a custom
file.)]

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

Now I have a doubt that you read what I proposed.
I've said several times that you'd lose zero such
control.  Users should and would have 100% control
over whether to use a `custom-file', where it is,
when and where and whether to load it, and so on.

> In a nutshell, the potential negatives seem to outweigh the benefits.

I hear you.  But I think, especially given what
you just wrote, that you might have a mistaken
notion of the negatives.

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

That I understand.  I expected someone would
say that at some point, and I have no rebuttal.

On the other hand, I don't see the downside.
To me this is a no-lose no-brainer for Emacs
users - all of them.

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

First time that's been pointed out.  And that
too I expected someone would say at some point.
And there too I have no rebuttal.  Except to
say that customization settings are in a world
of their own - Customize is particular.

But yes, there's an argument to be made that a
hand-coded `setq' of option `foobar' being in
the same file as a `custom-set-variables' that
includes `foobar' might make some sense.

On the other hand, ask yourself what happens
if there's a hand-coded `custom-set-variables'
along with a Customize-inserted one.

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

Maybe, maybe not.  Interaction of user code
with Customize code can be...interesting.
Face changes, for instance.

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

Yes; agreed.  Provided your init file isn't
a monster.  In my case, my init file loads
a boatload of other code files.  And my
`custom-file' is pretty small.

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

I don't think it's irrelevant at all.  I think
it's worth thinking about.  But I agree that
whether to change also involves the question
of the cost vs benefit of the change.

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

OK.

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

So much for VS Code's brilliance. ;-)

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

Please, let's not throw in the kitchen sink.
There's no committal to any road.  There's
no marriage or contract.

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

> > On the road from 1 to 4, how far do you get?
> 
> I guess zero :-)

Right.  I should have said from 0 to 4.

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

There's no such hard-and-fast assumption
underpinning anything I wrote.  In fact, I
_don't_ think dealing with Elisp code is hard
for new users.

I think separating hand-coded code from generated
code makes sense, by default, for old as well as
new users.  I use a separate `custom-file' myself.

> > 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 expectation is that it won't happen.  Eli's
said about as much already.  I've suggested it
before, to no avail - but not recently.

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

I've said it several times now, and I'll say it
again: _absolutely_.  Nothing changes in that
regard.  (I myself use a separate `custom-file',
and I load it twice in my init file.)

Thank you for taking the time to express your
point of view clearly and in detail.

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:

>
> Thank you for taking the time to express your
> point of view clearly and in detail.

Thank you for considering my points (I'm now feeling a bit like one of
WB chipmunks!).

From your response, there are a couple of additional points I'd like to
make to clarify some things.

The reason I don't think just setting the custom file to some value
really covers the full scope of the change is because in addition to
that change, it will also be necessary to add code to make emacs load
that file. This means either the timing of loading that file would then
be up to Emacs or we would have to add some other switch to disable
automatic loading to restore user control over loading that file. So
already the 'simple' change proposal has added additional complexity
(albeit small). There could be other corner cases I've not thought of as
well, especially once we add a new 'toggle' for the loading behaviour.

The change management aspects I referred to are perhaps a little subtle
and are certainly hard to quantify. However, it is often way too easy to
underestimate the impact of such change and identify what needs to be
done to mitigate it. This impact can be especially hard to recognise
when you are invested in the change. Things which need to be considered
(some of which have been mentioned) include

- dealing with impact on existing users
- updating documentation, including manuals, howtos, faqs etc
- managing the confusion that will arise due to the amount of existing
  and easily found information out there (stack overflow, reddit, wikki,
  blogs, books etc) which will be out of date and will likely cause more
  confusion. 

Just dealing with the first one will likely result in the final solution
being more complex than simply setting a default custom file value,
which in turn will make the other points more substantial to deal with.

The above are some of the reasons I think it may be misleading to
characterise the proposal as something simple. However, I would be in
support if I thought this was an actual problem needing to be addressed.
TO me, it really does feel more like a solution in search of a problem
or at the very least, a change which will result in non-trivial effort
(at various levels) when there is little evidence it is really required. 

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

[Drew Adams]

> From your response, there are a couple of additional
> points I'd like to make to clarify some things.
> 
> The reason I don't think just setting the custom file
> to some value really covers the full scope of the
> change is because in addition to that change, it will
> also be necessary to add code to make emacs load that file.

I assume you mean load that file _automatically_,
since users can (and do) already load it in their
init files.

Automatically loading `custom-file', if it isn't
loaded by the init file (and any code that file
loads etc.), is not a hard requirement.

It's something that could easily be done, but it's
not _required_ to advance the aim of getting more
users aware of and using `custom-file'.

> This means either the timing of loading that file would then
> be up to Emacs or we would have to add some other switch to disable
> automatic loading to restore user control over loading that file.

Yes.  But I think that can be as simple as what
I suggested:

1. Automatically load `custom-file' (provided it's
   not the same as the init file) immediately after
   the init file is loaded.

   (We already automatically load other files if
   they exist - site-lisp.el etc.)

2. Provide users with a way to inhibit automatic
   loading if they need/want to do that.

(Those users who want to do everything in their
init file are not involved in this - they'd
just set `custom-file' to their init file.)

> So already the 'simple' change proposal has added additional complexity
> (albeit small). 

As I say, automatic loading isn't a requirement.
It's a feature.  And with #2 it's optional.

(One way to realize #2 would be with a user
option.  We could discuss its default value.)

> There could be other corner cases I've not thought of as
> well, especially once we add a new 'toggle' for the loading behaviour.

If we're really worried about that, then we
just don't provide any such automatic loading.

I don't expect problems, but automatic loading
isn't a requirement.  Nothing in the general
aim and proposed solutions requires it.

Without it, users would just be responsible for
loading `custom-file' - like now.  Not a big
deal, but I think it might help users to provide
it (new users especially).

> The change management aspects I referred to are perhaps a little subtle
> and are certainly hard to quantify. However, it is often way too easy to
> underestimate the impact of such change and identify what needs to be
> done to mitigate it. This impact can be especially hard to recognise
> when you are invested in the change.

I don't disagree with that general point.

I don't foresee any complications, but I'm
_not_ really invested in Emacs providing the
ability to automatically load `custom-file'.

> Things which need to be considered
> (some of which have been mentioned) include
> 
> - dealing with impact on existing users
> - updating documentation, including manuals, howtos, faqs etc
> - managing the confusion that will arise due to the amount of existing
>   and easily found information out there (stack overflow, reddit, wikki,
>   blogs, books etc) which will be out of date and will likely cause more
>   confusion.

Sure.

> Just dealing with the first one will likely result in the final solution
> being more complex than simply setting a default custom file value,
> which in turn will make the other points more substantial to deal with.

I don't think so, but I can't prove you're wrong.

Suppose we don't offer automatic loading.
If you don't load `custom-file' (from your
init file or in some other way) then it doesn't
get loaded.  End of story.

Or suppose we offer it, but by way of a user
option that by default is off (no autoload).

IOW, no change from what we do now, in this
respect (no autoloading of `custom-file').

In that case, the change is just to default
`custom-file' to a standard location, not to
nil.  Now reread your paragraph of things that
need to be considered.  Not a big deal in this
case, right?

I wouldn't be completely happy with that
solution, but it would still be an improvement.

As I said, it would even be a (small)
improvement if Emacs would just come out and
recommend to users to use `custom-file',
instead of just warning them, in the init-file
template-comment, not to edit the inserted
generated code.

I'd hope that we go further than that, but
even that would help.

> The above are some of the reasons I think it may be misleading to
> characterise the proposal as something simple. 

"The proposal" is really a set/hierarchy of
proposals, from trivially simple, with little
effect (and I hope little controversy), to
something that includes possibly automatically
loading `custom-file'.

I hope you'll agree that the mere change to
defaulting `custom-file' to a file name isn't
complicated in its implications, and it should
not be controversial.

All of what would happen in that case already
happens, if a user sets `custom-file' to a
file name.  If no one loads that file, or if
that file remains nonexistent or empty, we're
in no-op land.

Even users who only want to use their init
file for customizations wouldn't be impacted.
No-op.

> However, I would be in support if I thought
> this was an actual problem needing to be addressed.

Maybe think of it as what we have now: offering
`custom-file', but just making use of it a bit
more visible and likely.  Instead of thinking
"problem" and "solution", maybe just think that
it might help more users to take advantage of
`custom-file'.

> TO me, it really does feel more like a solution in search of a problem
> or at the very least, a change which will result in non-trivial effort
> (at various levels) when there is little evidence it is really required.

I understand that you feel that.  I think your
fears are unnecessary.  Take out the "automatic
loading" feature from your consideration, and
see how fearful you still are.

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:

>> From your response, there are a couple of additional
>> points I'd like to make to clarify some things.
>> 
>> The reason I don't think just setting the custom file
>> to some value really covers the full scope of the
>> change is because in addition to that change, it will
>> also be necessary to add code to make emacs load that file.
>
> I assume you mean load that file _automatically_,
> since users can (and do) already load it in their
> init files.
>
> Automatically loading `custom-file', if it isn't
> loaded by the init file (and any code that file
> loads etc.), is not a hard requirement.
>
> It's something that could easily be done, but it's
> not _required_ to advance the aim of getting more
> users aware of and using `custom-file'.
>
>> This means either the timing of loading that file would then
>> be up to Emacs or we would have to add some other switch to disable
>> automatic loading to restore user control over loading that file.
>
> Yes.  But I think that can be as simple as what
> I suggested:
>
> 1. Automatically load `custom-file' (provided it's
>    not the same as the init file) immediately after
>    the init file is loaded.
>
>    (We already automatically load other files if
>    they exist - site-lisp.el etc.)
>
> 2. Provide users with a way to inhibit automatic
>    loading if they need/want to do that.
>
> (Those users who want to do everything in their
> init file are not involved in this - they'd
> just set `custom-file' to their init file.)
>
>> So already the 'simple' change proposal has added additional complexity
>> (albeit small). 
>
> As I say, automatic loading isn't a requirement.
> It's a feature.  And with #2 it's optional.
>
> (One way to realize #2 would be with a user
> option.  We could discuss its default value.)
>
>> There could be other corner cases I've not thought of as
>> well, especially once we add a new 'toggle' for the loading behaviour.
>
> If we're really worried about that, then we
> just don't provide any such automatic loading.
>
> I don't expect problems, but automatic loading
> isn't a requirement.  Nothing in the general
> aim and proposed solutions requires it.
>
> Without it, users would just be responsible for
> loading `custom-file' - like now.  Not a big
> deal, but I think it might help users to provide
> it (new users especially).
>
>> The change management aspects I referred to are perhaps a little subtle
>> and are certainly hard to quantify. However, it is often way too easy to
>> underestimate the impact of such change and identify what needs to be
>> done to mitigate it. This impact can be especially hard to recognise
>> when you are invested in the change.
>
> I don't disagree with that general point.
>
> I don't foresee any complications, but I'm
> _not_ really invested in Emacs providing the
> ability to automatically load `custom-file'.
>
>> Things which need to be considered
>> (some of which have been mentioned) include
>> 
>> - dealing with impact on existing users
>> - updating documentation, including manuals, howtos, faqs etc
>> - managing the confusion that will arise due to the amount of existing
>>   and easily found information out there (stack overflow, reddit, wikki,
>>   blogs, books etc) which will be out of date and will likely cause more
>>   confusion.
>
> Sure.
>
>> Just dealing with the first one will likely result in the final solution
>> being more complex than simply setting a default custom file value,
>> which in turn will make the other points more substantial to deal with.
>
> I don't think so, but I can't prove you're wrong.
>
> Suppose we don't offer automatic loading.
> If you don't load `custom-file' (from your
> init file or in some other way) then it doesn't
> get loaded.  End of story.
>
> Or suppose we offer it, but by way of a user
> option that by default is off (no autoload).
>
> IOW, no change from what we do now, in this
> respect (no autoloading of `custom-file').
>
> In that case, the change is just to default
> `custom-file' to a standard location, not to
> nil.  Now reread your paragraph of things that
> need to be considered.  Not a big deal in this
> case, right?
>
> I wouldn't be completely happy with that
> solution, but it would still be an improvement.
>
> As I said, it would even be a (small)
> improvement if Emacs would just come out and
> recommend to users to use `custom-file',
> instead of just warning them, in the init-file
> template-comment, not to edit the inserted
> generated code.
>
> I'd hope that we go further than that, but
> even that would help.
>
>> The above are some of the reasons I think it may be misleading to
>> characterise the proposal as something simple. 
>
> "The proposal" is really a set/hierarchy of
> proposals, from trivially simple, with little
> effect (and I hope little controversy), to
> something that includes possibly automatically
> loading `custom-file'.
>
> I hope you'll agree that the mere change to
> defaulting `custom-file' to a file name isn't
> complicated in its implications, and it should
> not be controversial.
>
> All of what would happen in that case already
> happens, if a user sets `custom-file' to a
> file name.  If no one loads that file, or if
> that file remains nonexistent or empty, we're
> in no-op land.
>
> Even users who only want to use their init
> file for customizations wouldn't be impacted.
> No-op.
>
>> However, I would be in support if I thought
>> this was an actual problem needing to be addressed.
>
> Maybe think of it as what we have now: offering
> `custom-file', but just making use of it a bit
> more visible and likely.  Instead of thinking
> "problem" and "solution", maybe just think that
> it might help more users to take advantage of
> `custom-file'.
>
>> TO me, it really does feel more like a solution in search of a problem
>> or at the very least, a change which will result in non-trivial effort
>> (at various levels) when there is little evidence it is really required.
>
> I understand that you feel that.  I think your
> fears are unnecessary.  Take out the "automatic
> loading" feature from your consideration, and
> see how fearful you still are.

Hi Drew,

we seem to be mis-communicating here or I'm just not being clear enough.
One last attempt and then I'll leave it alone.

My understanding of your suggestion is to set custom-file to some
default location rather than nil e.g. .emacs.d/custom.el. You suggest
that is all which is required and that no automatic loading would need
to be added. I reject this as automatic loading would be absolutely
necessary to retain existing behaviour.

If all we do is set custom-file to a default location, custom will stop
working between sessions because nothing will load those settings. This
significantly changes behaviour. To keep the same behaviour, either all
users who now just use custom with custom-file set to nil would need to
add a load statement OR emacs will have to automatically load that file.

Requiring users add a load statement to their initialisation file to
ensure custom settings work across sessions is a bad design and would
impact too many existing users.

If we change the default setting of custom-file from nil to a
default file location, there will need to be code added to Emacs to load
that file at some point in the initialisation step. If we then also want
to retain the user's ability to control when this file is loaded, we
will also require a toggle to turn off that loading and allow the user
to do it. 

Claiming that all you are proposing is a change to the default value for
custom-file is inaccurate if you also want to claim no change in
behaviour.  

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

[Drew Adams]

[Quoting most of this so it can be referred to
 in my reply.  Readers can skip over the long
 first quoted part, and come back to parts of
 it, if needed, when they're referred to.
 To do that, skip to "------------".]

> > Automatically loading `custom-file', if it isn't
> > loaded by the init file (and any code that file
> > loads etc.), is not a hard requirement.
> >
> > It's something that could easily be done, but it's
> > not _required_ to advance the aim of getting more
> > users aware of and using `custom-file'.
> >
> >> This means either the timing of loading that file would then
> >> be up to Emacs or we would have to add some other switch to disable
> >> automatic loading to restore user control over loading that file.
> >
> > Yes.  But I think that can be as simple as what
> > I suggested:
> >
> > 1. Automatically load `custom-file' (provided it's
> >    not the same as the init file) immediately after
> >    the init file is loaded.
> >
> >    (We already automatically load other files if
> >    they exist - site-lisp.el etc.)
> >
> > 2. Provide users with a way to inhibit automatic
> >    loading if they need/want to do that.
> >
> > (Those users who want to do everything in their
> > init file are not involved in this - they'd
> > just set `custom-file' to their init file.)
> >
> >> So already the 'simple' change proposal has added 
> >> additional complexity (albeit small).
> >
> > As I say, automatic loading isn't a requirement.
> > It's a feature.  And with #2 it's optional.
> >
> > (One way to realize #2 would be with a user
> > option.  We could discuss its default value.)
> >
> >> There could be other corner cases I've not thought of as
> >> well, especially once we add a new 'toggle' for the loading behaviour.
> >
> > If we're really worried about that, then we
> > just don't provide any such automatic loading.
> >
> > I don't expect problems, but automatic loading
> > isn't a requirement.  Nothing in the general
> > aim and proposed solutions requires it.
> >
> > Without it, users would just be responsible for
> > loading `custom-file' - like now.  Not a big
> > deal, but I think it might help users to provide
> > it (new users especially).
> >
> >> The change management aspects I referred to are perhaps a little subtle
> >> and are certainly hard to quantify. However, it is often way too easy to
> >> underestimate the impact of such change and identify what needs to be
> >> done to mitigate it. This impact can be especially hard to recognise
> >> when you are invested in the change.
> >
> > I don't disagree with that general point.
> >
> > I don't foresee any complications, but I'm
> > _not_ really invested in Emacs providing the
> > ability to automatically load `custom-file'.
> >
> >> Things which need to be considered
> >> (some of which have been mentioned) include
> >>
> >> - dealing with impact on existing users
> >> - updating documentation, including manuals, howtos, faqs etc
> >> - managing the confusion that will arise due to the amount of existing
> >>   and easily found information out there (stack overflow, reddit, wikki,
> >>   blogs, books etc) which will be out of date and will likely cause more
> >>   confusion.
> >
> > Sure.
> >
> >> Just dealing with the first one will likely result in the final solution
> >> being more complex than simply setting a default custom file value,
> >> which in turn will make the other points more substantial to deal with.
> >
> > I don't think so, but I can't prove you're wrong.
> >
> > Suppose we don't offer automatic loading.
> > If you don't load `custom-file' (from your
> > init file or in some other way) then it doesn't
> > get loaded.  End of story.
> >
> > Or suppose we offer it, but by way of a user
> > option that by default is off (no autoload).
> >
> > IOW, no change from what we do now, in this
> > respect (no autoloading of `custom-file').
> >
> > In that case, the change is just to default
> > `custom-file' to a standard location, not to
> > nil.  Now reread your paragraph of things that
> > need to be considered.  Not a big deal in this
> > case, right?
> >
> > I wouldn't be completely happy with that
> > solution, but it would still be an improvement.
> >
> > As I said, it would even be a (small)
> > improvement if Emacs would just come out and
> > recommend to users to use `custom-file',
> > instead of just warning them, in the init-file
> > template-comment, not to edit the inserted
> > generated code.
> >
> > I'd hope that we go further than that, but
> > even that would help.
> >
> >> The above are some of the reasons I think it may be misleading to
> >> characterise the proposal as something simple.
> >
> > "The proposal" is really a set/hierarchy of
> > proposals, from trivially simple, with little
> > effect (and I hope little controversy), to
> > something that includes possibly automatically
> > loading `custom-file'.
> >
> > I hope you'll agree that the mere change to
> > defaulting `custom-file' to a file name isn't
> > complicated in its implications, and it should
> > not be controversial.
> >
> > All of what would happen in that case already
> > happens, if a user sets `custom-file' to a
> > file name.  If no one loads that file, or if
> > that file remains nonexistent or empty, we're
> > in no-op land.
> >
> > Even users who only want to use their init
> > file for customizations wouldn't be impacted.
> > No-op.
> >
> >> However, I would be in support if I thought
> >> this was an actual problem needing to be addressed.
> >
> > Maybe think of it as what we have now: offering
> > `custom-file', but just making use of it a bit
> > more visible and likely.  Instead of thinking
> > "problem" and "solution", maybe just think that
> > it might help more users to take advantage of
> > `custom-file'.
> >
> >> TO me, it really does feel more like a solution in search of a problem
> >> or at the very least, a change which will result in non-trivial effort
> >> (at various levels) when there is little evidence it is really required.
> >
> > I understand that you feel that.  I think your
> > fears are unnecessary.  Take out the "automatic
> > loading" feature from your consideration, and
> > see how fearful you still are.

------------

> we seem to be mis-communicating here or I'm just not being clear enough.
> One last attempt and then I'll leave it alone.
> 
> My understanding of your suggestion is to set custom-file to some
> default location rather than nil e.g. .emacs.d/custom.el. You suggest
> that is all which is required and that no automatic loading would need
> to be added.

For some definition of "required".  See the rest of
what I wrote (which you quote above).

I certainly favor automatic loading, with an option
to prevent it (#1 and #2 above).

> I reject this as automatic loading would be absolutely
> necessary to retain existing behaviour.

Depends on what is meant by "absolutely necessary".
As I said:

  Without it, users would just be responsible for
  loading `custom-file' - like now.  Not a big
  deal, but I think it might help users to provide
  it (new users especially).

By "absolutely necessary" you appear to mean without
any users having to make any changes.

So yes, if _no user will make any changes_ then
something like automatic loading would be necessary.
Otherwise, saved customizations wouldn't get loaded.

(Is it necessary that they get loaded?  Certainly
desirable/expected.)

> If all we do is set custom-file to a default location, custom will stop
> working between sessions because nothing will load those settings. This
> significantly changes behaviour.

Indeed.  Hence the proposal to automatically
load `custom-file', if it hasn't been loaded
and it's not empty.

> To keep the same behaviour, either all
> users who now just use custom with custom-file set to nil would need to
> add a load statement OR emacs will have to automatically load that file.

Or they would need to start using `custom-file'
(which should be encouraged, without obligation
to do so).

Yes, that's it.

(Except that we could perhaps let an _explicit_
setting of `custom-file' to nil act like setting
it to the init file.)

> Requiring users add a load statement to their initialisation file to
> ensure custom settings work across sessions is a bad design and would
> impact too many existing users.

There would be no such requirement.

You prefaced your (incomplete) statement with
"To keep the same behaviour".  Clearly, if we
change default behavior then we're not keeping
the same behavior by default.

We would be _allowing_ the same behavior to be
realized.  And with very minimal effort.  And
no, users who really want to keep the same 
behavior would not need to add a load statement
anywhere.  It's enough to set `custom-file' to
the init file (or perhaps even to nil).

> If we change the default setting of custom-file from nil to a
> default file location, there will need to be code added to Emacs to load
> that file at some point in the initialisation step.

Yes.  (But load it only if it hasn't been loaded.)

> If we then also want
> to retain the user's ability to control when this file is loaded, we
> will also require a toggle to turn off that loading and allow the user
> to do it.

1. See previous - it would be loaded only if
not loaded during the load of the init file.

2. Users can load it anytime during the init
file load.  They can even load it multiple
times.

3. Users can prevent loading it automatically
(I suggested a user option or this, as well as
perhaps a command-line switch.) 

> Claiming that all you are proposing is a change to the default value for
> custom-file is inaccurate if you also want to claim no change in
> behaviour.

1. That's _not_ all I proposed.  That's all that's
strictly necessary.  But in that case, users have
a bit more responsibility.

2. I never claimed that there would be no change
in behavior.  Obviously, if we change the default
behavior we change the behavior.  What I claimed
is that (a) in many cases there will be no change
in behavior and (b) in any case users can easily
get whatever behavior they like, including the
behavior that's the default now.

To restore the behavior to what is now the default,
a user would set `custom-file' to the init file.

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:

> [Quoting most of this so it can be referred to
>  in my reply.  Readers can skip over the long
>  first quoted part, and come back to parts of
>  it, if needed, when they're referred to.
>  To do that, skip to "------------".]
>
>> > Automatically loading `custom-file', if it isn't
>> > loaded by the init file (and any code that file
>> > loads etc.), is not a hard requirement.
>> >
>> > It's something that could easily be done, but it's
>> > not _required_ to advance the aim of getting more
>> > users aware of and using `custom-file'.
>> >
>> >> This means either the timing of loading that file would then
>> >> be up to Emacs or we would have to add some other switch to disable
>> >> automatic loading to restore user control over loading that file.
>> >
>> > Yes.  But I think that can be as simple as what
>> > I suggested:
>> >
>> > 1. Automatically load `custom-file' (provided it's
>> >    not the same as the init file) immediately after
>> >    the init file is loaded.
>> >
>> >    (We already automatically load other files if
>> >    they exist - site-lisp.el etc.)
>> >
>> > 2. Provide users with a way to inhibit automatic
>> >    loading if they need/want to do that.
>> >
>> > (Those users who want to do everything in their
>> > init file are not involved in this - they'd
>> > just set `custom-file' to their init file.)
>> >
>> >> So already the 'simple' change proposal has added 
>> >> additional complexity (albeit small).
>> >
>> > As I say, automatic loading isn't a requirement.
>> > It's a feature.  And with #2 it's optional.
>> >
>> > (One way to realize #2 would be with a user
>> > option.  We could discuss its default value.)
>> >
>> >> There could be other corner cases I've not thought of as
>> >> well, especially once we add a new 'toggle' for the loading behaviour.
>> >
>> > If we're really worried about that, then we
>> > just don't provide any such automatic loading.
>> >
>> > I don't expect problems, but automatic loading
>> > isn't a requirement.  Nothing in the general
>> > aim and proposed solutions requires it.
>> >
>> > Without it, users would just be responsible for
>> > loading `custom-file' - like now.  Not a big
>> > deal, but I think it might help users to provide
>> > it (new users especially).
>> >
>> >> The change management aspects I referred to are perhaps a little subtle
>> >> and are certainly hard to quantify. However, it is often way too easy to
>> >> underestimate the impact of such change and identify what needs to be
>> >> done to mitigate it. This impact can be especially hard to recognise
>> >> when you are invested in the change.
>> >
>> > I don't disagree with that general point.
>> >
>> > I don't foresee any complications, but I'm
>> > _not_ really invested in Emacs providing the
>> > ability to automatically load `custom-file'.
>> >
>> >> Things which need to be considered
>> >> (some of which have been mentioned) include
>> >>
>> >> - dealing with impact on existing users
>> >> - updating documentation, including manuals, howtos, faqs etc
>> >> - managing the confusion that will arise due to the amount of existing
>> >>   and easily found information out there (stack overflow, reddit, wikki,
>> >>   blogs, books etc) which will be out of date and will likely cause more
>> >>   confusion.
>> >
>> > Sure.
>> >
>> >> Just dealing with the first one will likely result in the final solution
>> >> being more complex than simply setting a default custom file value,
>> >> which in turn will make the other points more substantial to deal with.
>> >
>> > I don't think so, but I can't prove you're wrong.
>> >
>> > Suppose we don't offer automatic loading.
>> > If you don't load `custom-file' (from your
>> > init file or in some other way) then it doesn't
>> > get loaded.  End of story.
>> >
>> > Or suppose we offer it, but by way of a user
>> > option that by default is off (no autoload).
>> >
>> > IOW, no change from what we do now, in this
>> > respect (no autoloading of `custom-file').
>> >
>> > In that case, the change is just to default
>> > `custom-file' to a standard location, not to
>> > nil.  Now reread your paragraph of things that
>> > need to be considered.  Not a big deal in this
>> > case, right?
>> >
>> > I wouldn't be completely happy with that
>> > solution, but it would still be an improvement.
>> >
>> > As I said, it would even be a (small)
>> > improvement if Emacs would just come out and
>> > recommend to users to use `custom-file',
>> > instead of just warning them, in the init-file
>> > template-comment, not to edit the inserted
>> > generated code.
>> >
>> > I'd hope that we go further than that, but
>> > even that would help.
>> >
>> >> The above are some of the reasons I think it may be misleading to
>> >> characterise the proposal as something simple.
>> >
>> > "The proposal" is really a set/hierarchy of
>> > proposals, from trivially simple, with little
>> > effect (and I hope little controversy), to
>> > something that includes possibly automatically
>> > loading `custom-file'.
>> >
>> > I hope you'll agree that the mere change to
>> > defaulting `custom-file' to a file name isn't
>> > complicated in its implications, and it should
>> > not be controversial.
>> >
>> > All of what would happen in that case already
>> > happens, if a user sets `custom-file' to a
>> > file name.  If no one loads that file, or if
>> > that file remains nonexistent or empty, we're
>> > in no-op land.
>> >
>> > Even users who only want to use their init
>> > file for customizations wouldn't be impacted.
>> > No-op.
>> >
>> >> However, I would be in support if I thought
>> >> this was an actual problem needing to be addressed.
>> >
>> > Maybe think of it as what we have now: offering
>> > `custom-file', but just making use of it a bit
>> > more visible and likely.  Instead of thinking
>> > "problem" and "solution", maybe just think that
>> > it might help more users to take advantage of
>> > `custom-file'.
>> >
>> >> TO me, it really does feel more like a solution in search of a problem
>> >> or at the very least, a change which will result in non-trivial effort
>> >> (at various levels) when there is little evidence it is really required.
>> >
>> > I understand that you feel that.  I think your
>> > fears are unnecessary.  Take out the "automatic
>> > loading" feature from your consideration, and
>> > see how fearful you still are.
>
> ------------
>
>> we seem to be mis-communicating here or I'm just not being clear enough.
>> One last attempt and then I'll leave it alone.
>> 
>> My understanding of your suggestion is to set custom-file to some
>> default location rather than nil e.g. .emacs.d/custom.el. You suggest
>> that is all which is required and that no automatic loading would need
>> to be added.
>
> For some definition of "required".  See the rest of
> what I wrote (which you quote above).
>
> I certainly favor automatic loading, with an option
> to prevent it (#1 and #2 above).
>
>> I reject this as automatic loading would be absolutely
>> necessary to retain existing behaviour.
>
> Depends on what is meant by "absolutely necessary".
> As I said:
>
>   Without it, users would just be responsible for
>   loading `custom-file' - like now.  Not a big
>   deal, but I think it might help users to provide
>   it (new users especially).
>
> By "absolutely necessary" you appear to mean without
> any users having to make any changes.
>
> So yes, if _no user will make any changes_ then
> something like automatic loading would be necessary.
> Otherwise, saved customizations wouldn't get loaded.
>
> (Is it necessary that they get loaded?  Certainly
> desirable/expected.)
>
>> If all we do is set custom-file to a default location, custom will stop
>> working between sessions because nothing will load those settings. This
>> significantly changes behaviour.
>
> Indeed.  Hence the proposal to automatically
> load `custom-file', if it hasn't been loaded
> and it's not empty.
>
>> To keep the same behaviour, either all
>> users who now just use custom with custom-file set to nil would need to
>> add a load statement OR emacs will have to automatically load that file.
>
> Or they would need to start using `custom-file'
> (which should be encouraged, without obligation
> to do so).
>
> Yes, that's it.
>
> (Except that we could perhaps let an _explicit_
> setting of `custom-file' to nil act like setting
> it to the init file.)
>
>> Requiring users add a load statement to their initialisation file to
>> ensure custom settings work across sessions is a bad design and would
>> impact too many existing users.
>
> There would be no such requirement.
>
> You prefaced your (incomplete) statement with
> "To keep the same behaviour".  Clearly, if we
> change default behavior then we're not keeping
> the same behavior by default.
>
> We would be _allowing_ the same behavior to be
> realized.  And with very minimal effort.  And
> no, users who really want to keep the same 
> behavior would not need to add a load statement
> anywhere.  It's enough to set `custom-file' to
> the init file (or perhaps even to nil).
>
>> If we change the default setting of custom-file from nil to a
>> default file location, there will need to be code added to Emacs to load
>> that file at some point in the initialisation step.
>
> Yes.  (But load it only if it hasn't been loaded.)
>
>> If we then also want
>> to retain the user's ability to control when this file is loaded, we
>> will also require a toggle to turn off that loading and allow the user
>> to do it.
>
> 1. See previous - it would be loaded only if
> not loaded during the load of the init file.
>
> 2. Users can load it anytime during the init
> file load.  They can even load it multiple
> times.
>
> 3. Users can prevent loading it automatically
> (I suggested a user option or this, as well as
> perhaps a command-line switch.) 
>
>> Claiming that all you are proposing is a change to the default value for
>> custom-file is inaccurate if you also want to claim no change in
>> behaviour.
>
> 1. That's _not_ all I proposed.  That's all that's
> strictly necessary.  But in that case, users have
> a bit more responsibility.
>
> 2. I never claimed that there would be no change
> in behavior.  Obviously, if we change the default
> behavior we change the behavior.  What I claimed
> is that (a) in many cases there will be no change
> in behavior and (b) in any case users can easily
> get whatever behavior they like, including the
> behavior that's the default now.
>
> To restore the behavior to what is now the default,
> a user would set `custom-file' to the init file.

Thanks for putting it all together in one place. It does help.

I believe I now have a better understanding of your multi-layered or
hierarchy of proposed change. I have now moved from being fairly
ambivalent about the proposal and sceptical regarding the necessity for
any change to being firmly against any change.

Ignoring the important question as to whether there is any real problem
which this change will address, I feel your proposal has the real
potential to complicate the semantics of how custom works and very
likely to add to user confusion.

- If we don't have autoloading of custom settings, new users will have
  to add a load statement or set their custom-file to their init file
  (or nil). This does not seem intuitive to me. If I use the
  customisation facilities of an application, I don't then expect to
  have to load those settings as well.

- If we do add autoloading, then we also need to add additional switches
  to allow user control of that autoloading. This is adding additional
  complexity, especially if we only want the autoloading to occur if the
  user has not explicitly done it (I don't believe detecting this will
  be as straight-forward or simple as some have suggested - not without
  having some corner cases or modifying custom).

All of this done based on the assumption that having auto generated code
in your init file is a bad enough idea we need to get rid of it. Yet
that assumption lacks any real evidence despite decades of this practice
being in place. 

You also suggest we need to encourage new users to use a separate custom
file. Why? While you feel it is bad practice to mix user and auto
generated configuration in the same file, I suspect a much larger number
of users don't even give it a thought and have never had any problems
with it. 

At the end of the day, this seems like a non-problem driven by a
belief/ideology that mixing user and auto-generated code is so wrong it
has to be eliminated. If there was evidence of significant adverse
impact to users due to this practice, change would be warranted.
However, as it now stands, I cannot see how such change can be
justified. 

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

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00794.html
> ...
> At the end of the day, this seems like a non-problem driven by a
> belief/ideology that mixing user and auto-generated code is so wrong it
> has to be eliminated. If there was evidence of significant adverse
> impact to users due to this practice, change would be warranted.
> However, as it now stands, I cannot see how such change can be
> justified.

All arguments against Drew's proposals so far converge at "it is better
to do nothing."  Why not propose something even better?  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.  Is existence of people
on Emacs related forums suggesting setting custom-file to /dev/null as a
good solution evidence enough?  How about split of early-init/creation
of straight.el?  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.  If only concern is the cost of change, why
not produce arguments for how to reduce that cost or to find a way
forward?

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> All arguments against Drew's proposals so far converge at "it is better
> to do nothing."  Why not propose something even better?

Any argument against Drew's proposal is by definition "it's better to do
nothing", so what else is there to propose?

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

[xenodasein--- via Emacs development discussions.]

Jan 11, 2022, 15:10 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> All arguments against Drew's proposals so far converge at "it is better
>> to do nothing."  Why not propose something even better?
>>
>
> Any argument against Drew's proposal is by definition "it's better to do
> nothing", so what else is there to propose?
>

If that is all you derived from their page long alternative proposals and
explanations, I think it is safe to say your intentions with these weird one
liner answers are impure.  You, my friend, are what is known on the Internet
as a debatelord.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Tue, Jan 11, 2022 at 01:25:16PM +0100, xenodasein--- via Emacs development discussions. wrote:

[...]

> If that is all you derived from their page long alternative proposals and
> explanations, I think it is safe to say your intentions with these weird one
> liner answers are impure.  You, my friend, are what is known on the Internet
> as a debatelord.

Now this is not only unwarranted, but also unnecessary. The debate is
already difficult as it is, so please, don't do that.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[xenodasein--- via Emacs development discussions.]

Jan 11, 2022, 17:40 by tomas@tuxteam.de:

> On Tue, Jan 11, 2022 at 03:23:50PM +0100, Mathias Megyei wrote:
>
>> On 1/11/22 1:42 PM, tomas@tuxteam.de wrote:
>>
>
> [...]
>
>> > Now this is not only unwarranted, but also unnecessary. The debate is
>> > already difficult as it is, so please, don't do that.
>> > 
>> > Cheers
>>
>> [I delibaretaly removed emacs-devel, I don't want to contribute to
>> non-technical discussion there. But I want to express my support for
>> xenodasein. No need to reply to this email.]
>>
>
> My mail wasn't about the position, but about the personal attack. This
> is unnecessary.
>
>> I have the same impression as xenodasein regarding the "helpfulness" of the
>> emails from Po Lu.
>>
>> Xenodasein, I hope and wish that you manage to overcome the destructive
>> effect of Po Lu's emails and remain active on emacs-devel. Maybe you could
>> just stop answering his emails and ask for the opinion of other developers
>> like Eli, Stefan M., Lars ...
>>
>
> This is just destructive behaviour. I don't know why you are doing this.
>
> Bye
> -- 
> tomás
>

It is not a refined response sure, but unnecessary and unwarranted?
I don't know.  I could just ignore but how is it better?  Ignoring
is simple enough, but it helps no one and there is no self-growth.
I see zero effort from the other party to correct these
misunderstandings, that is why my tone gets worse.  If this is too
disrupting and things won't change, I hereby stop responding to Po Lu
unless it is about something undeniable concrete a as patch, and I want
them to do the same.

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

[xenodasein--- via Emacs development discussions.]

Jan 11, 2022, 18:36 by tomas@tuxteam.de:
...
> The last sentence wasn't directed at you, rather at Mathias (who wrote
> off-list: I've snipped the list accordingly).
...

I wasn't paying attention to CC and I thought this was going on on the
list!  This is a mistake on my part, sorry for this.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Tue, Jan 11, 2022 at 05:05:51PM +0100, xenodasein@tutanota.de wrote:
> Jan 11, 2022, 18:36 by tomas@tuxteam.de:
> ...
> > The last sentence wasn't directed at you, rather at Mathias (who wrote
> > off-list: I've snipped the list accordingly).
> ...
> 
> I wasn't paying attention to CC and I thought this was going on on the
> list!  This is a mistake on my part, sorry for this.

No worries, at least from me.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Po Lu]

xenodasein@tutanota.de writes:

> If that is all you derived from their page long alternative proposals and
> explanations, I think it is safe to say your intentions with these weird one
> liner answers are impure.  You, my friend, are what is known on the Internet
> as a debatelord.

Drivel.

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

[Tim Cross]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00794.html
>> ...
>> At the end of the day, this seems like a non-problem driven by a
>> belief/ideology that mixing user and auto-generated code is so wrong it
>> has to be eliminated. If there was evidence of significant adverse
>> impact to users due to this practice, change would be warranted.
>> However, as it now stands, I cannot see how such change can be
>> justified.
>
> 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?

> 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.
>
> How about split of early-init/creation
> of straight.el? 

iWhat about it? How is it relevant to this proposed change?

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

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

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. 

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

[xenodasein--- via Emacs development discussions.]

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.

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

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

> 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 didn't intend to adress you directly if that is how it came out, but
this is a pattern I see a lot and wanted to express my opinion on it.
Thanks for giving a detailed response.

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

[Tim Cross]

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. 

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

[Jean Louis]

* xenodasein--- via "Emacs development discussions. <emacs-devel@gnu.org> [2022-01-11 15:08]:
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00794.html
> > ...
> > At the end of the day, this seems like a non-problem driven by a
> > belief/ideology that mixing user and auto-generated code is so wrong it
> > has to be eliminated. If there was evidence of significant adverse
> > impact to users due to this practice, change would be warranted.
> > However, as it now stands, I cannot see how such change can be
> > justified.
> 
> All arguments against Drew's proposals so far converge at "it is better
> to do nothing."  Why not propose something even better?  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.  Is existence of people
> on Emacs related forums suggesting setting custom-file to /dev/null as a
> good solution evidence enough?  How about split of early-init/creation
> of straight.el?  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.  If only concern is the cost of change, why
> not produce arguments for how to reduce that cost or to find a way
> forward?

A girl I know here uses frequently Emacs and she is 3 years. She likes
large letters and cannot read. For her is important to enlarge letters
and to type on keyboard. She does not know what letters and numbers
mean. I can tell she is new user of Emacs. 

It would be great for this new user to enable C-x-+ to and C-x-- to be
easier accessible (text-scale-adjust INC) and thus I propose to
include the text scale option into any setup wizards to come, in easy
way.

The way how I have see it in the setup-wizard.el is too complicated. I
rather expect something like using + and - to set the default font
size so that young people can easier get along.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Po Lu]

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

>  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?
>                  ^^^^^^^^^^^^^^^^^^^^^^^^
>
> No one has answered that.  Forget, for a
> second (and no, I'm not saying this isn't
> important), that there is habit & legacy.

There goes the _most_ important aspect of this: it's been around for a
long time, which is precisely why it's a great idea to stick with it.

I don't think it's a good idea on its own, but it's too established to
change now, no matter how good an idea the change is.

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

[Drew Adams]

> >  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?
> >
> > No one has answered that.  Forget, for a
> > second (and no, I'm not saying this isn't
> > important), that there is habit & legacy.
> 
> There goes the _most_ important aspect of this: it's been around for a
> long time, which is precisely why it's a great idea to stick with it.

What part of "no, I'm not saying this isn't
important", did you have trouble with?

> I don't think it's a good idea on its own, but it's too established to
> change now, no matter how good an idea the change is.

That's a pretty broad argument.  It argues
against pretty much all of the small & large
changes Emacs has undergone over the last
couple of decades.

It's a blanket argument against both good
& bad changes.  No addition of you-name-it.
(Think how long the lack of lexical binding
was "established".)

(And try arguing "longstanding behavior"
against some change coming from on high.
Been there.)

The number of things Emacs changes willy
nilly, which oblige users to change all
kinds of things in their code, setup, etc.,
is far greater than what I'd prefer.
We even live with some changes that are
unaccompanied by any stated reason, other
than a "Because _I_ like it".

This change would cause no such disruption.

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

[Po Lu]

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

>> There goes the _most_ important aspect of this: it's been around for a
>> long time, which is precisely why it's a great idea to stick with it.

> What part of "no, I'm not saying this isn't
> important", did you have trouble with?

You proceeded to dismiss the importance of that problem.

> That's a pretty broad argument.  It argues
> against pretty much all of the small & large
> changes Emacs has undergone over the last
> couple of decades.

[...]

> It's a blanket argument against both good
> & bad changes.  No addition of you-name-it.

This is not an addition of a new feature, which should be off by default
if it interferes with existing code (think lexical binding).  It is a
change to very long-standing behaviour that is also relied on by many
people.

> (Think how long the lack of lexical binding
> was "established".)

And lexical binding is still optional, so the use of dynamic binding by
default is as established as it used to be.

> (And try arguing "longstanding behavior"
> against some change coming from on high.
> Been there.)
> The number of things Emacs changes willy
> nilly, which oblige users to change all
> kinds of things in their code, setup, etc.,
> is far greater than what I'd prefer.
> We even live with some changes that are
> unaccompanied by any stated reason, other
> than a "Because _I_ like it".

I did not make those decisions, so I can't speak for them.  If mistakes
were made with those, however, it's not a reason to repeat them again.

> This change would cause no such disruption.

It might not for you, but would for a lot of people.

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

[Drew Adams]

> >> There goes the _most_ important aspect of this:
> >> it's been around for a long time, which is
> >> precisely why it's a great idea to stick with it.
> >
> > What part of "no, I'm not saying this isn't
> > important", did you have trouble with?
> 
> You proceeded to dismiss the importance of that problem.

No, not at all.

I asked that, "for a second", we abstract
from that problem to consider what behavior
we'd think was best without it.  I wanted to
know what we think is the better approach,
other things being equal - as a starting
point for discussion.

If it's not even considered generally better,
in the abstract, to separate hand-coding and
generated code, then there's no need to add
an a fortiori argument of "it's longstanding".

To make such a change, a minimal starting
point is agreeing that, other things being
equal, separate is better.  Disagreement on
that means no sense in going further.

And yes, "other things being equal" is an
expression which takes for granted that other
things need NOT be equal.  It doesn't at all
dismiss their importance.

> > > it's too established to change now, no
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > matter how good an idea the change is.
> >
> > That's a pretty broad argument.  It argues
> > against pretty much all of the small & large
> > changes Emacs has undergone over the last
> > couple of decades.  It's a blanket argument
> > against both good & bad changes.
> 
> This is not an addition of a new feature, which
> should be off by default if it interferes with
> existing code (think lexical binding).

Doesn't matter to your statement, which was
only that if something is longstanding then
it should be kept - a blanket argument for
keeping the status quo, what's "established".

The lack of lexical binding was longstanding.
That lack was removed (thank goodness).

> It is a change to very long-standing behaviour
> that is also relied on by many people.

The absence of a `custom-file' by default
is "relied on"?  How so?  What would giving
`custom-file' a default value deprive anyone
of?

No one has suggested that anyone _has_ to
use a separate custom file, just as now no
one says that everyone _must not_ use a
separate file.

> > (Think how long the lack of lexical
> > binding was "established".)
> 
> And lexical binding is still optional, 

But there's no longer any lack of it.  A
change was introduced, bucking your rule of
not changing whatever's long been the case.

> so the use of dynamic binding by default
> is as established as it used to be.

What was established was that there was
_only_ dynamic binding.  That's no longer
the case.

> > This change would cause no such disruption.
> 
> It might not for you, but would for a lot of people.

How so?  Are you talking about a minority
of users having to explicitly say that
they don't want a separate file - e.g.
simply setting `custom-file' to nil?

As opposed to the majority having to say
that they do want a separate file?

I'm assuming you agree it's generally
better, for more people than not, to
use a separate `custom-file'.

There are more future than past users,
and for a new user the "other thing"
of longstanding habit doesn't apply.
There may be still "other things" to
consider (what?), but that one is moot
for new users.

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

[Po Lu]

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

> Doesn't matter to your statement, which was only that if something is
> longstanding then it should be kept - a blanket argument for keeping
> the status quo, what's "established".

And it (dynamic binding) has been kept.

> The lack of lexical binding was longstanding.

The lack of lexical binding was a shortcoming.  A shortcoming is not
behaviour, nor is it a feature.  In contrast, defaulting to the init
file if no custom-file is set is behaviour, since it describes how the
program behaves under certain conditions.

In the specific case of lexical binding, the long-standing behaviour
that was preserved was to default to dynamic binding.

> The absence of a `custom-file' by default is "relied on"?  How so?

Emacs would start to behave differently for people who did not explictly
set custom-file if it gained a default value.

> But there's no longer any lack of it.  A change was introduced,
> bucking your rule of not changing whatever's long been the case.

[...]

> What was established was that there was _only_ dynamic binding.
> That's no longer the case.

Again, see what I said about the distinction between behaviour and
shortcomings.

> How so?  Are you talking about a minority of users having to
> explicitly say that they don't want a separate file - e.g.  simply
> setting `custom-file' to nil?

You may call them a "minority", but all people are important.  There is
no need to cause useless churn for people, just because some other
people have differing preferences.

> As opposed to the majority having to say that they do want a separate
> file?

The majority (if it indeed is a majority) have already done so.

> I'm assuming you agree it's generally better, for more people than
> not, to use a separate `custom-file'.

Yes, I agree.  If this discussion was started at the introduction of
`custom-file', then I would certainly have argued for it to have a
default value.

> There are more future than past users, and for a new user the "other
> thing" of longstanding habit doesn't apply.

How many future users there will be is for the future to say, not for
the present, where changing the default value will only serve to churn
the already muddy waters.

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

[Drew Adams]

> > The lack of lexical binding was longstanding.
> 
> The lack of lexical binding was a shortcoming.
> A shortcoming is not behaviour, nor is it a feature.

You don't like/get the example of lexical-binding.
OK.

Consider `transient-mark-mode'.
Its existence in Emacs was status quo for a
very long time, and the behavior was OFF.
Until it wasn't - the status quo was changed
to ON.  Holy Toledo!

That was a backward-incompatible change in
behavior.  It affected thousands of users.
It took us _decades_ to get that change made.
Status quo, status quo, status quo.

And why was that change finally made?  It's
what those who decided expected that more
users would expect & want.  Users out in
the wild expect to see text that they select
to act on ("activated") be highlighted, so
they can see what they'll act on.

What was the effect on users who did NOT
want `transient-mark-mode' on by default?

They turned it off.  End of story.  Some
muffled grumbles, nothing more.  Why?
Because you can still use Emacs as before -
just turn `t-m-mode' off (Customize).
Happy campers all around.

Why didn't we go all the way toward what most
new users out there really expected, which is
something more like `delete-selection-mode'
(which turns on `transient-mark-mode')?  Why
stop with `t-m-mode', which corresponds to
neither what users get outside Emacs nor what
Emacs behavior is with `t-m-mode' off?

We should have, IMO.  Not enough weight to
balance the rotund body of Status Quo.  I've
been betting on `delete-selection-mode' being
turned on by default after a few decades, but
it's already been a few decades now...  (I'm
still betting on that happening sometime.)

I'm as strong a proponent of not rocking the
status-quo boat as anyone.  And opinions can
certainly differ about whether `custom-file'
should default to a file name.  But what's
the downside of changing such a default
change?

A relatively few users - those who remain
wedded to using only their init file - would
need to set `custom-file' to their init file
(or to nil, if we interpret that as using
the init file after the default change).

A big deal?  I don't think so.  Just like
it ultimately wasn't a big deal to turn on
`transient-mark-mode' by default.

> > The absence of a `custom-file' by default is "relied on"?  How so?
> 
> Emacs would start to behave differently for people who did
> not explictly set custom-file if it gained a default value.

Yes, and?  Anyone can rely on the behavior
they've long relied on and enjoyed, by just
setting `custom-file' to their init file.
End of story.

> > How so?  Are you talking about a minority of users having to
> > explicitly say that they don't want a separate file - e.g.  simply
> > setting `custom-file' to nil?
> 
> You may call them a "minority", but all people are important.  There is
> no need to cause useless churn for people, just because some other
> people have differing preferences.

In the case of `transient-mark-mode' I'd wager
that the _vast_ majority - maybe 90% - of
existing Emacs users had `t-m-mode' off when
the default was switched to on.  And I'd wager
that a minority of them bothered to switch it
to off after the default changed.  And today
I'm guessing that relatively few Emacs users
set it to off.

It's not only about individual preferences,
and especially not only about _current_ ones.

It's also about what we expect will be best
for most users, and in particular most users
in the future.  Most Emacs users are future
users, not current users.  What's the best
behavior for them?  I think it's to separate
the file that Customize writes to from their
init file.

But _every_ user will have a simple, trivial,
quick, one-time way to get the behavior they
prefer: just set `custom-file' to the file
they want Customize to write to, whether
that be their init file or another file.

Sensible behavior by default for everyone.
Individual preferences respected.  Happy
campers, all.

When the default of `transient-mark-mode'
was switched we definitely had in mind
potential/future users as well as current ones.

> > I'm assuming you agree it's generally better, for more people than
> > not, to use a separate `custom-file'.
> 
> Yes, I agree.  If this discussion was started at the introduction of
> `custom-file', then I would certainly have argued for it to have a
> default value.

That's the right starting point, to think
about what the behavior should be.

Next comes the question about how much of
a disturbance changing to that design
would cause.

> > There are more future than past users, and for a new 
> > user the "other thing" of longstanding habit doesn't apply.
> 
> How many future users there will be is for
> the future to say, not for the present, 

The exact number, sure.  But not the relative
number.  Unless Emacs is blown off the globe
it's certain that there will be more users in
the future than there are today.

> where changing the default value will only
> serve to churn the already muddy waters.

Diehards who said the same thing about turning
on `transient-mark-mode' will admit today that
their alarmism was misplaced.  They still live
happily with `transient-mark-mode' turned off,
as their personal preference.  Really not a
big deal, though they didn't think so at the
time.

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

[Po Lu]

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

> Consider `transient-mark-mode'.
> Its existence in Emacs was status quo for a
> very long time, and the behavior was OFF.
> Until it wasn't - the status quo was changed
> to ON.  Holy Toledo!

> That was a backward-incompatible change in
> behavior.  It affected thousands of users.
> It took us _decades_ to get that change made.
> Status quo, status quo, status quo.

And I didn't like that change.  IMO, it was a bad idea, but the
decision has already been made.  Here, it has not, so it would be good
to not repeat the same mistake.

> And why was that change finally made?  It's
> what those who decided expected that more
> users would expect & want.  Users out in
> the wild expect to see text that they select
> to act on ("activated") be highlighted, so
> they can see what they'll act on.
>
> What was the effect on users who did NOT
> want `transient-mark-mode' on by default?
>
> They turned it off.  End of story.  Some
> muffled grumbles, nothing more.  Why?
> Because you can still use Emacs as before -
> just turn `t-m-mode' off (Customize).
> Happy campers all around.

Lucky.  We don't know that would be the case here.  (And it was not
the case with transient-mark-mode either.)

> Why didn't we go all the way toward what most
> new users out there really expected, which is
> something more like `delete-selection-mode'
> (which turns on `transient-mark-mode')?  Why
> stop with `t-m-mode', which corresponds to
> neither what users get outside Emacs nor what
> Emacs behavior is with `t-m-mode' off?
>
> We should have, IMO.  Not enough weight to
> balance the rotund body of Status Quo.  I've
> been betting on `delete-selection-mode' being
> turned on by default after a few decades, but
> it's already been a few decades now...  (I'm
> still betting on that happening sometime.)

Turning delete-selection-mode on by default would be extremely
confusing.  I sincerely hope that long standing default behavior will
never change as well.

> I'm as strong a proponent of not rocking the
> status-quo boat as anyone.  And opinions can
> certainly differ about whether `custom-file'
> should default to a file name.  But what's
> the downside of changing such a default
> change?
>
> A relatively few users - those who remain
> wedded to using only their init file - would
> need to set `custom-file' to their init file
> (or to nil, if we interpret that as using
> the init file after the default change).

> Yes, and?  Anyone can rely on the behavior
> they've long relied on and enjoyed, by just
> setting `custom-file' to their init file.
> End of story.

Nobody knows how "few" those users are, and even if someone did, it
would still be better to cause less churn.

> In the case of `transient-mark-mode' I'd wager
> that the _vast_ majority - maybe 90% - of
> existing Emacs users had `t-m-mode' off when
> the default was switched to on.

From anecdotal experience at my workplace, that is simply false.

> And I'd wager that a minority of them bothered
> to switch it to off after the default changed.

Also untrue.

> It's not only about individual preferences,
> and especially not only about _current_ ones.
>
> It's also about what we expect will be best
> for most users, and in particular most users
> in the future.  Most Emacs users are future
> users, not current users.  What's the best
> behavior for them?  I think it's to separate
> the file that Customize writes to from their
> init file.
>
> But _every_ user will have a simple, trivial,
> quick, one-time way to get the behavior they
> prefer: just set `custom-file' to the file
> they want Customize to write to, whether
> that be their init file or another file.
>
> Sensible behavior by default for everyone.
> Individual preferences respected.  Happy
> campers, all.

That's a catch-all excuse to make random changes, and a very slippery
slope.  Imagine how many "one-time solutions" there would have to be
if we made more and more changes under that slogan.

> The exact number, sure.  But not the relative
> number.  Unless Emacs is blown off the globe
> it's certain that there will be more users in
> the future than there are today.

And that globe might as well be blown to pieces tomorrow, so it is
utterly pointless to make changes to please those who might not even
exist.

> Diehards who said the same thing about turning
> on `transient-mark-mode' will admit today that
> their alarmism was misplaced.

I don't.  I know as a fact that it's annoying for people switching
between Emacs 23 and 21, both of which still have users.

Thanks.

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

[LdBeth]

>>>>> In <87lezrvyfx.fsf@yahoo.com> 
>>>>>	Po Lu <luangruo@yahoo.com> wrote:
DA> And why was that change finally made?  It's
DA> what those who decided expected that more
DA> users would expect & want.  Users out in
DA> the wild expect to see text that they select
DA> to act on ("activated") be highlighted, so
DA> they can see what they'll act on.
DA>
DA> What was the effect on users who did NOT
DA> want `transient-mark-mode' on by default?
DA>
DA> They turned it off.  End of story.  Some
DA> muffled grumbles, nothing more.  Why?
DA> Because you can still use Emacs as before -
DA> just turn `t-m-mode' off (Customize).
DA> Happy campers all around.

PL> Lucky.  We don't know that would be the case
PL> here.  (And it was not the case with
PL> transient-mark-mode either.)

DA> Why didn't we go all the way toward what most
DA> new users out there really expected, which is
DA> something more like `delete-selection-mode'
DA> (which turns on `transient-mark-mode')?  Why
DA> stop with `t-m-mode', which corresponds to
DA> neither what users get outside Emacs nor what
DA> Emacs behavior is with `t-m-mode' off?
DA>
DA> We should have, IMO.  Not enough weight to
DA> balance the rotund body of Status Quo.  I've
DA> been betting on `delete-selection-mode' being
DA> turned on by default after a few decades, but
DA> it's already been a few decades now...  (I'm
DA> still betting on that happening sometime.)

PL> Turning delete-selection-mode on by default
PL> would be extremely confusing.  I sincerely
PL> hope that long standing default behavior will
PL> never change as well.

Before reading this thread I was not aware of the
`delete-selection-mode' after years of using
Emacs.

Think it might be a idea to add a list of customize variables
that could make Emacs behavior closer to "modern
editors" experience to the setup wizard (or
tutorial).

-- 
LDB

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

[Po Lu]

LdBeth <andpuke@foxmail.com> writes:

> Before reading this thread I was not aware of the
> `delete-selection-mode' after years of using Emacs.

> Think it might be a idea to add a list of customize variables that
> could make Emacs behavior closer to "modern editors" experience to the
> setup wizard (or tutorial).

Yes, it would be a good option for a setup wizard.  It makes Emacs
behave closer to other X programs, though I personally don't find its
behaviour very intuitive.

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

[Eli Zaretskii]

> Date: Sat, 08 Jan 2022 11:13:49 +0800
> From: LdBeth <andpuke@foxmail.com>
> Cc: Yuan Fu <casouri@gmail.com>, Tim Cross <theophilusx@gmail.com>,
>  Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> Think it might be a idea to add a list of customize variables
> that could make Emacs behavior closer to "modern
> editors" experience to the setup wizard (or
> tutorial).

Feel free to propose such a list.

TIA

Add list of useful settings to setup wizard was: Re: Default custom file

[LdBeth]

>>>>> In <83ee5i4rve.fsf@gnu.org> 
>>>>>	Eli Zaretskii <eliz@gnu.org> wrote:

ldb> Think it might be a idea to add a list of customize variables
ldb> that could make Emacs behavior closer to "modern editors"
ldb> experience to the setup wizard (or tutorial).

> Feel free to propose such a list.

> TIA

Sure, these are what I can think of so far that can improve the
editing experience of a newcomer to emacs. Please feel free to make
comment on and edit this list.

* List of interesting editing packages

Builtin packages can may benifit anyone who expecting some features
from other editors.

** EDT
  It would be strange to consider EDT as "modern", that thing is
  probably as old as TECO. But this could still be useful if you have
  a keypad. You may get the manual about EDT from the internet.

  Probably useful link: http://edt-text-editor.sourceforge.net

** hl-line
  Toggled via =hl-line-mode=. Might be useful for VI user's.

** cua-mode
  Undo, Cut, Copy, Paste.

** autoarg-mode
  Make numberic arguments as prefix commands. Might be useful for
  VI addicted.

  *PS: This one probably needs fixes, binding C-DIGIT to
  `self-insert-command' won't make it insert DIGIT.*

** delete-selection-mode
  When Delete Selection mode is enabled, typed text replaces the
  selection if the selection is active.

** align, delimit-columns-region
  "Align regions in a context-sensitive fashion."
  "Helps to prettify columns in a text region or rectangle."

** auto-revert-mode
  Update buffer when file changes.

** ruler-mode
  Something you'd get in a word processor.

** whitespace-mode
  And =whitespace-cleanup=.

** tab-bar-mode, tab-line-mode
  Tabbar emulation.

** mouse-avoidance-mode
  Hide your mouse pointer.

** kinsoku
   Avoid certain characters appear at beg-of-line..

** strokes-mode
   Useful if you have a 3-key mouse.

* List of interesting editing customize variables

  This variables are worth to have a look at. They may improve your
  editing experience a little if the default value of the variables
  are changed for your specific needs.

+ show-trailing-whitespace
+ track-eol
+ colon-double-space
+ tab-always-indent
+ kill-do-not-save-duplicates
+ kill-read-only-ok
+ kill-whole-line
+ set-mark-command-repeat-pop
+ case-fold-search
+ require-final-newline


-- 
LDB

Re: Add list of useful settings to setup wizard was: Re: Default custom file

[Eli Zaretskii]

> Date: Sat, 08 Jan 2022 21:32:48 +0800
> From: LdBeth <andpuke@foxmail.com>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> 
> ** align, delimit-columns-region
>   "Align regions in a context-sensitive fashion."
>   "Helps to prettify columns in a text region or rectangle."
> 
> ** auto-revert-mode
>   Update buffer when file changes.
> 
> ** ruler-mode
>   Something you'd get in a word processor.
> 
> ** whitespace-mode
>   And =whitespace-cleanup=.
> 
> ** mouse-avoidance-mode
>   Hide your mouse pointer.
> 
> ** kinsoku
>    Avoid certain characters appear at beg-of-line..
> 
> ** strokes-mode
>    Useful if you have a 3-key mouse.

I'm not sure I understand what other editors does each of the above
features emulate.  Can you spell that out?

Thanks.

Re: Add list of useful settings to setup wizard was: Re: Default custom file

[LdBeth]

>>>>> In <83zgo62u6f.fsf@gnu.org> 
>>>>>	Eli Zaretskii <eliz@gnu.org> wrote:

> I'm not sure I understand what other editors does each of the above
> features emulate.  Can you spell that out?

> Thanks.

I might not able to make a comprehensive list and what listed probably
do not own the original idea, just speaking from what I know:

ldb> ** align, delimit-columns-region
ldb>   "Align regions in a context-sensitive fashion."
ldb>   "Helps to prettify columns in a text region or rectangle."

Vim via vim-easy-align plugin. There are bunches of other editors or
IDEs providing this feature via plugins.

ldb> ** auto-revert-mode
ldb>   Update buffer when file changes.

Many IDE's that would allow external editors would have this.
XCode has this via the file watcher API provided by OSX.
VSCode now also has this feature. 

ldb> ** ruler-mode
ldb>   Something you'd get in a word processor.

TextEdit.app or MS Word although that's meant for rich text.

ldb> ** whitespace-mode
ldb>   And =whitespace-cleanup=.

Sublime Text/Atom has this.

ldb> ** mouse-avoidance-mode
ldb>   Hide your mouse pointer.

That feature (hide mouse when typing) is usually provided by external
software or via system wide configuration on nonefree OS.

ldb> ** kinsoku
ldb>    Avoid certain characters appear at beg-of-line..

This feature is usually provided by typesetting software for
processing eastern languages.  EmEditor provides this.

ldb> ** strokes-mode
ldb>    Useful if you have a 3-key mouse.

This feature is common on web browsers such as FireFox.

-- 
LDB

Re: Add list of useful settings to setup wizard was: Re: Default custom file

[Stefan Kangas]

LdBeth <andpuke@foxmail.com> writes:

> Sure, these are what I can think of so far that can improve the
> editing experience of a newcomer to emacs. Please feel free to make
> comment on and edit this list.

The only ones from your list I think could be relevant to a beginner are
`cua-mode' and `delete-selection-mode.

Perhaps you could include `hl-line-mode' (which I use myself), but I'm
not sure it is important enough.  Same goes for `mouse-avoidance-mode'.

I would strongly advise against including either `edt' or `autoarg-mode'
in a list of modes to recommend to a beginner.

> ** tab-bar-mode, tab-line-mode
>   Tabbar emulation.

I don't use it much.  Is it polished enough?

> ** kinsoku
>    Avoid certain characters appear at beg-of-line..

I don't understand what this does or when I would want to use it from
reading it's docstring.  Probably it should be better documented.

The name is also... confusing.

> * List of interesting editing customize variables
>
>   This variables are worth to have a look at. They may improve your
>   editing experience a little if the default value of the variables
>   are changed for your specific needs.
>
> + show-trailing-whitespace
> + track-eol
> + colon-double-space
> + tab-always-indent
> + kill-do-not-save-duplicates
> + kill-read-only-ok
> + kill-whole-line
> + require-final-newline

Sounds basically good at a glance, with some exceptions:

> + case-fold-search

I think we have commands for this, so I'd not specifically recommend new
users to fiddle with it.

> + set-mark-command-repeat-pop

I don't understand what it does and I doubt a beginner would either.

Re: Add list of useful settings to setup wizard was: Re: Default custom file

[LdBeth]

>>>>> In <CADwFkmmm3-f0X71JyJF4hCs6qDyCGy6TvP-prp15Vxmeyg=Zgw@mail.gmail.com> 
>>>>>	Stefan Kangas <stefankangas@gmail.com> wrote:

Stefan> I would strongly advise against including either `edt' or
Stefan> `autoarg-mode' in a list of modes to recommend to a beginner.

Right, there're referenced only for "historical significance" and
could only be interested by writers of emulation modes.

ldb> ** tab-bar-mode, tab-line-mode
ldb>   Tabbar emulation.

Stefan> I don't use it much.  Is it polished enough?

It is quite popular among people migrated from other editors. There's
even a popular extension been made based on that package.

https://github.com/manateelazycat/awesome-tab

ldb> ** kinsoku
ldb>    Avoid certain characters appear at beg-of-line..

Stefan> I don't understand what this does or when I would want to use it from
Stefan> reading it's docstring.  Probably it should be better documented.

Stefan> The name is also... confusing.


When filling a paragraph, you probably won't like commas or periods to
appear at the beginning of a line, or left parentheses hanging at the
end of line.

   The rabbit-hole went straight on like a tunnel for some way
   , and then dipped suddenly down

   even if I fell off the top of the house!' (
   Which was very likely true.)

The above cases can be handled correctly by `M-q' though.  But certain
languages like Japanese can not be handled correctly with the default
behavior `fill-paragraph'. This package takes extra care to these
language.

ldb> * List of interesting editing customize variables
ldb>
ldb>   This variables are worth to have a look at. They may improve your
ldb>   editing experience a little if the default value of the variables
ldb>   are changed for your specific needs.
ldb>
ldb> + show-trailing-whitespace
ldb> + track-eol
ldb> + colon-double-space
ldb> + tab-always-indent
ldb> + kill-do-not-save-duplicates
ldb> + kill-read-only-ok
ldb> + kill-whole-line
ldb> + require-final-newline

Stefan> Sounds basically good at a glance, with some exceptions:

ldb> + case-fold-search

Stefan> I think we have commands for this, so I'd not specifically
Stefan> recommend new users to fiddle with it.

Right, but we could provide a brief list for useful toggles.

ldb> + set-mark-command-repeat-pop

Stefan> I don't understand what it does and I doubt a beginner would
Stefan> either.

Right, this would requires knowledge about mark-ring, should just
leave this to advanced users.

-- 
LDB

Re: Add list of useful settings to setup wizard was: Re: Default custom file

[John Yates]

On Sat, Jan 8, 2022 at 8:34 AM LdBeth <andpuke@foxmail.com> wrote:
>
> ** EDT
>   It would be strange to consider EDT as "modern", that thing is
>   probably as old as TECO.

In fact their ages differ by about a decade.

Dan Murphy wrote TECO in 1962 on the MIT RLE venerable PDP-1:
    https://en.wikipedia.org/wiki/TECO_(text_editor)

EDT was an outgrowth of RT-11's KED:
    https://en.wikipedia.org/wiki/EDT_(Digital)

RT-11 first shipped in 1970:
    https://en.wikipedia.org/wiki/RT-11

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

On Sat, Jan 08, 2022 at 08:54:58AM +0800, Po Lu wrote:
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > Consider `transient-mark-mode'.
> > Its existence in Emacs was status quo for a
> > very long time, and the behavior was OFF.
> > Until it wasn't - the status quo was changed
> > to ON.  Holy Toledo!
> 
> > That was a backward-incompatible change in
> > behavior.  It affected thousands of users.
> > It took us _decades_ to get that change made.
> > Status quo, status quo, status quo.

Drew,

this is being polemic, and you know it.

There may be reasons for a change (there often are), but they should be
discussed on their merits. Sometimes, that discussion is arduous,
because there are folks who prefer the old behaviour.

Dismissing something just because it sticks to the "status quo" is a
disrespect towards those users who /in this one case/ prefer this status
quo for whatever good (to them!) reason. Gotta listen to that, instead
of just telling them "you're a luddite" or "you're just resistant to
change".

This can be even offensive: after all, it's a way of telling those
people "you don't exist". Big flamewars have been in part fuelled by
this pattern.

With a program as old as Emacs, which will have lots of more old users
than new, I think those discussions are necessary.

In the present case, I'm against the proposed change. Why? Because it
alienates some old users for no reason but some "pedagogy" towards
hypothetical new users, although there would be far better means to
achieve that (several have been proposed in this thread).

Personally, I won't be affected by that: I separated off the custom file
long ago anyway. I'd be miffed had I not and had the change come anyway
(I'm one of those who /edit/ the custom file after Customize has done
its work, because (a) I can't stand "HANDS OFF! THIS FILE NOT FOR YOU!",
and (b) because at the beginning it was a wonderful way to learn about
Emacs's inner workings).

So I can feel with those who now oppose this change.

> They turned it off.  End of story.  Some
> muffled grumbles, nothing more.  Why?
> Because you can still use Emacs as before -
> just turn `t-m-mode' off (Customize).
> Happy campers all around.

You are overlooking something important: our community is (compared to
others) pretty civilised. Idiosyncratic, yes, but civilised. The
maintainers are highly respected people (at least among most old timers,
and this /is/ an important part of our community). So once a decision
has been reached, each one tries to get along with it.

Still, I think this comes both ways, and this seemingly endless
discussions are part of what helps people to stay civilised, because
concerns from all sides are heard.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Po Lu]

<tomas@tuxteam.de> writes:

>> They turned it off.  End of story.  Some
>> muffled grumbles, nothing more.  Why?
>> Because you can still use Emacs as before -
>> just turn `t-m-mode' off (Customize).
>> Happy campers all around.

> You are overlooking something important: our community is (compared to
> others) pretty civilised. Idiosyncratic, yes, but civilised. The
> maintainers are highly respected people (at least among most old
> timers, and this /is/ an important part of our community). So once a
> decision has been reached, each one tries to get along with it.

+1

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

[xenodasein--- via Emacs development discussions.]

<tomas@tuxteam.de> writes:

>>> They turned it off.  End of story.  Some
>>> muffled grumbles, nothing more.  Why?
>>> Because you can still use Emacs as before -
>>> just turn `t-m-mode' off (Customize).
>>> Happy campers all around.
>>>
>> You are overlooking something important: our community is (compared to
>> others) pretty civilised. Idiosyncratic, yes, but civilised. The
>> maintainers are highly respected people (at least among most old
>> timers, and this /is/ an important part of our community). So once a
>> decision has been reached, each one tries to get along with it.
>>

I wouldn't call, opposing to setting a handful of variables every
couple of years to disable new developments and instead stagnating
your favorite libre editor into oblivion, civilized.

If it is that painful to make Customize use its own data file, what
hope would there be to make big improvements to it?

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I wouldn't call, opposing to setting a handful of variables every
> couple of years to disable new developments and instead stagnating
> your favorite libre editor into oblivion, civilized.

Nothing is "stagnating".  Not changing an established default is not
"stagnating".

> If it is that painful to make Customize use its own data file

It already can via `custom-file', which see.

> what hope would there be to make big improvements to it?

I don't see how not changing the default value of custom-file conflicts
with making actual improvements to custom.

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 14:14 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> I wouldn't call, opposing to setting a handful of variables every
>> couple of years to disable new developments and instead stagnating
>> your favorite libre editor into oblivion, civilized.
>>
>
> Nothing is "stagnating".  Not changing an established default is not
> "stagnating".
>

Everything is stagnatin'.  :)
Not changing an established default can be a sign of stagnation.


>> If it is that painful to make Customize use its own data file
>>
>
> It already can via `custom-file', which see.
>
>> what hope would there be to make big improvements to it?
>>
>
> I don't see how not changing the default value of custom-file conflicts
> with making actual improvements to custom.
>

Then read what has been discussed.

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Not changing an established default can be a sign of stagnation.

That statement is wrong.

> Then read what has been discussed.

I did, care to point out anything I might've missed?
TIA.

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 15:44 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Not changing an established default can be a sign of stagnation.
>>
>
> That statement is wrong.
>

Above statement is wrong.


>> Then read what has been discussed.
>>
>
> I did, care to point out anything I might've missed?
> TIA.
>

Hopefully you will forgive me as I don't have the energy to reanalyze
and paraphrase everything that has been said so far in favor of
changing the default.  I can say this much; how many mails are there,
50, 100?  Now if it takes all that for one variable, how many will it
take for nontrivial changes?

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Now if it takes all that for one variable, how many will it take for
> nontrivial changes?

Let me name several nontrivial changes from the past 24 hours that
gained less than 100 replies:

 - XIM pre-edit text support
 - Native GTK input support
 - Using auth-info-password in TRAMP
 - rcirc-when

The difference between Drew's proposal and the others is that his
proposal will make for a breaking change.  IMO, breaking changes must be
avoided to the best of everyone's ability, in order to minimize the
disruption posed to the work and lives of many people.

Also, take a look at Emacs 29 NEWS, to see how many nontrivial changes
have been made in Emacs from October to now.

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 16:16 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Now if it takes all that for one variable, how many will it take for
>> nontrivial changes?
>>
>
> Let me name several nontrivial changes from the past 24 hours that
> gained less than 100 replies:
>
>  - XIM pre-edit text support
>  - Native GTK input support
>  - Using auth-info-password in TRAMP
>  - rcirc-when
>
> The difference between Drew's proposal and the others is that his
> proposal will make for a breaking change.  IMO, breaking changes must be
> avoided to the best of everyone's ability, in order to minimize the
> disruption posed to the work and lives of many people.
>
> Also, take a look at Emacs 29 NEWS, to see how many nontrivial changes
> have been made in Emacs from October to now.
>

This is plain know-it-all-ery.  Not cool.  You know we are talking about
breaking changes.  We know it is better to avoid breaking changes,
until you can't.

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You know we are talking about breaking changes.  We know it is better
> to avoid breaking changes, until you can't.

There is nothing preventing custom from being improved by leaving the
default value of a single option intact, if that's what you worry about.

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 16:33 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> You know we are talking about breaking changes.  We know it is better
>> to avoid breaking changes, until you can't.
>>
>
> There is nothing preventing custom from being improved by leaving the
> default value of a single option intact, if that's what you worry about.
>

There is something preventing custom from being improved by leaving the
default value of a single option intact, whether you get it or not.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Sat, Jan 08, 2022 at 02:44:04PM +0100, xenodasein--- via Emacs development discussions. wrote:

[...]

> There is something preventing custom from being improved by leaving the
> default value of a single option intact, whether you get it or not.
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry, this is (again) borderline arrogant. There are many of us who
don't "get it". I don't think this is the way to further a discussion.
Please accept that others might be right, as you expect others to accept
that you might be right.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 17:32 by tomas@tuxteam.de:

> On Sat, Jan 08, 2022 at 02:44:04PM +0100, xenodasein--- via Emacs development discussions. wrote:
>
> [...]
>
>> There is something preventing custom from being improved by leaving the
>> default value of a single option intact, whether you get it or not.
>>
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Sorry, this is (again) borderline arrogant. There are many of us who
> don't "get it". I don't think this is the way to further a discussion.
> Please accept that others might be right, as you expect others to accept
> that you might be right.
>
> Cheers
> -- 
> t
>

Yes. That is the point.  I'm trying to show what this answers to
does the exact same thing, and it must stop.

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

[Corwin Brust]

Hi developers!

On Sat, Jan 8, 2022 at 8:47 AM xenodasein--- via Emacs development
discussions. <emacs-devel@gnu.org> wrote:
>
> Jan 8, 2022, 17:32 by tomas@tuxteam.de:
>
> > On Sat, Jan 08, 2022 at 02:44:04PM +0100, xenodasein--- via Emacs development discussions. wrote:
> >
> > [...]
> >
> >> There is something preventing custom from being improved by leaving the
> >> default value of a single option intact, whether you get it or not.
> >>
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Sorry, this is (again) borderline arrogant. There are many of us who
> > don't "get it". I don't think this is the way to further a discussion.
> > Please accept that others might be right, as you expect others to accept
> > that you might be right.
> >
> > Cheers
> > --
> > t
> >
>
> Yes. That is the point.  I'm trying to show what this answers to
> does the exact same thing, and it must stop.

I would very much prefer to be able to use a single file to contain my
hand-coded configurations as well as to save customizations.

I found this a very comfortable way to build an emacs configuration
without understanding elisp over decades.

During the last couple of years I have learned more elisp (yay, fun!)
and I don't find any frustration having to set up my custom-file
explicitly, now that this is something I prefer doing.

During the "middle years", I knew enough to configure a fresh emacs by
retyping a minimum set of elisp into a .emacs file to get myself
started from a fresh install.  (I didn't really understand how this
code I was typing worked, I just knew it made emacs easier for me to
use.)   Once my .emacs was created on the newly setup system I would
use customize to amend the configuration as I used the editor.    From
that point, I would migrate my configuration from machine to machine
until I somehow lost the .emacs file, at which point the process would
start over.

Placing customized output into the .emacs file meant I had only one
file to keep track, trying to keep my 'live configuration settings"
going.

I didn't find the mixture of hand and machine authored code in my
configuration file unexpected.   In fact, I consider that most
programs with a "control panel" seem to work this way:   if I manually
edit the rc files that work.  If I use the GUI the program updates my
rc files for me.   In this light, I see the present approach
(supporting a single .emacs file with all config/customizations in) as
rather more elegant and showcasing Emacs' expert manipulation of my
files.

Emacs is one of the only programs I trust to edit files for me

In any case, I would discourage efforts to complicate the minimum set
of user-space files required to effect a combination of configuration
and customizations.   I hope that additional understanding of Emacs
would not be required to reenable this behavior if my perspective
isn't common among emacs users.

Finally, it's unclear to me where the level of zeal toward changing
the current behavior is coming from.  I can understand that people may
well not share my view.   I don't understand the sense of urgency and
supercilious tone.   Perhaps I can ask those who strongly disagree
with my perspective to also share personal stories of how their
proposed changes would have improved their own use of Emacs over the
years.

TIA

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 20:17 by corwin@bru.st:
> Hi developers!
>
> I would very much prefer to be able to use a single file to contain my
> hand-coded configurations as well as to save customizations.
>
> I found this a very comfortable way to build an emacs configuration
> without understanding elisp over decades.
>
> During the last couple of years I have learned more elisp (yay, fun!)
> and I don't find any frustration having to set up my custom-file
> explicitly, now that this is something I prefer doing.
>
> During the "middle years", I knew enough to configure a fresh emacs by
> retyping a minimum set of elisp into a .emacs file to get myself
> started from a fresh install. (I didn't really understand how this
> code I was typing worked, I just knew it made emacs easier for me to
> use.) Once my .emacs was created on the newly setup system I would
> use customize to amend the configuration as I used the editor. From
> that point, I would migrate my configuration from machine to machine
> until I somehow lost the .emacs file, at which point the process would
> start over.
>
> Placing customized output into the .emacs file meant I had only one
> file to keep track, trying to keep my 'live configuration settings"
> going.
>
> I didn't find the mixture of hand and machine authored code in my
> configuration file unexpected. In fact, I consider that most
> programs with a "control panel" seem to work this way: if I manually
> edit the rc files that work. If I use the GUI the program updates my
> rc files for me. In this light, I see the present approach
> (supporting a single .emacs file with all config/customizations in) as
> rather more elegant and showcasing Emacs' expert manipulation of my
> files.
>
> Emacs is one of the only programs I trust to edit files for me
>
> In any case, I would discourage efforts to complicate the minimum set
> of user-space files required to effect a combination of configuration
> and customizations. I hope that additional understanding of Emacs
> would not be required to reenable this behavior if my perspective
> isn't common among emacs users.
>
> Finally, it's unclear to me where the level of zeal toward changing
> the current behavior is coming from. I can understand that people may
> well not share my view. I don't understand the sense of urgency and
> supercilious tone. Perhaps I can ask those who strongly disagree
> with my perspective to also share personal stories of how their
> proposed changes would have improved their own use of Emacs over the
> years.
>
> TIA


Hi, thanks for sharing your insights on this.

I genuinely do not understand the difficulty and difference between
having only a single file, or a directory of multiple files, among
which you only edit one.  I'd appreciate reading your reasoning on it.
What makes this more difficult than using multiple programs, which is
hard to avoid for most computer use, each with their own configurations?

The type of configuration files you describe have data-driven, easy to
edit formats, which mitigates problems when edited from an interface.
They are able to almost completely provide any type of customization
possible for their purposes.  They are very different from the
computational jungle init.el becomes in some users hands.  Unfortunately,
there is also now early-init.el, which is the only way to do some things.

But here's the thing; at least from my perspective if things go well you
will still need only one file, the custom file. You will be able to have
a majority of the customizations one would want to inside it, editable by
hand or interface.  Exactly what you described.  If you still want to
have some handwritten Elisp functions, those could be installed with
package-install-file.  Only when you want to do involved changes to Emacs
state, you would use early-init/init, which most users shouldn't have to.

AFAIU from what is envisioned on this thread, you will not need any
additional unserstanding of Emacs to have custom-set-* forms inside
init.el in the short term.

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

[Corwin Brust]

You appear to have forgotten to CC the list so I've taken the liberty
of putting the group back in CC.

Thanks for taking the trouble to send me a third message asking me to
restate what I've already said.

In any case, suffice to say: I don't think this is a helpful change; I
attempted to show why I think it is unhelpful to anyone who isn't
already comfortable with Emacs.

That said, Drew's prior note convinced me not to involve myself
further; if you can somehow convince the maintainers that this
obfuscation and further proliferation of emacs configurations across
several "dot files" should be imposed on users by default I don't
intend to object further.

On Thu, Jan 20, 2022 at 3:50 AM <xenodasein@tutanota.de> wrote:
>
> Are you in the habit of randomly calling people supercilious then
> ignore when addressed?  Okay then, don't bother, I doubt you can
> present a better argument than "I can't copy two files around"
> anyway.
>
>
>
> Jan 18, 2022, 12:55 by xenodasein@tutanota.de:
>
> > Jan 8, 2022, 21:26 by xenodasein@tutanota.de:
> >
> >> Jan 8, 2022, 20:17 by >> corwin@bru.st>> :
> >> > Hi developers!
> >> >
> >> > I would very much prefer to be able to use a single file to contain my
> >> > hand-coded configurations as well as to save customizations.
> >> >
> >> > I found this a very comfortable way to build an emacs configuration
> >> > without understanding elisp over decades.
> >> >
> >> > During the last couple of years I have learned more elisp (yay, fun!)
> >> > and I don't find any frustration having to set up my custom-file
> >> > explicitly, now that this is something I prefer doing.
> >> >
> >> > During the "middle years", I knew enough to configure a fresh emacs by
> >> > retyping a minimum set of elisp into a .emacs file to get myself
> >> > started from a fresh install. (I didn't really understand how this
> >> > code I was typing worked, I just knew it made emacs easier for me to
> >> > use.) Once my .emacs was created on the newly setup system I would
> >> > use customize to amend the configuration as I used the editor. From
> >> > that point, I would migrate my configuration from machine to machine
> >> > until I somehow lost the .emacs file, at which point the process would
> >> > start over.
> >> >
> >> > Placing customized output into the .emacs file meant I had only one
> >> > file to keep track, trying to keep my 'live configuration settings"
> >> > going.
> >> >
> >> > I didn't find the mixture of hand and machine authored code in my
> >> > configuration file unexpected. In fact, I consider that most
> >> > programs with a "control panel" seem to work this way: if I manually
> >> > edit the rc files that work. If I use the GUI the program updates my
> >> > rc files for me. In this light, I see the present approach
> >> > (supporting a single .emacs file with all config/customizations in) as
> >> > rather more elegant and showcasing Emacs' expert manipulation of my
> >> > files.
> >> >
> >> > Emacs is one of the only programs I trust to edit files for me
> >> >
> >> > In any case, I would discourage efforts to complicate the minimum set
> >> > of user-space files required to effect a combination of configuration
> >> > and customizations. I hope that additional understanding of Emacs
> >> > would not be required to reenable this behavior if my perspective
> >> > isn't common among emacs users.
> >> >
> >> > Finally, it's unclear to me where the level of zeal toward changing
> >> > the current behavior is coming from. I can understand that people may
> >> > well not share my view. I don't understand the sense of urgency and
> >> > supercilious tone. Perhaps I can ask those who strongly disagree
> >> > with my perspective to also share personal stories of how their
> >> > proposed changes would have improved their own use of Emacs over the
> >> > years.
> >> >
> >> > TIA
> >>
> >>
> >> Hi, thanks for sharing your insights on this.
> >>
> >> I genuinely do not understand the difficulty and difference between
> >> having only a single file, or a directory of multiple files, among
> >> which you only edit one.  I'd appreciate reading your reasoning on it.
> >> What makes this more difficult than using multiple programs, which is
> >> hard to avoid for most computer use, each with their own configurations?
> >>
> >> The type of configuration files you describe have data-driven, easy to
> >> edit formats, which mitigates problems when edited from an interface.
> >> They are able to almost completely provide any type of customization
> >> possible for their purposes.  They are very different from the
> >> computational jungle init.el becomes in some users hands.  Unfortunately,
> >> there is also now early-init.el, which is the only way to do some things.
> >>
> >> But here's the thing; at least from my perspective if things go well you
> >> will still need only one file, the custom file. You will be able to have
> >> a majority of the customizations one would want to inside it, editable by
> >> hand or interface.  Exactly what you described.  If you still want to
> >> have some handwritten Elisp functions, those could be installed with
> >> package-install-file.  Only when you want to do involved changes to Emacs
> >> state, you would use early-init/init, which most users shouldn't have to.
> >>
> >> AFAIU from what is envisioned on this thread, you will not need any
> >> additional unserstanding of Emacs to have custom-set-* forms inside
> >> init.el in the short term.
> >>
> >>
>

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

[Drew Adams]

> I would very much prefer to be able to use a single file to contain my
> hand-coded configurations as well as to save customizations.

There's been some misinterpretation, if not
misinformation, about what's actually been
proposed.

Nothing, in what's been proposed, would
prevent anyone from using only their init
file, i.e., continuing to have Customize
save settings to their init file.

[And nothing would prevent someone who
 loads `custom-file' already from loading
 it from wherever, whenever s?he likes, and
 as many times as s?he likes.  You didn't
 mention that need, but I mention it because
 this was another misunderstanding some
 introduced here.]

> I found this a very comfortable way to build an emacs configuration
> without understanding elisp over decades.

Yes, indeed.

> During the last couple of years I have learned more elisp (yay, fun!)
> and I don't find any frustration having to set up my custom-file
> explicitly, now that this is something I prefer doing.

Ditto.  I used to use only my init file, and
at some point I started using `custom-file'.

[In my case, I even load `custom-file' twice
 from my init file.  Getting the same effect
 without using a separate `custom-file' could
 be done, but would be tricky and somewhat
 error-prone.]

Or did you mean the opposite?  By "set up my
custom-file explicitly" did you instead mean
set your customizations in my init file, and
let Customize add customizes there?

> During the "middle years", I knew enough to configure a fresh emacs by
> retyping a minimum set of elisp into a .emacs file to get myself
> started from a fresh install.  (I didn't really understand how this
> code I was typing worked, I just knew it made emacs easier for me to
> use.)

Yes!  I tried to make the point that some
users do exactly that.  That counters the
notion that only knowledgeable users add or
edit code in their init files.  Init files
are for everyone, including novices.

> Once my .emacs was created on the newly setup system I would
> use customize to amend the configuration as I used the editor.

Sounds good.

> From that point, I would migrate my configuration from machine to machine
> until I somehow lost the .emacs file, at which point the process would
> start over.
> 
> Placing customized output into the .emacs file meant I had only one
> file to keep track, trying to keep my 'live configuration settings"
> going.

Yes, that can be a definite advantage in some
such situations.

> I didn't find the mixture of hand and machine authored code in my
> configuration file unexpected.   In fact, I consider that most
> programs with a "control panel" seem to work this way:   if I manually
> edit the rc files that work.  If I use the GUI the program updates my
> rc files for me.   In this light, I see the present approach
> (supporting a single .emacs file with all config/customizations in) as
> rather more elegant and showcasing Emacs' expert manipulation of my
> files.

OK.

> Emacs is one of the only programs I trust to edit files for me
> 
> In any case, I would discourage efforts to complicate the minimum set
> of user-space files required to effect a combination of configuration
> and customizations.   I hope that additional understanding of Emacs
> would not be required to reenable this behavior if my perspective
> isn't common among emacs users.

If you mean re-enable having Customize save
to your init file, then no.  No special
understanding would be needed.  You'd just
explicitly set variable `custom-file' to
your init file (or to nil).

> Finally, it's unclear to me where the level of zeal
> toward changing the current behavior is coming from.

I'm not sure there's any zeal in that
direction.

I proposed the change, and I've tried to
give reasons supporting it, replying to
(sometimes zealous) opposition to the
proposal.  I'm pretty tired of replying,
but I've continued to make an effort.
(I did take the weekend off.)

I don't think I've been zealous about our
making such a change.  But I have tried to
be attentive to answering arguments others
have made.

IOW, it's really not a big deal to me
whether Emacs makes such a change.  I think
it would be helpful if it did, but I won't
cry if it doesn't. In fact (as I've said),
I don't expect Emacs will make such a change.

And I don't need the change for my own
benefit.  Whether I use `custom-file' or
not is irrelevant.  (I use it, but that
doesn't matter at all.)

> I can understand that people may
> well not share my view.   I don't understand the
> sense of urgency and supercilious tone.

I don't think my own tone has been supercilious.

Nor have I expressed any sense of urgency.
In fact, I've made the same proposal (but
without specifying details) in the past -
years ago, and perhaps more than once over
the decades.  It's not as if I've suddenly
come up with this idea and insisted that
Emacs must make such a change immediately.

The point in mentioning the saga of
`transient-mark-mode' is that sometimes it
takes a long time, and perhaps more than
one discussion, for a change to be made.

I'm glad this `custom-file' thing is being
discussed now, even if no change comes from
it.

Why?  For one thing, because I'm sure that
some users who are completely unaware of
`custom-file' will start to use it.  And
for another thing, even if `custom-file'
doesn't get used by default anytime soon,
this discussion might contribute to such a
change being made sometime in the future.

> Perhaps I can ask those who strongly disagree
> with my perspective to also share personal stories of how their
> proposed changes would have improved their own use of Emacs over the
> years.

I don't disagree with your perspective at
all.  Your perspective about your personal
use, and all that you say about it, makes
sense to me.

My summary of the main argument for the proposal:

1. Separate files by default is a better
design, in the abstract.

That is, if we hadn't used the same file by
default for decades then I think there'd be
pretty widespread agreement that the design
should be separate files by default.

(The discussion has borne this out, so far.
Even forceful opponents of making the change
have admitted that IF we were starting from
scratch THEN separate files would make more
sense.)

2. All a user would need to do, to get back
the current behavior, would be to explicitly
set `custom-file' to the init file (or nil).
___

More has been argued, but that about sums it
up.  The benefit is a better default behavior.
The cost is that some users would need to add
a `setq' to their init file.

(Which users?  Not necessarily everyone who
today lets Customize save to their init file
will want or need to add that `setq'.  Some
will do so.)

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

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> There is something preventing custom from being improved by leaving the
> default value of a single option intact

That is not a rule which can be generally applied, and in this specific
case it certainly isn't true.

> whether you get it or not.

Please watch your tone.

=?gb18030?B?u9i4tKO6IFtFeHRlcm5hbF0gOiBSZTogRGVmYXVsdCBjdXN0b20gZmlsZSB3YXM6IFJlOiBQcm9wb3NlIHRvIGFkZCBzZXR1cC13aXphcmQuZWwgdG8gRUxQQQ==?=

[=?gb18030?B?emVyb2xlZQ==?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1774 bytes --]

breaking changes != better
breaking changes != cool




------------------ Ô­Ê¼Óʼþ ------------------
·¢¼þÈË:                                                                                                                        "xenodasein"                                                                                    <emacs-devel@gnu.org&gt;;
·¢ËÍʱ¼ä:&nbsp;2022Äê1ÔÂ8ÈÕ(ÐÇÆÚÁù) ÍíÉÏ9:24
ÊÕ¼þÈË:&nbsp;"luangruo"<luangruo@yahoo.com&gt;;
³­ËÍ:&nbsp;"emacs-devel"<emacs-devel@gnu.org&gt;;
Ö÷Ìâ:&nbsp;Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA



Jan 8, 2022, 16:16 by luangruo@yahoo.com:

&gt; xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org&gt;
&gt; writes:
&gt;
&gt;&gt; Now if it takes all that for one variable, how many will it take for
&gt;&gt; nontrivial changes?
&gt;&gt;
&gt;
&gt; Let me name several nontrivial changes from the past 24 hours that
&gt; gained less than 100 replies:
&gt;
&gt;&nbsp; - XIM pre-edit text support
&gt;&nbsp; - Native GTK input support
&gt;&nbsp; - Using auth-info-password in TRAMP
&gt;&nbsp; - rcirc-when
&gt;
&gt; The difference between Drew's proposal and the others is that his
&gt; proposal will make for a breaking change.&nbsp; IMO, breaking changes must be
&gt; avoided to the best of everyone's ability, in order to minimize the
&gt; disruption posed to the work and lives of many people.
&gt;
&gt; Also, take a look at Emacs 29 NEWS, to see how many nontrivial changes
&gt; have been made in Emacs from October to now.
&gt;

This is plain know-it-all-ery.&nbsp; Not cool.&nbsp; You know we are talking about
breaking changes.&nbsp; We know it is better to avoid breaking changes,
until you can't.

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Sat, Jan 08, 2022 at 01:59:37PM +0100, xenodasein--- via Emacs development discussions. wrote:
> Jan 8, 2022, 15:44 by luangruo@yahoo.com:
> 
> > xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> > writes:
> >
> >> Not changing an established default can be a sign of stagnation.
> >>
> >
> > That statement is wrong.
> >
> 
> Above statement is wrong.

Let's agree on "both statements can be wrong"?

I think xenodasein's characterization sufficiently careful in this case:
"can be a sign of...". That means that it isn't a sure sign. More
evidence would be necessary to reach a clear conclusion. We seem to
agree, after all?

Peace :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 17:28 by tomas@tuxteam.de:

> On Sat, Jan 08, 2022 at 01:59:37PM +0100, xenodasein--- via Emacs development discussions. wrote:
>
>> Jan 8, 2022, 15:44 by luangruo@yahoo.com:
>>
>> > xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>> > writes:
>> >
>> >> Not changing an established default can be a sign of stagnation.
>> >>
>> >
>> > That statement is wrong.
>> >
>>
>> Above statement is wrong.
>>
>
> Let's agree on "both statements can be wrong"?
>
> I think xenodasein's characterization sufficiently careful in this case:
> "can be a sign of...". That means that it isn't a sure sign. More
> evidence would be necessary to reach a clear conclusion. We seem to
> agree, after all?
>
> Peace :-)
>
> Cheers
> -- 
> t
>

1+

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Sat, Jan 08, 2022 at 11:39:04AM +0100, xenodasein--- via Emacs development discussions. wrote:
> <tomas@tuxteam.de> writes:

[...]

> >> You are overlooking something important: our community is (compared to
> >> others) pretty civilised [...]

> I wouldn't call, opposing to setting a handful of variables every
> couple of years to disable new developments and instead stagnating
> your favorite libre editor into oblivion, civilized.
> 
> If it is that painful to make Customize use its own data file, what
> hope would there be to make big improvements to it?

I may very well be wrong (this is not a rhethoric device, but just age:
I've been wrong more times than I can count!), but I perceive your
position as extreme.

The opposition is not there "to disable new developments". It's usually
there because some people (it's not /always the same/ people!) don't
like a change.

Surely some discussion is in order to either convince those people or to
redesign the change in a way that it hopefully makes people happy?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[xenodasein--- via Emacs development discussions.]

Jan 8, 2022, 14:42 by tomas@tuxteam.de:

> On Sat, Jan 08, 2022 at 11:39:04AM +0100, xenodasein--- via Emacs development discussions. wrote:
>
>> <tomas@tuxteam.de> writes:
>>
>
> [...]
>
>> >> You are overlooking something important: our community is (compared to
>> >> others) pretty civilised [...]
>>
>> I wouldn't call, opposing to setting a handful of variables every
>> couple of years to disable new developments and instead stagnating
>> your favorite libre editor into oblivion, civilized.
>>
>> If it is that painful to make Customize use its own data file, what
>> hope would there be to make big improvements to it?
>>
>
> I may very well be wrong (this is not a rhethoric device, but just age:
> I've been wrong more times than I can count!), but I perceive your
> position as extreme.
>
> The opposition is not there "to disable new developments". It's usually
> there because some people (it's not /always the same/ people!) don't
> like a change.
>
> Surely some discussion is in order to either convince those people or to
> redesign the change in a way that it hopefully makes people happy?
>
> Cheers
> -- 
> t
>

Agreed, I came out as too extreme as to where things are, but I believe
things are at least leaning that way.

Discussion is great, especially when opinions are more amenable to
movement.  We must know how much inconvenience to users is too much
and adjust, as we can't avoid it completely.  Freedom always comes at
a cost, and that cost is involvement.

Cheers.

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

[Drew Adams]

> > > Consider `transient-mark-mode'.
> > > Its existence in Emacs was status quo for a
> > > very long time, and the behavior was OFF.
> > > Until it wasn't - the status quo was changed
> > > to ON.  Holy Toledo!
> >
> > > That was a backward-incompatible change in
> > > behavior.  It affected thousands of users.
> > > It took us _decades_ to get that change made.
> > > Status quo, status quo, status quo.
> 
> this is being polemic, and you know it.

Sorry, but I disagree.

I don't think there's anything polemical in what
I said.  If you refer to reasoned argument then
sure.  But if you're suggesting dogmatic reflex
and argument for argument's sake then I have to
disagree.

The point made was that sometimes (sometimes)
we do change the default behavior of something
(e.g. from off to on or vice versa).  And even
something that affects _lots_ of users.

Not often, thank goodness!  As I said, I'm one
of the strongest proponents, in general, for
NOT changing default behavior.

But sometimes we do.  We can.  And sometimes,
as in the case of `transient-mark-mode', the
change in default behavior even takes place
after a very long time - i.e., we flip a very
longstanding behavior.

That was the point, and it was made in response
to an argument that the behavior shouldn't be
changed _only because_ it's longstanding.  My
point was that that argument, alone, isn't a
strong one.  It's a legitimate argument, but on
its own it doesn't override all other argument.

The point is NOT that status quo is bad (far
from it), or that status quo should never be
changed.  The point is that change is sometimes
merited, even for longstanding behavior.

Nothing more.  I was countering the blanket
argument that nothing longstanding can or should
ever be changed.  (And yes, such a blanket
argument was made, IMO.)

> There may be reasons for a change (there often are), but they should be
> discussed on their merits. Sometimes, that discussion is arduous,
> because there are folks who prefer the old behaviour.

Exactly.  Which is why this is being discussed
on its merits.  And its costs.

> Dismissing something just because it sticks to the "status quo" 

No one did that.  Certainly not I.

> is a disrespect towards those users who /in this one case/ prefer this status
> quo for whatever good (to them!) reason. Gotta listen to that, instead
> of just telling them "you're a luddite" or "you're just resistant to
> change".

You are acting alarmist, IMO.  No one said
anything like your characterization.

(I'm in fact most often thought of as being
resistant to change.  I'm not systematically
opposed to change, but some have accused me
of that.  I do tend to oppose change for
which no reasons have been given, and whose
reasons are not obvious.)

> This can be even offensive: after all, it's a way of telling those
> people "you don't exist". Big flamewars have been in part fuelled by
> this pattern.

Sorry, but you're really being over the top.
I'm not telling "those people", or anyone,
any such thing.

I invite you to reread what I wrote, and then
read your response, and then think about who
might be fueling (or even igniting) flames.

(It might be enough for you to just look at
the messages that people have sent in response
to your message that I'm replying to now.  I
think you'll find that you ignited a useless
tit-for-tat emotional storm, with little-to-no
real content.  Do you disagree?  I believe you
changed the tone, as well as the content, of
the thread, and not in a positive way.)

> With a program as old as Emacs, which will
> have lots of more old users than new, I think
> those discussions are necessary.

Proposals to change behavior should always be
accompanied by reasons, and discussed with
reasons, counter-reasons, etc.

That's been the case here, at least on my end.

I'm a big fan of discussing what should be done
and (especially) why & why not.
___

And yes, it's particularly important to consider
existing users and longstanding behavior.

But the number of future users is always greater
than, not smaller than, the number of existing
users. (It might even be the case that there are
more past users than there are existing users.)

But existing users can speak for themselves,
whereas guessing what's appropriate for future
users is always risky.  Who can speak for them?
No one, really.

Examining the benefits & costs of some design,
while abstracting from what might already be
used, is one way to guess what might most help
the greater number of users.  It's reasonable
to ask what design we'd pick if starting from
scratch.

But _by itself_, such an assessment has the
disadvantage of not taking into account the
effects of a possible change on existing users.

Both (1) guessing what's best for the greater
good, and (2) guessing what's good for existing
users, are appropriate when considering what
to do.

(And yes, even though existing users can speak
for themselves, #2 is a guess, as the number of
interlocutors in the discussion is limited.)

> In the present case, I'm against the proposed change. Why?

Very good to say why.  Thank you for that.
(I appreciate disagreement with expressed
reasons, and dislike it without reasons.)

> Because it alienates some old users for no reason but some "pedagogy" towards
> hypothetical new users, although there would be far better means to
> achieve that (several have been proposed in this thread).

I think this has already been gone over in
the discussion.

[I disagree that the proposed change helps
 only new users, or that they are only
 hypothetical.

 I gave reasons why I think it can help
 experienced users as well.  And anyone who
 doesn't want the proposed default behavior
 could simply use `setq' once, to return to
 the behavior s?he had before.]  

> Personally, I won't be affected by that: I 
> separated off the custom file long ago anyway.

Likewise.  Like you, changing the default
behavior wouldn't affect me.  I proposed the
change for Emacs users in general.  I think
it would help the most users, from novice to
expert.

Even those who've expressed disagreement with
changing the default have, so far, pretty much
agreed that if letting Customize save to the
init file were not the longstanding behavior,
the better design would be to use a separate
file.

It's a better design for the default behavior.
Whether it makes sense to change to that
design now is the question. 

> I'd be miffed had I not and had the change come anyway

Would you really be _miffed_ by having to set
`custom-file' to your init file?

To me, such a strong reaction borders on a
demand that _nothing_ ever change in a way
that would cause you to do anything.  I mean,
if adding a `setq' provokes that kind of
reaction, where would it end?

I disagree with many, many, many changes
that Emacs makes, some of which require me
to go to great lengths to compensate or
adjust.  If I had a reaction such as what
you describe each time Emacs makes me change
my code or setup I'd have gone postal long
ago. ;-)  Life is too short.

> (I'm one of those who /edit/ the custom file after Customize has done
> its work, because (a) I can't stand "HANDS OFF! THIS FILE NOT FOR YOU!",
> and (b) because at the beginning it was a wonderful way to learn about
> Emacs's inner workings).

Seems like a similarly strong reaction,
just for a suggestion aimed to help users
avoid mistakes.

(I'm not defending that warning - I just
point out that it sounds like you have
quite a strong reaction there, as well.)

> So I can feel with those who now oppose this change.

I can too.  (And I think I've shown that.)

> > They turned it off.  End of story.  Some
> > muffled grumbles, nothing more.  Why?
> > Because you can still use Emacs as before -
> > just turn `t-m-mode' off (Customize).
> > Happy campers all around.
> 
> You are overlooking something important: our community
> is (compared to others) pretty civilised.

Why/how do you think I'm overlooking such
a thing?

> Idiosyncratic, yes, but civilised. The
> maintainers are highly respected people (at least among most old timers,
> and this /is/ an important part of our community). So once a decision
> has been reached, each one tries to get along with it.

Why do you think I'm overlooking that fact?

> Still, I think this comes both ways, and this seemingly endless
> discussions are part of what helps people to stay civilised, because
> concerns from all sides are heard.

I haven't tried to silence the discussion.

I happen to agree that discussion, especially
reasoned argument - presenting reasons -
promotes a civilized, cooperative community,
as well as it advances understanding.
Dialectic.

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

[Drew Adams]

> > Consider `transient-mark-mode'.
> > Its existence in Emacs was status quo for a
> > very long time, and the behavior was OFF.
> > Until it wasn't - the status quo was changed
> > to ON.  Holy Toledo!
> 
> > That was a backward-incompatible change in
> > behavior.  It affected thousands of users.
> > It took us _decades_ to get that change made.
> > Status quo, status quo, status quo.
> 
> And I didn't like that change.  IMO, it was a bad idea, but the
> decision has already been made.

It too hadn't been made when it was being discussed.

> Here, it has not, so it would be good
> to not repeat the same mistake.

It wasn't a mistake; it was done deliberately.
You don't like it; that doesn't make it a mistake.

> > And why was that change finally made?  It's
> > what those who decided expected that more
> > users would expect & want.  Users out in
> > the wild expect to see text that they select
> > to act on ("activated") be highlighted, so
> > they can see what they'll act on.
> >
> > What was the effect on users who did NOT
> > want `transient-mark-mode' on by default?
> >
> > They turned it off.  End of story.  Some
> > muffled grumbles, nothing more.  Why?
> > Because you can still use Emacs as before -
> > just turn `t-m-mode' off (Customize).
> > Happy campers all around.
> 
> Lucky.  We don't know that would be the case here.
> (And it was not the case with transient-mark-mode either.)

You're mixing things up.

It's not about whether you like the change to
`t-m-mode' ON by default.

The point in mentioning `t-m-mode' (since you
didn't like the example of `lexical-binding')
was to point out that longstanding (even very
longstanding) default behavior is sometimes
changed/flipped.  And that's sometimes done
after a lot of discussion.

And we do know that it would be the case that
you would be able to keep the current behavior
just by setting `custom-file' to your init file.
You can do that today.  Try it, or look at the
code for _function_ `custom-file', to see.

See the last line:

(defun custom-file (&optional no-error)
  "Return the file name for saving customizations."
  (if (or (null user-init-file)
          (and (null custom-file) init-file-had-error))
      ;; Started with -q, i.e. the file containing
      ;; Custom settings hasn't been read.  Saving
      ;; settings there won't make much sense.
      (if no-error
	  nil
	(user-error "Saving settings from \"emacs -q\" \
would overwrite existing customizations"))
    (file-chase-links (or custom-file user-init-file))))

> > I'm as strong a proponent of not rocking the
> > status-quo boat as anyone.  And opinions can
> > certainly differ about whether `custom-file'
> > should default to a file name.  But what's
> > the downside of changing such a default
> > change?
> >
> > A relatively few users - those who remain
> > wedded to using only their init file - would
> > need to set `custom-file' to their init file
> > (or to nil, if we interpret that as using
> > the init file after the default change).
> 
> > Yes, and?  Anyone can rely on the behavior
> > they've long relied on and enjoyed, by just
> > setting `custom-file' to their init file.
> > End of story.
> 
> Nobody knows how "few" those users are,

I said "relatively" few.  And I'm sticking to
that.  (1) Fewer users today than tomorrow.
(2) How many existing users will insist on
continuing to let Customize save to their init
file?  I'm betting on relatively few.

> and even if someone did, it would still be
> better to cause less churn.

There you go again.  Turning a discussion of
relative cost/benefit into a black-&-white
less-churn-ALWAYS-better, aka NO-change-EVER.

> > In the case of `transient-mark-mode' I'd wager
> > that the _vast_ majority - maybe 90% - of
> > existing Emacs users had `t-m-mode' off when
> > the default was switched to on.
> 
> From anecdotal experience at my workplace, that is simply false.

At your workplace?  How many users at your
workplace had `t-m-mode' turned ON before
the default was switched to ON?

I don't know anyone who had it turned ON
before the change.  When it was turned on
by default it was a change for everyone I
knew who used Emacs.

So I'd still make that wager.  Will we ever
know?  Nope.

But maybe you'd grant that many Emacs users
had t-m-mode OFF when the switch to ON by
default was made - even if you don't agree
that they were the vast majority.

> > And I'd wager that a minority of them bothered
> > to switch it to off after the default changed.
> 
> Also untrue.

It's a wager.  (It's definitely true that
I'd wager that.)  We'll never know for sure
what proportion who had it off before the
change (which you think was not the vast
majority, at least) went to the trouble of
turning it off explicitly after the change.

> > It's not only about individual preferences,
> > and especially not only about _current_ ones.
> >
> > It's also about what we expect will be best
> > for most users, and in particular most users
> > in the future.  Most Emacs users are future
> > users, not current users.  What's the best
> > behavior for them?  I think it's to separate
> > the file that Customize writes to from their
> > init file.
> >
> > But _every_ user will have a simple, trivial,
> > quick, one-time way to get the behavior they
> > prefer: just set `custom-file' to the file
> > they want Customize to write to, whether
> > that be their init file or another file.
> >
> > Sensible behavior by default for everyone.
> > Individual preferences respected.  Happy
> > campers, all.
> 
> That's a catch-all excuse to make random changes, and a very slippery
> slope.  Imagine how many "one-time solutions" there would have to be
> if we made more and more changes under that slogan.

None of that follows.  It's not because Emacs
makes a rare flip of default behavior, with a
trivial way to get the pre-change behavior,
that Emacs is obliged to flip default behavior
all over the place.  Let's not be alarmist.

> > The exact number, sure.  But not the relative
> > number.  Unless Emacs is blown off the globe
> > it's certain that there will be more users in
> > the future than there are today.
> 
> And that globe might as well be blown to pieces tomorrow, so it is
> utterly pointless to make changes to please those who might not even
> exist.

Huh?

> > Diehards who said the same thing about turning
> > on `transient-mark-mode' will admit today that
> > their alarmism was misplaced.
> 
> I don't.  I know as a fact that it's annoying for people switching
> between Emacs 23 and 21, both of which still have users.

 /s/diehards/SOME diehards

Other diehard anti-transient-moders no doubt stick
to their guns.  That's their right, and they can
do so just by turning that mode off.  Thankfully.
End of story.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It wasn't a mistake; it was done deliberately.
  > You don't like it; that doesn't make it a mistake.

We made the decision to change Transient-Mark mode after much thought.
One can argue that it was a bad decision (though users generally
accepted it), but it was not an instance of carelessness.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[xenodasein--- via Emacs development discussions.]

Jan 12, 2022, 07:55 by rms@gnu.org:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > It wasn't a mistake; it was done deliberately.
>  > You don't like it; that doesn't make it a mistake.
>
> We made the decision to change Transient-Mark mode after much thought.
> One can argue that it was a bad decision (though users generally
> accepted it), but it was not an instance of carelessness.
>
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>

I don't know the history of it but I'm glad reason has won.  Personally
not liking nor using such features is totally fine, hell if I show what
I do with the computer it would be understandable if someone wants to set
it on fire immediately.  Arguing it was a bad decision and wanting casual
users to not use t-m-m though IMO would be in the same vein as "visual
editing is a mistake, we should all use Ed" or "human-computer interaction
is no research for real men."

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

[Eli Zaretskii]

> Date: Wed, 12 Jan 2022 09:58:17 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> Jan 12, 2022, 07:55 by rms@gnu.org:
> 
> > We made the decision to change Transient-Mark mode after much thought.
> > One can argue that it was a bad decision (though users generally
> > accepted it), but it was not an instance of carelessness.
> 
> I don't know the history of it but I'm glad reason has won.

Since reason was on both sides of that discussion, it was a win-win
situation for reason, no matter what was the outcome.

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

[Po Lu]

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

> And we do know that it would be the case that
> you would be able to keep the current behavior
> just by setting `custom-file' to your init file.
> You can do that today.  Try it, or look at the
> code for _function_ `custom-file', to see.

Then that's not the current behaviour, which is to use the init file if
custom-file is nil.

> None of that follows.  It's not because Emacs
> makes a rare flip of default behavior, with a
> trivial way to get the pre-change behavior,
> that Emacs is obliged to flip default behavior
> all over the place.  Let's not be alarmist.

That's a wager too, and I wager that is precisely what will happen.

> Huh?

I meant to say that the present is more important to worry about than
the future, and I stand by that statement.

> Other diehard anti-transient-moders no doubt stick
> to their guns.  That's their right, and they can
> do so just by turning that mode off.  Thankfully.
> End of story.

Too much work.  Anyway, the decision to turn transient-mark-mode on by
default was already made, while this has not.

Let's not turn it into a repeat of that, especially when the gain is
not likely to be remotely as visible as transient-mark-mode.

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

[Po Lu]

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

> And _why_ should the first-time-save (however
> you might define it) be the criterion?
>
> And what if there's a `custom-set-variables',
> `customize-set-variable', `customize-set-value',
> `custom-save-variables', customize-save-variable,
> `customize-save-all', `custom-save-all',
> `custom-save-faces', `customize-save-customized', 
> or `customize-saved' in the init file?

Then it's not the first time something was saved.

> What if such is not in the init file but in
> some file that's loaded by the init file?

Easy: you see if any such form was ever loaded.

> What if such files get loaded conditionally?

Then it's not something we should worry about.

Thanks.

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

[Drew Adams]

> > And _why_ should the first-time-save (however
> > you might define it) be the criterion?
> >
> > And what if there's a `custom-set-variables',
> > `customize-set-variable', `customize-set-value',
> > `custom-save-variables', customize-save-variable,
> > `customize-save-all', `custom-save-all',
> > `custom-save-faces', `customize-save-customized',
> > or `customize-saved' in the init file?
> 
> Then it's not the first time something was saved.

I don't see how that follows.

> > What if such is not in the init file but in
> > some file that's loaded by the init file?
> 
> Easy: you see if any such form was ever loaded.

Where do you see that?

> > What if such files get loaded conditionally?
> 
> Then it's not something we should worry about.

Seems clear you don't want to seem clear...

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

[Po Lu]

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

> Where do you see that?

It would work to make every one of these forms set a flag when they are
loaded.

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

>  My preference is for #3: we just bite the bullet and nudge
>  users helpfully toward using a separate file.

+1

> It would work to make every one of these forms set a flag when they are
loaded.

Doesn't that go a bit too far? Other proposals don't depend on modifying
custom-*

Just my .2cents, /PA

On Fri, 7 Jan 2022 at 05:42, Po Lu <luangruo@yahoo.com> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
>
> > Where do you see that?
>
> It would work to make every one of these forms set a flag when they are
> loaded.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1283 bytes --]

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

[Robert Pluim]

>>>>> On Fri, 7 Jan 2022 07:38:49 +0100, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    >> My preference is for #3: we just bite the bullet and nudge
    >> users helpfully toward using a separate file.

    Pedro> +1

    >> It would work to make every one of these forms set a flag when they are
    Pedro> loaded.

    Pedro> Doesn't that go a bit too far? Other proposals don't depend on modifying
    Pedro> custom-*

If you want to detect whether the user has custom-set-variables or
custom-set-faces in their init file, youʼre going to have to modify
their code. The issue is whether weʼd need to do it for *all* of these
function. Personally I think that would be excessive.

Robert
-- 

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

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

> If you want to detect whether the user has custom-set-variables or
> custom-set-faces in their init file, youʼre going to have to modify
>  their code. The issue is whether weʼd need to do it for *all* of these
>  function. Personally I think that would be excessive.

1+

So the question is whether these calls in the init file come from users
using them *intentionally* in their code or these calls being produced by
Customize, right?

/PA

On Fri, 7 Jan 2022 at 09:43, Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Fri, 7 Jan 2022 07:38:49 +0100, Pedro Andres Aranda Gutierrez <
> paaguti@gmail.com> said:
>
>     >> My preference is for #3: we just bite the bullet and nudge
>     >> users helpfully toward using a separate file.
>
>     Pedro> +1
>
>     >> It would work to make every one of these forms set a flag when they
> are
>     Pedro> loaded.
>
>     Pedro> Doesn't that go a bit too far? Other proposals don't depend on
> modifying
>     Pedro> custom-*
>
> If you want to detect whether the user has custom-set-variables or
> custom-set-faces in their init file, youʼre going to have to modify
> their code. The issue is whether weʼd need to do it for *all* of these
> function. Personally I think that would be excessive.
>
> Robert
> --
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 2135 bytes --]

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

[Drew Adams]

>DA>> My preference is for #3: we just bite the bullet
>DA>> and nudge users helpfully toward using a separate file.
> 
>Pedro> +1
> 
>PL>> It would work to make every one of these forms
>PL>> set a flag when they are loaded.
> 
>Pedro> Doesn't that go a bit too far? Other proposals
>Pedro> don't depend on modifying custom-*
> 
> If you want to detect whether the user has custom-set-variables or
> custom-set-faces in their init file, youʼre going to have to modify
> their code. The issue is whether weʼd need to do it for *all* of these
> function. Personally I think that would be excessive.

I agree.  (And such a flag being set is no
guarantee that the new state whose change it
intends to record remains in effect.)

And none of that is necessary.  The aim should
just be to make more users aware of `custom-file'
and hopefully get more users to make use of it.
Especially new users.

And to give existing users who might have (very)
special needs or strong feelings of resistance
to using a separate file a simple (trivial) way
to continue using only their init file.

Both of those aims are easily realizable.  Just
default `custom-file' to some agreed on location,
and let the few users who want to remain with
just their init file set `custom-file' to it.

All the rest is sound & fury, signifying nothing.

Emacs should just use `custom-file' by default.

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Pedro, you (accidentally, no doubt) mixed up statements by two different writers, which can confuse others or give a false impression.

(I'd again suggest that you use plain text for such messages. Easier to show who's responding to whom, etc., and no incentive to top-post.)

DA>  My preference is for #3: we just bite the bullet and nudge
DA>  users helpfully toward using a separate file.

That was said by me.

+1

PL> It would work to make every one of these forms set a flag when they are loaded.

But that was said by Po Lu, not me.

Doesn't that go a bit too far? Other proposals don't depend on modifying custom-*

[-- Attachment #2: Type: text/html, Size: 4410 bytes --]

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

[Drew Adams]

> >> 7. Suppose a longtime user doesn't read the NEWS
> >>    etc., and _does nothing_.  What happens then?
...
> >> c. If the user then makes some custom* changes
> >>    and saves them, they're saved to the default
> >>    `custom-file' location, _not_ to the init file.
> 
> How about ignoring all of that, and asking the user
> where to save his customizations when he tries to
> save them for the first time?
> 
> That seems like the best solution to me.

You don't say _why_ it seems best to you.
So...why?
___

I think I already replied to your how-about
question, but let me elaborate a bit.

If that were to be done, the agreed-on default
location (e.g. ~/emacs-custom.el) should be
presented explicitly (inserted in minibuffer)
for confirming/editing, as opposed to just
being available with `M-n' (which many users,
especially new ones, aren't even aware of).

Even doing that, I'm guessing that more users
might go with their init file than would be the
case with what I proposed: just default to the
default location.

I see 3 levels mentioned so far:

1. What we have now: default is init file, and
   if a user wants a separate `custom-file' she
   has to know about that possibility and go
   through the steps to set it up explicitly.

   This overwhelmingly favors saving to their
   init file, i.e., no separate `custom-file'.

2. What you propose: essentially no change,
   except to prompt for where to save at the
   first customize save.  (First for all time,
   or first for each Emacs session, or what?)

3. Default to the new default (what I proposed).
   Start saving there.  Call it out in doc & NEWS.

   This favors users changing to a separate
   `custom-file'.  They have to explicitly go to
   the trouble of customizing that var to their
   init file (or perhaps to nil), to use their
   init file.

#2 is intermediate between 1 & 3.  My preference
is for #3: we just bite the bullet and nudge
users helpfully toward using a separate file.

My reason:

#3 is most likely to achieve the desired outcome.
Only users who really want to not have Customize
use a separate file will do so.  And those users
are more likely to be familiar with Emacs Lisp and
know why they really want Customize to tamper with
their init file.

We should especially want to get away from naive
or ignorant users wrt Customize and Elisp getting
into trouble because of mixing user editing with
Customize editing of the same file.

I'm not so worried about those users grumbling
here about having to explicitly set `custom-file'
to their init file (or to nil), to keep Customize
writing to their init file.  In fact, I'm not
worried about them at all.

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

[Po Lu]

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

> You don't say _why_ it seems best to you.

It would change less, which is always desirable to changing more.

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

[Drew Adams]

> > You don't say _why_ it seems best to you.
> 
> It would change less, which is always desirable
> to changing more.

Really?

That means that making _no change ever_ is
best of all.  A bit black-&-white.  Do you
really believe it?

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Fri, Jan 07, 2022 at 04:09:08AM +0000, Drew Adams wrote:
> > > You don't say _why_ it seems best to you.
> > 
> > It would change less, which is always desirable
> > to changing more.
> 
> Really?
> 
> That means that making _no change ever_ is
> best of all.  A bit black-&-white.  Do you
> really believe it?

You shouldn't strip all context before making
such an assertion: you risk nonsense, then.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Drew Adams]

> > > > You don't say _why_ it seems best to you.
> > >
> > > It would change less, which is always desirable
> > > to changing more.
> >
> > Really?
> >
> > That means that making _no change ever_ is
> > best of all.  A bit black-&-white.  Do you
> > really believe it?
> 
> You shouldn't strip all context before making
> such an assertion: you risk nonsense, then.

What additional context do you think is relevant
for that statement?  An empty seems-best-to-me
followed by, as only reason, just 
changing-less-is-always-better-than-changing-more.

Less is "always" better than more means zero
is best, no?

What context do you think I stripped?  Your
statement makes it sound like I distorted what
was said, by omitting something relevant.  I
don't think I did.  Please point to what else
was said, that you think indicates a switch in
meaning by me.

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Below.

> 1. Whether to load `custom-file' automatically after the init file is an open question.

Agree, but it would be a nice place, right?

Yes, that's why I proposed it.

I meant that the idea of automatically loading `custom-file' is open, and the general proposition doesn't depend strongly on it.

> In addition, we should add a new switch that suppresses (only) loading of the `custom-file'

Don't get that one

Same reason as for the variable that would do that. You can set or bind the variable in code, but you might just want to start up Emacs without your `custom-file' sometime.

[-- Attachment #2: Type: text/html, Size: 4278 bytes --]

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

[Drew Adams]

> Let me try to put it another way: as I envisage the whole process
>
> 1.- On startup:
> a) Get the startup file from [ .emacs, .emacs.d/init.el, .config/emacs/init.el ] or whatever set of files we decide and load it
> b) if custom-file is not nil and wasn't already loaded, load custom-file. If is was already loaded, maybe tell the user (???)
>
> 2.- When saving the customisations
> if custom-file is not nil, save them there else save them in the startup file whatever it is
>
> AFAIK, the only new thing is to include 1b) in the emacs code, because 1a) and 2) are already in the code (it's how emacs behaves today, right?)
>
> So someone not defining custom-file would not see anything changing (long-standing behaviour respected)

No.  That's not what I've suggested, at least.

Not defining `custom-file' _would_ change the
behavior.  Setting `custom-file' to your init
file would keep the current default behavior of
Customize using your init file.  That's in fact
what we have now, implicitly: `custom-file' =
init file.  The aim is to make it different,
by default.

I suggested that, by default, Customize would
write to `custom-file'.  Just like a bookmark
file, that variable would have a default value
(different from the default for your init file).

So doing nothing - not changing the default
value of `custom-file' - would mean that
Customize would write to that default file
location.

IOW, we would treat `custom-file' like we treat
bookmark files, desktop files, etc.  We would
not, by default, have Customize write its config
code to your init file.  (You would still be
_able_ to have Customize write to your init file,
if you like; that just wouldn't happen by default.)
___

I also suggested that we add a variable that you
can set (including conditionally) if you want to
prevent Emacs from loading `custom-file'.

The use of that variable is independent of the
question of where Customize saves info: it would
save to your `custom-file', whether that's a
separate file from your init file (the default
case) or not (you've set it to your init file).
The variable would exist just to give you a way
to prevent loading `custom-file', if you needed
to do that in some context.

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

[Drew Adams]

> What I propose is to agree on a default value
> for custom-file that could potentially be
> changed by the user in  init.el or .emacs
> and do the (load custom-file 'noerror) after
> loading the init file as a default behaviour for Emacs

Yes, I already proposed exactly that.

However, wrt that last part, about "default
behavior":

As I said earlier, `custom-file' should be
loaded by default just after the init file,
but _only_ if it has not already been loaded.

Users need to be able to control when and
where `custom-file' gets loaded (which
includes the possibility of doing so more
than once).  There should be no automatic
loading of it if it's already been loaded.

In addition, we should have an option that
can prevent such automatic loading altogether.

(And of course you should be able to just
set `custom-file' to your init file, if
you want to keep the longstanding behavior).