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

[Jim Porter <jporterbugs@gmail.com>]

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.