bug#52286: 28.0.90; [PATCH] Be consistent in naming of separators in context menu

[Jim Porter]

On 12/5/2021 2:39 AM, Eli Zaretskii wrote:
> > Cc: 52286@debbugs.gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> > Date: Sat, 4 Dec 2021 23:44:07 -0800
> >
> > > The first pretest of Emacs 28 is already out, so this problem is
> > > already with us, isn't it?
> >
> > If it's too late to change this, that's ok. I just noticed it while
> > working on the patch for bug#52237 and figured it'd be good to file a
> > bug about it while there's still a non-zero chance it could be changed.
> > It's a pretty minor issue, so I don't really mind if this gets closed as
> > wontfix.
> >
> > If this change *is* ok to merge, I'll happily update the ELisp manual
> > with a brief summary of the convention before it gets merged.
>
> I'd like to hear opinions of others.  Meanwhile, having the proposed
> convention spelled out in the manual would be good to make sure we are
> all on the same page regarding the issue.

Ok, I'll start working on some documentation. Do you have any suggestion 
on where it should go, or how general I should make it? (I could 
document the convention specifically for separators, or I could try to 
write up a more general guideline that could apply to any symbol name.)

> As for the issue itself: cannot we detect the separators in some more
> robust way, one that doesn't depend on how they are named?  And if
> that's not feasible, perhaps allow anything that has "separator" in
> its name to be considered a separator?

We can detect whether an item is a separator pretty easily without this 
change. However, context menu functions use specific separators to 
determine where exactly it should put new menu items. For example, 
`elisp-context-menu' adds menu items after `middle-separator':

    (define-key-after menu [elisp-separator] menu-bar-separator
      'middle-separator)

(Later in the function, it adds the actual menu items after the 
newly-added `elisp-separator'.)

The only issue (though it's a small one) is that some of the separator 
names added to the context menu by default are named `FOO-separator' and 
others are named `separator-FOO'. I thought it might be hard to remember 
which was which without double-checking, so my patch converts all of the 
names to use the `FOO-separator' format.

Of course, as Juri Linkov's message points out, many already-existing 
separators use both naming schemes, and it's too late to change those. 
Since the context menu is new, I thought it would be worth converting to 
a consistent naming scheme if it's not too late.

Still, this is a *very* small problem. I'm not sure third party packages 
would want to insert context menu items after, say, `separator-undo'; a 
user might customize `context-menu-functions' so that their menu doesn't 
even *have* a separator of that name. In practice, it's possible almost 
no one will even notice the different naming conventions.