|
From: | Jim Porter |
Subject: | bug#52293: 29.0.50; [PATCH v3] Prevent further cases of duplicated separators in context menus |
Date: | Mon, 13 Dec 2021 10:13:28 -0800 |
On 12/13/2021 4:23 AM, Eli Zaretskii wrote:
Cc: 52293@debbugs.gnu.org, juri@linkov.net From: Jim Porter <jporterbugs@gmail.com> Date: Sun, 12 Dec 2021 13:59:16 -0800 On 12/12/2021 12:43 PM, Eli Zaretskii wrote:Cc: 52293@debbugs.gnu.org, juri@linkov.net From: Jim Porter <jporterbugs@gmail.com> Date: Sun, 12 Dec 2021 12:27:34 -0800 On 12/11/2021 11:02 PM, Eli Zaretskii wrote:Are you saying that we will be recommending a convention for separator names only for menus popped up in context-menu-mode? Does it make sense to have such a specialized convention? Isn't it possible to show context menus outside of the context-menu-mode?No, I think this convention should be recommended for separators used anywhere in Emacs going forward.Ok, so then the effect of this change is wide, as I envisioned, and compatibility considerations still apply.I'm also ok with applying this naming convention *only* to context menus and not treating this as a general guideline; that would still make it easier to remember the names of each context menu separator without having to double-check the source code.I don't think this would make sense, and I said that above.
I don't really have a preference about what we recommend in the documentation. We don't need to recommend anything at all. Above, I was just referring to changing the separator names within context-menu-mode functions to use a single style (`foo-separator'), not necessarily documenting/recommending it.
Even the code change I only have a very slight preference for. I was just reading through the context-menu code to understand it, saw that some separators were named `foo-separator' and others named `separator-foo', and thought that was a bit odd. The only "problem" (and it's barely a problem) is that programmers writing code referring to these separators later (e.g. with `define-key-after') might get the names mixed up if they're not paying attention. Since I came across it, I thought I'd submit a patch in case the maintainers wanted it.
However, if it's controversial (or just too late in the release cycle to make a small compatibility break), I don't have a problem with closing bug#52286 as wontfix. It's such a minor issue that I really don't see any major downside to wontfixing the bug if there's any hesitation about it.
[Prev in Thread] | Current Thread | [Next in Thread] |