GNU bug report logs - #52293
29.0.50; [PATCH] Prevent further cases of duplicated separators in context menus

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "52293 <at> debbugs.gnu.org" <52293 <at> debbugs.gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#52293: [External] : bug#52293: 29.0.50; [PATCH v3] Prevent
 further cases of duplicated separators in context menus
Date: Mon, 13 Dec 2021 10:47:22 +0200

>> This involves no duplicate menu items:
>>    (define-key menu [separator-1] '("--"))
>>    (define-key menu [separator-2] '("--"))
>
> That's correct. The above menu items would be de-duplicated since they're
> both separators. However, that logic only applies to "simple" separators,
> so the de-duplication code doesn't apply to this:
>
>   (define-key menu [separator-1] '(menu-item "--"))
>   (define-key menu [separator-2] '(menu-item "--"))
>
> (It's possible that's just an accidental omission in the original code
> though.)

Actually, this wasn't an omission.  Now that I'm thinking more about this,
maybe separators that are subject to possible removal could be marked by e.g.
using text properties, thus opting into this behavior explicitly:

  (defconst context-menu-separator (list (propertize "--" 'remove t)))
  (define-key menu [separator-1] context-menu-separator)
  (define-key menu [separator-2] context-menu-separator)

Then code that de-duplicates separators could check for this property.

> In any case, I think I prefer the solution I proposed in my followup:
> instead of removing consecutive separators so things look right, we can
> *add* separators between different "sections" of the context menu. Sections
> can be marked by the `:section' keyword and a name for the section (note:
> this only applies to the context menu, not other menus). That should
> completely prevent any unwanted manipulation of menus, since the programmer
> needs to opt into this behavior explicitly.
>
> In my limited tests, that method is also less brittle than the current
> method (this bug is an example of the brittleness). See my other message[1]
> for more details.

Adding a new keyword to every menu item requires more work from authors
of context menus, and actually makes menus more brittle -
when an author forgets to add the new keyword `:section' to some menu item,
then two unexpected separators will be inserted: before and after
such an item.

Previous Next

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