From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: larsi@gnus.org, 24237@debbugs.gnu.org
Subject: bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning
Date: Sun, 13 Dec 2020 09:24:52 -0800 (PST) [thread overview]
Message-ID: <e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default> (raw)
In-Reply-To: <<83blexeod5.fsf@gnu.org>>
> > IF the guess is correct that this caveat does NOT
> > in fact apply to this use case then no, it is
> > NOT the case that "You should always write these
> > filter functions as if they are called at any time."
> > If that guess is correct then what you say as the
> > reason for not fixing this doc bug simply isn't
> > relevant.
>
> I don't think I understand what "this case" is,
As was said in the original bug report and has
been repeated in the thread, this case is the
"use of a `menu-item' construct with a :filter
to create a conditional _keyboard_ key binding.
In such a case, the `menu-item' construct is not
a real menu item - it is not placed on any menu."
> but in general menu functions
Define "menu function", please. Does this apply
to the case being discussed: an extended menu
item that's bound only to a keyboard key, i.e.,
that's not used in any menu?
> could be called whenever the display engine needs to
> recalculate the contents and the dimensions of the menu, and that
> could basically be every redisplay cycle, depending on circumstances.
See above. There's no menu involved in the case
being discussed (at least none that's visible to
users, AFAIK). So there should be no need or
possibility of recalculating menu contents and
dimensions.
This is (only) about the hack/idiom of using an
extended menu item for a keyboard key binding
(only). And the use case for doing that is to
take advantage of the :filter handling.
I don't know where/when the :filter handling is
done. Perhaps it is done as an integral part of
redisplay. If that's the case, does it mean
that the warning in the doc is applicable in
this case?
If it is thus applicable in this case, does it
need to be? IOW, could handling of :filter be
separated out, at least in the case where no menu
is involved?
Again, though, I'm not really arguing that using
a `menu-item' just to get :filter behavior for a
keyboard key binding is the best approach.
The point is that currently it is the _only_
approach, hence the idiom. If Emacs provides a
more direct way to do this, that's uncoupled from
`menu-item' and its redisplay handling, great.
Lacking that, this bug is about having the doc
address the use case of the idiom.
next parent reply other threads:[~2020-12-13 17:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>
[not found] ` <<87v9d67ox6.fsf@gnus.org>
[not found] ` <<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>
[not found] ` <<83blexeod5.fsf@gnu.org>
2020-12-13 17:24 ` Drew Adams [this message]
2020-12-13 17:56 ` bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning Eli Zaretskii
[not found] <<<<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>
[not found] ` <<<<<87v9d67ox6.fsf@gnus.org>
[not found] ` <<<<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>
[not found] ` <<<<<83blexeod5.fsf@gnu.org>
[not found] ` <<<<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default>
[not found] ` <<<<83v9d5d1yd.fsf@gnu.org>
[not found] ` <<<846fcdf8-9b51-4246-8200-b067e7006e24@default>
[not found] ` <<<83y2hut6m7.fsf@gnu.org>
[not found] ` <<d15a8746-eb78-44b5-a4d6-af2285969b76@default>
[not found] ` <<838s9ttxkk.fsf@gnu.org>
2020-12-19 19:35 ` Drew Adams
2020-12-20 0:05 ` Stefan Kangas
2020-12-20 1:23 ` Drew Adams
[not found] <<<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>
[not found] ` <<<<87v9d67ox6.fsf@gnus.org>
[not found] ` <<<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>
[not found] ` <<<<83blexeod5.fsf@gnu.org>
[not found] ` <<<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default>
[not found] ` <<<83v9d5d1yd.fsf@gnu.org>
[not found] ` <<846fcdf8-9b51-4246-8200-b067e7006e24@default>
[not found] ` <<83y2hut6m7.fsf@gnu.org>
2020-12-19 18:54 ` Drew Adams
2020-12-19 19:17 ` Eli Zaretskii
[not found] <<<6c4f5089-43fa-4ca1-a656-1ec1684df960@default>
[not found] ` <<<87v9d67ox6.fsf@gnus.org>
[not found] ` <<<70cc884d-4f32-4a2e-b3f5-181709f2ca29@default>
[not found] ` <<<83blexeod5.fsf@gnu.org>
[not found] ` <<e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default>
[not found] ` <<83v9d5d1yd.fsf@gnu.org>
2020-12-13 19:52 ` Drew Adams
2020-12-19 10:47 ` Eli Zaretskii
2016-08-15 18:06 Drew Adams
2020-12-12 20:24 ` Lars Ingebrigtsen
2020-12-12 20:45 ` Drew Adams
2020-12-13 15:07 ` Eli Zaretskii
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=e70746fb-1e56-4115-9fb8-1896c4e8b8d3@default \
--to=drew.adams@oracle.com \
--cc=24237@debbugs.gnu.org \
--cc=eliz@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.