bug#43308: 28.0.50; Improvements to Edit->Search menu

[Drew Adams]

> >> Why no keybindings are shown for nonincremental menu items?
> >> They still have keybindings, e.g. nonincremental forward search
> >> can be started with 'C-s RET', nonincremental backward search
> >> with 'C-r RET', nonincremental regexp search 'C-M-s RET', etc.
> >
> > I suppose I could add some explicitly, with :keys.
> > That makes sense.  Unfortunately, none show up
> > automatically.  It would be good to somehow fix that.
> 
> How about the following patch?

It doesn't fix the nonautomatic display of keys, does it?

> BTW, why "Search Tagged Files..." and "Continue Tags Search" have
> no keybindings?

Because they have no keyboard key bindings.  Or was
that your question?  Did `tags-search' ever have a
default keyboard binding?  For `Continue Tags Search'
I think the reason was that when Emacs moved to xref
it dropped the `M-,' key binding for that command
(`tags-loop-continue').  (I wasn't in favor of that.)

> Another problem is that selecting "Continue Tags Search"
> signals the error:
> 
> emacs -Q
> Select "Edit" -> "Search" -> "Continue Tags Search"
> 
> Lisp error: (wrong-type-argument commandp fileloop-continue)

I don't see that with emacs -Q, loading menu-bar+.el,
and using that item in the Search menu (which is not
under Edit).  Dunno why.  I see just this error message:
"No operation in progress", which makes sense.

> I think "Continue Tags Search" should be disabled when it has no effect.

I've done that now, in menu-bar+.el.  I use this, but
perhaps someone can let me know if it's not the right,
or best, condition to use.  (I use condition-case, not
ignore-errors, for compatibility with older Emacs.)

:enable (not (condition-case nil
                 (tags-loop-eval tags-loop-scan)
               (error t)))