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: 24237@debbugs.gnu.org
Subject: bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning
Date: Sat, 12 Dec 2020 12:45:17 -0800 (PST)	[thread overview]
Message-ID: <70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> (raw)
In-Reply-To: <87v9d67ox6.fsf@gnus.org>

> > The doc for :filter says this about the FILTER-FN:
> >
> >    Emacs can call this function at any time that it does redisplay or
> >    operates on menu data structures, so you should write it so it can
> >    safely be called at any time.
> >
> > Is this true in general, or only when the extended menu item is put on a
> > menu?
> >
> > A common idiom is to make 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.
> >
> > I'm guessing that in such a case this doc paragraph does not apply.  If
> > this guess is correct then please correct the paragraph, so that it says
> > something like "If an extended menu item that uses :filter is placed on
> > a menu then Emacs can call FILTER-FN when...".
> 
> I think making the documentation more specific here serves no purpose.
> The statement as is should be true: You should always write these filter
> functions as if they are called at any time.
> 
> > Also, is it really the case that FILTER-FN can be called anytime Emacs
> > does redisplay?  Shouldn't the doc say only that it can be called
> > anytime Emacs "operates on menu data structures"?  Does it get called by
> > redisplay other than when redisplay operates on menu data structures?
> > In the case mentioned above (binding to a keyboard key), would FILTER-FN
> > ever be called during redisplay?  I'm guessing that it would not.
> 
> I don't see why we should specify that at all.

The Elisp manual is not only for readers reading as
end users.  This information is needed by people
writing Lisp code that uses extended menu items.

And as the bug report points out, a very different
use case does not involve use of a menu at all.

Now perhaps Emacs should provide some alternative
to using an extended menu item, specifically for
this very different use case.  But until and unless
it does that, the behavior for this particular use
case should be covered in the doc.  In particular,
if the caveat that is written does NOT apply for
this use case, then that should be pointed out.

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.

This is not some obscure detail.  It goes to the
heart of the behavior and use of extended menu
items.  If you instead want to create a new Lisp
construct to achieve such filtering for non-menu
uses, great - that would take care of this lack in
a different, equally (maybe even more) acceptable
way.

Just ignoring this isn't TRT.  I, for one, would
like to know what the case really is wrt the
display engine problem when you use an extended
menu item without a menu.





  reply	other threads:[~2020-12-12 20:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15 18:06 bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning Drew Adams
2020-12-12 20:24 ` Lars Ingebrigtsen
2020-12-12 20:45   ` Drew Adams [this message]
2020-12-13 15:07     ` 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>
2020-12-13 17:24       ` Drew Adams
2020-12-13 17:56         ` 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
     [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>
     [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

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=70cc884d-4f32-4a2e-b3f5-181709f2ca29@default \
    --to=drew.adams@oracle.com \
    --cc=24237@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.