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

[Jim Porter <jporterbugs@gmail.com>]

On 12/12/2021 1:00 PM, Drew Adams wrote:
> Caveat: I'm not following this thread.  FWIW:
> 
> 1. In my code I have _lots_ of menu separators that
> are apparently in what you call the old naming
> convention.

That's fine. I'd prefer we *not* update old menu separators, since 
that's a compatibility break. The only exception would be for existing 
context menu separators, since they're pretty new anyway, so the chance 
of any code relying on the old context menu names is low.

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

> 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 "--"))

That's not documented though, and I'm not sure what promises we should 
make here. 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.

It may be possible for context menu functions to be more careful about 
the insertion of separators so that duplicates never crop up in the 
first place. 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.