GNU bug report logs - #52286
28.0.90; [PATCH] Be consistent in naming of separators in context menu

Previous Next

Full log

Message #23 received at 52286 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52286 <at> debbugs.gnu.org
Subject: Re: bug#52286: 28.0.90; [PATCH] Be consistent in naming of separators
 in context menu
Date: Sun, 5 Dec 2021 18:09:22 -0800

On 12/5/2021 2:39 AM, Eli Zaretskii wrote:
>> Cc: 52286 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.