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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 52286@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sun, 5 Dec 2021 18:09:22 -0800
> 
> >> 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.)

I think the most natural place is where we describe how to construct
menus.

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

If this is a private convention of elisp-mode, we don't have to codify
it.

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

So maybe instead of conventions we should have recommendations, with
explanation why following that could be useful in some situation.
Then let Lisp programmers decide what they want.