* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
@ 2022-04-16 20:55 Sean Whitton
2022-04-17 5:01 ` Jim Porter
2022-04-17 5:28 ` Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Sean Whitton @ 2022-04-16 20:55 UTC (permalink / raw)
To: 54977
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
2022-04-16 20:55 bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries Sean Whitton
@ 2022-04-17 5:01 ` Jim Porter
2022-04-17 5:03 ` Sean Whitton
2022-04-17 5:28 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Jim Porter @ 2022-04-17 5:01 UTC (permalink / raw)
To: Sean Whitton, 54977
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".
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
2022-04-17 5:01 ` Jim Porter
@ 2022-04-17 5:03 ` Sean Whitton
2022-04-17 5:50 ` Jim Porter
0 siblings, 1 reply; 6+ messages in thread
From: Sean Whitton @ 2022-04-17 5:03 UTC (permalink / raw)
To: Jim Porter, 54977
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
2022-04-16 20:55 bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries Sean Whitton
2022-04-17 5:01 ` Jim Porter
@ 2022-04-17 5:28 ` Eli Zaretskii
2022-04-18 5:07 ` Sean Whitton
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-04-17 5:28 UTC (permalink / raw)
To: Sean Whitton; +Cc: 54977
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
2022-04-17 5:03 ` Sean Whitton
@ 2022-04-17 5:50 ` Jim Porter
0 siblings, 0 replies; 6+ messages in thread
From: Jim Porter @ 2022-04-17 5:50 UTC (permalink / raw)
To: Sean Whitton, 54977
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries
2022-04-17 5:28 ` Eli Zaretskii
@ 2022-04-18 5:07 ` Sean Whitton
0 siblings, 0 replies; 6+ messages in thread
From: Sean Whitton @ 2022-04-18 5:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 54977
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-04-18 5:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-16 20:55 bug#54977: 29.0.50; Customising eshell-modules-list means you won't get new default entries Sean Whitton
2022-04-17 5:01 ` Jim Porter
2022-04-17 5:03 ` Sean Whitton
2022-04-17 5:50 ` Jim Porter
2022-04-17 5:28 ` Eli Zaretskii
2022-04-18 5:07 ` Sean Whitton
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).