all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 44454@debbugs.gnu.org
Subject: 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)	[thread overview]
Message-ID: <ea9fd587-4403-41b1-9d5e-ee7e89fc0269@default> (raw)
In-Reply-To: <87v9eejz7m.fsf@gnus.org>

> :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?".)





  reply	other threads:[~2020-11-09 16:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-04 21:34 bug#44454: 26.3; Enhancement request: let :help in menus take a FORM arg, i.e., be eval'd Drew Adams
2020-11-09 16:02 ` Lars Ingebrigtsen
2020-11-09 16:26   ` Drew Adams [this message]
2020-11-10 13:57     ` Lars Ingebrigtsen
2020-11-10 17:27       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea9fd587-4403-41b1-9d5e-ee7e89fc0269@default \
    --to=drew.adams@oracle.com \
    --cc=44454@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.