GNU bug report logs - #44454
26.3; Enhancement request: let :help in menus take a FORM arg, i.e., be eval'd

Previous Next

To reply to this bug, email your comments to 44454 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: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; Enhancement request: let :help in menus take a FORM arg, i.e.,
 be eval'd
Date: Wed, 4 Nov 2020 13:34:17 -0800 (PST)

Enhancement request:

In extended menu items and the easy-menu stuff, the value of :help must
be a literal string.  Consider perhaps letting it be a FORM, i.e., have
it be evaluated, like :visible and :enable.

It would be backward compatible.  If you use a sexp now the result is
that you just don't get any help echo.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 44454 <at> debbugs.gnu.org
Subject: Re: bug#44454: 26.3; Enhancement request: let :help in menus take a
 FORM arg, i.e., be eval'd
Date: Mon, 09 Nov 2020 17:02:05 +0100

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

> Enhancement request:
>
> In extended menu items and the easy-menu stuff, the value of :help must
> be a literal string.  Consider perhaps letting it be a FORM, i.e., have
> it be evaluated, like :visible and :enable.
>
> It would be backward compatible.  If you use a sexp now the result is
> that you just don't get any help echo.

:visible and :enable have to allow forms as values.  What's the use case
for forms for :help elements?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44454 <at> debbugs.gnu.org
Subject: RE: bug#44454: 26.3; Enhancement request: let :help in menus take a
 FORM arg, i.e., be eval'd
Date: Mon, 9 Nov 2020 08:26:25 -0800 (PST)

> :visible and :enable have to allow forms as values.  What's the use case
> for forms for :help elements?

Same purpose as :visible and :enable:

To be able to change the help echo depending on the
current context.  The command for the menu item can
have different behaviors, depending on the context.
The help echo could let you know about this.

For example, the help echo for a command that cycles
some setting/value could let you know what the
current value is or what the next one will be if you
choose that menu item - let you know what will happen.

Just as :visible and :enable let you know whether a
command is currently available, so could :help let
you know what its behavior will be.

I have exactly this situation in my `Info' submenu
`Toggle/Cycle'.  For the toggle commands there, the
toggle checkmark suffices to let you know the current
(and hence the next) state/value.  For cycle commands
there's no way to know, except by actually cycling.
___

(Dare I ask if there's some reason that :help cannot
or shouldn't accept a FORM to evaluate?  Will I be
denounced again for including a question "Why not?"?
You have the "why" above.  But I'd anyway like to know
what it is, if there's a good answer to "why not?".)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 44454 <at> debbugs.gnu.org
Subject: Re: bug#44454: 26.3; Enhancement request: let :help in menus take a
 FORM arg, i.e., be eval'd
Date: Tue, 10 Nov 2020 14:57:35 +0100

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

> I have exactly this situation in my `Info' submenu
> `Toggle/Cycle'.  For the toggle commands there, the
> toggle checkmark suffices to let you know the current
> (and hence the next) state/value.  For cycle commands
> there's no way to know, except by actually cycling.

Makes sense to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44454 <at> debbugs.gnu.org
Subject: RE: bug#44454: 26.3; Enhancement request: let :help in menus take a
 FORM arg, i.e., be eval'd
Date: Tue, 10 Nov 2020 09:27:03 -0800 (PST)

> > I have exactly this situation in my `Info' submenu
> > `Toggle/Cycle'.  For the toggle commands there, the
> > toggle checkmark suffices to let you know the current
> > (and hence the next) state/value.  For cycle commands
> > there's no way to know, except by actually cycling.
> 
> Makes sense to me.

BTW, another way to consider this is to look for
similarity with `help-echo'.  Not that the two
need to be similar, but that the use cases are
the same or similar for the value to be evaluated
rather than being restricted to a literal string.

(Yes, there's nothing special about the evaluation
for contexts where `help-echo' is used - it has
nothing, per se, to do with `help-echo', which is
just a property.  And yes, for menus, using a
FORM that gets evaluated (by the display engine,
IIUC) is a bit special.  But the use cases - the
usefulness for users, is of the same order.)

Previous Next

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