bug#52293: [External] : bug#52293: 29.0.50; [PATCH v3] Prevent further cases of duplicated separators in context menus

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

> > I said only that someone (for whatever reasons) might
> > want to provide or allow consecutive separators, and
> > that that should be possible.  That's all.  And I
> > said that programmers can anyway make separators,
> > like other menu items, conditional (e.g. invisible).
> 
> I was referring to your following words:
> 
>   Why should we even provide such removal?  If
>   someone doesn't want it they won't code it.
>   That's all.
> 
> But the problem is that it's not easy not to add separators that
> become duplicated when no menu items are added to submenus.

Please read the rest of what I wrote.

I specifically pointed out that some conditional menu
items might not appear, resulting in consecutive
separators. And that such a possibility might, or
might not, be what someone wants.

And I mentioned the possibility of making separators
themselves conditional.  You can programmatically
control what happens dynamically.

Of course, if you're only trying to insert some item
into an existing menu, then do more than just insert
the item.  At the limit, you might even need to
reprogram the menu, or at least some part of it
beyond that new item.

And I specifically mentioned the problem of having
two separators end up being consecutive because of a
dynamic situation - even just conditional insertion
or removal of some items.  I was the first one (maybe
the only one?) to have mentioned that possibility.

There are multiple ways in which a menu, including its
separators, can be "dynamic".  I'm well aware of that,
as I think you know.  

> > I've elsewhere expressed my displeasure in seeing
> > context menus implemented in the way Emacs is doing
> > that, but that was ignored.  (I use my own approach
> > to providing mouse-3 context menus, which allows the
> > standard, longstanding Emacs mouse-3 behavior at the
> > same time.)
> 
> Interesting.  Could you please describe your approach.

I already did, including in the thread where your
context-menu was proposed.  I've described it more
than once.  If you're truly interested and haven't
paid any mind to it before, you can find a description
here:

https://www.emacswiki.org/emacs/Mouse3

And you can find the code here:

https://www.emacswiki.org/emacs/download/mouse3.el

In general, I'm in favor of:

1. Combining these two advantages:

   . Allowing for a `mouse-3' context menu
   . Emacs's longstanding `mouse-3' actions

   Users shouldn't have to sacrifice one to have
   the other.

2. Letting users easily configure such menus, for
   whatever contexts they want.

3. Letting user code do the same (e.g., dynamic
   control).

`mouse3.el' is a simple start, but it already goes
a long way toward all of that.  My impression, from
the discussion about your context-menu approach, is
that it's much less open to user and programmatic
control, and it doesn't enable the traditional
`mouse-3' behavior at the same time.

The traditional `mouse-3' behavior (including
deleting) is a strong plus, IMHO.  Many Emacs users,
even those who use a mouse heavily, might not even
be aware of it, which is too bad, IMO.  I wonder
how many are even aware of multiclicking `mouse-1'.
Again, too bad, if they're not.

Instead of throwing the traditional Emacs `mouse-3'
under the bus, we should be running it up the flag
pole and shining a light on it.

That your new context-menu feature has the effect
of throwing Emacs's traditional `mouse-3' under the
bus is just a guess of mine.  Mille excuses, if you
do in fact allow both the traditional behavior and
a context menu at the same time.

Don't ask me to prove that your approach hard-codes
things in such a way.  That was my impression when
reading your descriptions and the arguments for the
approach.  I don't claim to be an expert on what
resulted.  As an eternal optimist, I can hope that
it isn't as closed, narrow, and predefined as what
my impression of it suggests.