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

From: Drew Adams <[email-masked]>
Date: Sat, 19 Dec 2020 11:35:45 -0800 (PST)

> > > > > >  "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."
> > >
> > > If this is never placed on the menu bar or on any pop-down menu, then
> > > what the manual says is not relevant, because redisplay only considers
> > > the menus that need to be displayed.
> >
> > 1. The manual's description of :filter is entirely
> > relevant to this use case - _except_ for that last
> > paragraph, which apparently erroneously assumes that
> > the only possible use of an extended menu item with
> > :filter is in a menu.
> 
> Since that last paragraph explicitly talks about displaying or acting
> on menus, I see no reason to change anything there.
> 
> >    a. You can bind an extended menu item that uses
> >       :filter to a keyboard key, to give it a
> >       dynamic binding (explaining what that means
> >       with an example).
> 
> IMO this is a kludge that we don't need to document.

It is indeed a kludge/workaround/hack.

It is also quite useful.  If you refuse to elevate it
to doc-worthiness, then please change this bug to an
enhancement request to provide the same feature
_without_ having to use `menu-item' with :filter.

Otherwise, I will I guess submit such an enhancement
request.  Elisp users shouldn't have to resort to an
undocumented kludge to get this useful behavior.

> > More generally, `menu-item' is not just about menus
> > and menu items.  This is not obvious.  And in
> > particular, it's not obvious that you can make good
> > use of :filter with a keyboard key.
> 
> menu-item is about menus, as its name says.  That it can be used for
> other purposes is an implementation detail.
> 
> And with that, I'm closing this bug report.

Ta da.