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

> > 3. I think there's zero need for any naming
> >     convention for menu-item names, whether
> >     separators or other.
> 
> The goal was to make it easier to remember the names of the separators
> if you wanted to add a new item after a particular separator that had
> already been added. It's easier to remember if they're all
> `foo-separator' instead of a mix of styles.

Why does anyone need to _remember_ such names?
What's the use case for remembering?

> > 4. As I stated early on in this thread, I think
> >     it's misguided to prevent the use of duplicate
> >     separators.  If someone wants such duplicates
> >     for some reason (and there can be any number
> >     of reasons), let them be.  And if someone, for
> >     some reason, wants to prevent such duplicates
> >     they can do so easily enough, manually or by
> >     code.
> 
> Technically, this is already possible by using extended-format menu
> items. Only simple separators are de-duplicated. So this would be
> de-duplicated:
> 
>    (define-key menu [foo-separator] '("--"))
> 
> But this wouldn't:
> 
>    (define-key menu [bar-separator] '(menu-item "--"))

Deduplication?  We're not talking about removing
exact duplicates are we?  I thought this was about
removing consecutive separators, leaving only one.
This involves no duplicate menu items:

  (define-key menu [separator-1] '("--"))
  (define-key menu [separator-2] '("--"))

More importantly, I didn't know this was about
removing any ordinary `define-key' bindings.
I really hope it's not.  I thought this was only
for Juri's new context menus.

If we're now automatically removing consecutive
separators coded with `define-key' then count me
as one user who's definitely against that.

What can possibly be the reason for imposing that
kind of meddling with someone's code, preventing
Emacs from showing consecutive separators (without
having to add superfluous `menu-item's)? 

> That's not documented though, and I'm not sure 
> what promises we should make here. 

The only promise I, as one user, am interested
in hearing is not to neuter code that creates
consecutive menu separators.

> It might be better to have a more-explicit way of opting into
> de-duplication, but I'm not sure what that would be off-hand.

Why should we even provide such removal?  If
someone doesn't want it they won't code it.
That's all.

And if it appears because some menu items that
might otherwise be present between 2 separators
aren't displayed (e.g. because of :visible),
then it's up to the coder to deal with that.
Maybe she wants to show that there are missing
menu items, by using consecutive separators.

I don't claim to know what you're really doing,
but IIUC, this is overoverengineering.

If you instead just provided a coding way for
someone to indicate, at some particular part of
a menu, that a separator shouldn't be shown if
it directly follows another separator, then just
do that.

(And that should already be possible, using
:invisible for the separator itself.)

> It may be possible for context menu functions

Is this all only about _context_ menus or not?

If it is, I don't care a lot.  But if it's about
menus generally, then what I think I'm hearing
isn't something I'm in favor of.  But again,
just one opinion.

> to be more careful about
> the insertion of separators so that duplicates never crop up in the
> first place.

Why do you care if they "crop up"?

> However, that would take a bit of experimentation, and I'm
> not sure of all the pros and cons of a solution like that. Maybe Juri
> has some thoughts on this though.