bug#24237: 24.5; (elisp)`Extended Menu Items', :filter warning

[Drew Adams <drew.adams@oracle.com>]

> > 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.