bug#52293: [External] : bug#52293: 29.0.50; [PATCH v3] Prevent further cases of duplicated separators in context menus

[Juri Linkov <juri@linkov.net>]

>> I agree that using an extend-format separator is a good idea,
>> especially if we'll provide a special variable that will contain it.
>> But I don't understand why opt-in.  I think opt-out would be better
>> since most of the time the users want to have de-duplicated menus.
>
> One benefit to this being opt-in would be that it would be possible to
> (eventually) support the de-duplication behavior for *all* menus without us
> having to worry about breaking compatibility for other menus[1]. If we
> provide a constant for people to use like in your earlier example[2], it
> would be still be reasonably simple to use.
>
> I think it would be nice to (again, eventually) support this for all menus,
> since it's probably useful in some other places, and it would keep the
> differences between specific menus' behaviors to a minimum.

As Drew already noted, other menus have no such problem because
they are static, and the authors can easily ensure that a single
separator is used between submenus.  But context menus are
dynamically constructed, and it's easier for authors just to
add a separator even for empty submenus, relying on post-processing
that will de-duplicate them.

So better to make this opt-out for context menus, and opt-in
for other menus, although I think this feature is not needed
for other menus.

>> Maybe better first to try fixing the problem using the separators?
>> When this doesn't help, only then we could consider alternatives.
>
> Ok, let's stick with deduplication then. I'll try to write a patch that
> doesn't require `top-separator', since that's easy for programmers to
> forget about (no other menu requires doing that to put items at the
> beginning).

Thanks.  The current question was raised by Drew who worried that
sometimes authors might want to leave two adjacent separators
for an empty submenu.  But you answered this question that it can be
addressed by using a special form of a separator with a menu-item.
So I see no more problems here.