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

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

[Sean Whitton]

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

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

[Jim Porter]

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

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

[Sean Whitton]

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

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

[Jim Porter]

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.

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

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@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.

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

[Sean Whitton]

Hello,

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

>> From: Sean Whitton <spwhitton@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