all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.