GNU bug report logs - #54977
29.0.50; Customising eshell-modules-list means you won't get new default entries

Previous Next

To reply to this bug, email your comments to 54977 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Customising eshell-modules-list means you won't get new
 default entries
Date: Sat, 16 Apr 2022 13:55:22 -0700

Hello,

eshell-modules-list has two kinds of entries: truly optional modules
that the user has chosen to enable, and modules that are enabled by
default, and that the user is likely to want to remove from the list
only in unusual circumstances.

Suppose that you use the customisation interface to enable the
eshell-rebind module, and save the result in your init.  Now upstream
Emacs gains a new on-by-default module, e.g. the recently added
em-extpipe.  While everyone who hasn't customised eshell-modules-list
gets the new module automatically, you'll have to customise the variable
again, and you can't even just tick a box to add it, as with the other
truly optional modules, but must manually insert it at the end of the
list.  This is no good.

How about using two separate defcustoms for these two kinds of entry?

-- 
Sean Whitton

Message #8 received at 54977 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54977 <at> debbugs.gnu.org
Subject: Re: bug#54977: 29.0.50; Customising eshell-modules-list means you
 won't get new default entries
Date: Sat, 16 Apr 2022 22:01:19 -0700

On 4/16/2022 1:55 PM, Sean Whitton wrote:
> Suppose that you use the customisation interface to enable the
> eshell-rebind module, and save the result in your init.  Now upstream
> Emacs gains a new on-by-default module, e.g. the recently added
> em-extpipe.  While everyone who hasn't customised eshell-modules-list
> gets the new module automatically, you'll have to customise the variable
> again, and you can't even just tick a box to add it, as with the other
> truly optional modules, but must manually insert it at the end of the
> list.  This is no good.

Generally I resolve this in my config by using a combination of 
`add-to-list' and `delete' to manually customize lists like this. Maybe 
it would be good to provide something like that for users of the 
Customize interface as well? Then any defcustom that takes a list could 
either be customized to have an exact set of elements (as it is today), 
or to have "the default, but with FOO added and BAR removed".

Message #11 received at 54977 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>, 54977 <at> debbugs.gnu.org
Subject: Re: bug#54977: 29.0.50; Customising eshell-modules-list means you
 won't get new default entries
Date: Sat, 16 Apr 2022 22:03:18 -0700

Hello,

On Sat 16 Apr 2022 at 10:01pm -07, Jim Porter wrote:

> On 4/16/2022 1:55 PM, Sean Whitton wrote:
>> Suppose that you use the customisation interface to enable the
>> eshell-rebind module, and save the result in your init.  Now upstream
>> Emacs gains a new on-by-default module, e.g. the recently added
>> em-extpipe.  While everyone who hasn't customised eshell-modules-list
>> gets the new module automatically, you'll have to customise the variable
>> again, and you can't even just tick a box to add it, as with the other
>> truly optional modules, but must manually insert it at the end of the
>> list.  This is no good.
>
> Generally I resolve this in my config by using a combination of
> `add-to-list' and `delete' to manually customize lists like this.

Right, me too.

> Maybe it would be good to provide something like that for users of the
> Customize interface as well? Then any defcustom that takes a list
> could either be customized to have an exact set of elements (as it is
> today), or to have "the default, but with FOO added and BAR removed".

That might be a good enhancement, but I think the Eshell case is a bit
simpler -- using two defcustoms mostly solves it.

-- 
Sean Whitton

Message #14 received at 54977 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 54977 <at> debbugs.gnu.org
Subject: Re: bug#54977: 29.0.50;
 Customising eshell-modules-list means you won't get new default
 entries
Date: Sun, 17 Apr 2022 08:28:08 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Sat, 16 Apr 2022 13:55:22 -0700
> 
> Suppose that you use the customisation interface to enable the
> eshell-rebind module, and save the result in your init.  Now upstream
> Emacs gains a new on-by-default module, e.g. the recently added
> em-extpipe.  While everyone who hasn't customised eshell-modules-list
> gets the new module automatically, you'll have to customise the variable
> again, and you can't even just tick a box to add it, as with the other
> truly optional modules, but must manually insert it at the end of the
> list.  This is no good.
> 
> How about using two separate defcustoms for these two kinds of entry?

One other idea is to have the default modules not mentioned
explicitly, but instead have some kind of placeholder which stands for
all the default modules.  Similar to some path variables that treat an
empty or nil list member as standing for the default value.

Message #17 received at 54977 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54977 <at> debbugs.gnu.org
Subject: Re: bug#54977: 29.0.50; Customising eshell-modules-list means you
 won't get new default entries
Date: Sat, 16 Apr 2022 22:50:10 -0700

On 4/16/2022 10:03 PM, Sean Whitton wrote:
> On Sat 16 Apr 2022 at 10:01pm -07, Jim Porter wrote:
> 
>> Maybe it would be good to provide something like that for users of the
>> Customize interface as well? Then any defcustom that takes a list
>> could either be customized to have an exact set of elements (as it is
>> today), or to have "the default, but with FOO added and BAR removed".
> 
> That might be a good enhancement, but I think the Eshell case is a bit
> simpler -- using two defcustoms mostly solves it.

True, for this case it might be simpler to use two defcustoms, 
especially if it turns out that adding the necessary bits to the 
Customize interface proves difficult. I've never looked at the Customize 
internals, so I'm not sure how hard that would be (though I'm sure it's 
considerably harder than adding a defcustom to Eshell).

Still, enhancing Customize would also (probably) solve this issue for 
`erc-modules' and `org-modules', and I'm sure lots of third-party 
packages would benefit too.

Message #20 received at 54977 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54977 <at> debbugs.gnu.org
Subject: Re: bug#54977: 29.0.50; Customising eshell-modules-list means you
 won't get new default entries
Date: Sun, 17 Apr 2022 22:07:48 -0700

Hello,

On Sun 17 Apr 2022 at 08:28am +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Sat, 16 Apr 2022 13:55:22 -0700
>>
>> Suppose that you use the customisation interface to enable the
>> eshell-rebind module, and save the result in your init.  Now upstream
>> Emacs gains a new on-by-default module, e.g. the recently added
>> em-extpipe.  While everyone who hasn't customised eshell-modules-list
>> gets the new module automatically, you'll have to customise the variable
>> again, and you can't even just tick a box to add it, as with the other
>> truly optional modules, but must manually insert it at the end of the
>> list.  This is no good.
>>
>> How about using two separate defcustoms for these two kinds of entry?
>
> One other idea is to have the default modules not mentioned
> explicitly, but instead have some kind of placeholder which stands for
> all the default modules.  Similar to some path variables that treat an
> empty or nil list member as standing for the default value.

That would be nicer than two defcustoms, I think.  Possibly it could be
an uber-module which just pulls in the defaults.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.