GNU bug report logs -
#52286
28.0.90; [PATCH] Be consistent in naming of separators in context menu
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Sat, 4 Dec 2021 21:58:02 UTC
Severity: normal
Tags: patch, wontfix
Found in version 28.0.90
Fixed in version 29.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52286 in the body.
You can then email your comments to 52286 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 04 Dec 2021 21:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jim Porter <jporterbugs <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 04 Dec 2021 21:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is spun off from bug#52237[1]. There's a minor issue with
`context-menu-mode' where some of the separators are named
`FOO-separator' and others are named `separator-FOO'. Since these
separators are partially useful for context menu functions to find the
right place to insert their items, this inconsistency could be pretty
confusing for authors of those functions (e.g. in third-party packages).
This patch renames the separators to `FOO-separator' following the logic
in the above-linked comment (in short, `FOO' is a noun adjunct modifying
the actual object: a separator). To verify that I changed all the
appropriate places and didn't miss anything, I ran the following command
and manually looked over all the results to eliminate false positives:
ag '(?<![\w-])separator-+[A-Za-z][\w-]*' ../lisp -G '.*\.el$'
I've tested the patch on both Emacs 28 and 29 and don't see any issues
in either.
Hopefully this is a small enough change to make it into Emacs 28, since
otherwise I think we'd just have to live with the names as they are
forever. It wouldn't be very nice to change these names after third
parties had come to rely on them in Emacs 28, after all.
[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-12/msg00312.html
[0001-Rename-context-menu-separators-to-FOO-separator-for-.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sun, 05 Dec 2021 06:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Sat, 4 Dec 2021 13:57:31 -0800
>
> This is spun off from bug#52237[1]. There's a minor issue with
> `context-menu-mode' where some of the separators are named
> `FOO-separator' and others are named `separator-FOO'. Since these
> separators are partially useful for context menu functions to find the
> right place to insert their items, this inconsistency could be pretty
> confusing for authors of those functions (e.g. in third-party packages).
If you want to introduce a convention that others should follow, this
convention should be documented in the ELisp manual.
> Hopefully this is a small enough change to make it into Emacs 28, since
> otherwise I think we'd just have to live with the names as they are
> forever.
The first pretest of Emacs 28 is already out, so this problem is
already with us, isn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sun, 05 Dec 2021 07:45:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52286 <at> debbugs.gnu.org (full text, mbox):
On 12/4/2021 10:45 PM, Eli Zaretskii wrote:
>> From: Jim Porter <jporterbugs <at> gmail.com>
>> Date: Sat, 4 Dec 2021 13:57:31 -0800
>>
>> This is spun off from bug#52237[1]. There's a minor issue with
>> `context-menu-mode' where some of the separators are named
>> `FOO-separator' and others are named `separator-FOO'.
[snip]
>
> If you want to introduce a convention that others should follow, this
> convention should be documented in the ELisp manual.
>
>> Hopefully this is a small enough change to make it into Emacs 28, since
>> otherwise I think we'd just have to live with the names as they are
>> forever.
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sun, 05 Dec 2021 10:05:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 52286 <at> debbugs.gnu.org (full text, mbox):
>> Hopefully this is a small enough change to make it into Emacs 28, since
>> otherwise I think we'd just have to live with the names as they are
>> forever.
>
> The first pretest of Emacs 28 is already out, so this problem is
> already with us, isn't it?
The problem will appear after the packages will start to build
own context menus after the release.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sun, 05 Dec 2021 10:40:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> 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.
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?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sun, 05 Dec 2021 18:10:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> This is spun off from bug#52237[1]. There's a minor issue with
> `context-menu-mode' where some of the separators are named `FOO-separator'
> and others are named `separator-FOO'. Since these separators are partially
> useful for context menu functions to find the right place to insert their
> items, this inconsistency could be pretty confusing for authors of those
> functions (e.g. in third-party packages).
While I agree that it would be nice to release Emacs 28 with consistent
menu separator names, the following list explains the current inconsistency
where part of separator names were based on one naming convention,
and part on another:
lisp/cmuscheme.el
(define-key map [separator-eval] '("--"))
lisp/help-mode.el
(define-key-after map [separator-1] menu-bar-separator)
lisp/info.el
(define-key-after map [separator-1] menu-bar-separator)
(define-key-after map [separator-2] menu-bar-separator)
(define-key-after map [separator-3] menu-bar-separator)
lisp/international/mule-cmds.el
(bindings--define-key map [separator-3] menu-bar-separator)
(bindings--define-key map [separator-2] menu-bar-separator)
(bindings--define-key map [separator-1] menu-bar-separator)
(bindings--define-key map [separator-coding-system] menu-bar-separator)
(bindings--define-key map [separator-input-method] menu-bar-separator)
(bindings--define-key map [separator-mule] menu-bar-separator)
lisp/menu-bar.el
(bindings--define-key menu [separator-exit]
(bindings--define-key menu [separator-print]
(bindings--define-key menu [separator-tab]
(bindings--define-key menu [separator-frame]
(bindings--define-key menu [separator-window]
(bindings--define-key menu [separator-save]
(bindings--define-key menu [separator-tag-isearch]
(bindings--define-key menu [separator-tag-search] menu-bar-separator)
(bindings--define-key menu [separator-repeat-search]
(bindings--define-key menu [separator-replace-tags]
(bindings--define-key menu [separator-tag-file]
(bindings--define-key menu [separator-xref]
(bindings--define-key menu [separator-bookmark]
(bindings--define-key menu [separator-search]
(bindings--define-key menu [separator-undo] menu-bar-separator))
(bindings--define-key menu [separator-1]
(bindings--define-key menu [separator-2]
(bindings--define-key menu [separator-3]
(bindings--define-key menu [separator-keys]
(bindings--define-key menu [separator-file]
(bindings--define-key menu [separator-games]
(bindings--define-key menu [separator-encryption-decryption]
(bindings--define-key menu [separator-net]
(bindings--define-key menu [separator-vc]
(bindings--define-key menu [separator-compare]
(bindings--define-key menu [separator-spell]
(bindings--define-key menu [separator-prog]
(bindings--define-key menu [separator-desc-mule]
lisp/net/eudc.el
(define-key map [separator-eudc-email] menu-bar-separator)
(define-key map [separator-eudc-query] menu-bar-separator)
lisp/progmodes/compile.el
(define-key map [separator-2] nil)
(define-key-after map [separator-compile] menu-bar-separator)
lisp/tool-bar.el
(define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
(define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
(define-key-after (default-value 'tool-bar-map) [separator-3] menu-bar-separator)
lisp/vc/ediff-hook.el
(define-key menu-bar-ediff-menu [separator-ediff-misc] menu-bar-separator)
(define-key menu-bar-ediff-menu [separator-ediff-windows] menu-bar-separator)
(define-key menu-bar-ediff-menu [separator-ediff-regions] menu-bar-separator)
(define-key menu-bar-ediff-menu [separator-ediff-directories] menu-bar-separator)
(define-key menu-bar-ediff-menu [separator-ediff-files] menu-bar-separator)
(define-key menu-bar-ediff-merge-menu [separator-ediff-merge] menu-bar-separator)
menu-bar-ediff-merge-menu [separator-ediff-merge-dirs] menu-bar-separator)
lisp/vc/vc-dir.el
(define-key-after map [separator-1] menu-bar-separator)
(define-key-after map [separator-2] menu-bar-separator)
(define-key-after map [separator-3] menu-bar-separator)
And another naming convention:
lisp/cedet/cedet.el
(define-key map [semantic-options-separator] #'undefined)
(define-key map [cedet-menu-separator] #'undefined)
lisp/cedet/ede.el
(define-key cedet-menu-map [cedet-menu-separator] '("--")))
(define-key cedet-menu-map [cedet-menu-separator] nil)
lisp/cedet/semantic.el
(define-key edit-menu [semantic-completion-separator]
(define-key edit-menu [semantic-edit-separator]
(define-key navigate-menu [semantic-narrow-to-defun-separator]
(define-key navigate-menu [semantic-navigation-separator]
(define-key cedet-menu-map [semantic-options-separator]
(define-key cedet-menu-map [cedet-menu-separator] '("--")))
(define-key cedet-menu-map [cedet-menu-separator] nil)
(define-key cedet-menu-map [semantic-options-separator] nil)
lisp/international/iso-cvt.el
(define-key menu [load-as-separator] '("--"))
(define-key menu [translate-separator] '("--"))
lisp/menu-bar.el
(bindings--define-key menu [scrollbar-separator]
(bindings--define-key menu [linecolumn-separator]
(bindings--define-key menu [datetime-separator]
(bindings--define-key menu [custom-separator]
(bindings--define-key menu [custom-separator]
(bindings--define-key menu [showhide-separator]
(bindings--define-key menu [mule-separator]
(bindings--define-key menu [debugger-separator]
(bindings--define-key menu [cursor-separator]
(bindings--define-key menu [edit-options-separator]
(bindings--define-key menu [highlight-separator]
lisp/net/newst-plainview.el
(define-key map [newsticker-separator-1]
(define-key map [newsticker-separator-2]
(define-key map [newsticker-separator-3]
(define-key map [newsticker-separator-4]
lisp/so-long.el
(define-key-after map [so-long-actions-separator]
(define-key-after map [so-long-help-separator]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Mon, 06 Dec 2021 02:10:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 52286 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Mon, 06 Dec 2021 12:56:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> Cc: 52286 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 11 Dec 2021 20:53:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 52286 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/6/2021 4:55 AM, Eli Zaretskii wrote:
> I think the most natural place is where we describe how to construct
> menus.
Thanks.
>> 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.
It's not just for `elisp-mode'; any mode (or other third-party code) may
want to insert context menu items in a certain spot. `middle-separator'
follows the naming convention I recommend, but a hypothetical mode might
want to insert a new item just after the separator for the Undo section.
However, that's currently named `separator-undo' on master, so it can be
confusing to remember the difference in naming between these two cases:
(define-key-after menu [my-separator] menu-bar-separator
'middle-separator)
(define-key-after menu [my-separator] menu-bar-separator
'separator-undo)
> 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.
Ok, I've tried to provide a brief explanation of the recommendation and
the reasoning for it without *over*-explaining it. I also added a small
explanation about how to use `menu-bar-separator', since I didn't see
documentation on that in the manual, and it helped segue into an
explanation about the naming recommendation.
[0001-Rename-context-menu-separators-to-FOO-separator-for-.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 15 Jan 2022 19:00:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> It's not just for `elisp-mode'; any mode (or other third-party code) may
> want to insert context menu items in a certain spot. `middle-separator'
> follows the naming convention I recommend, but a hypothetical mode might
> want to insert a new item just after the separator for the Undo
> section. However, that's currently named `separator-undo' on master, so it
> can be confusing to remember the difference in naming between these two
> cases:
>
> (define-key-after menu [my-separator] menu-bar-separator
> 'middle-separator)
>
> (define-key-after menu [my-separator] menu-bar-separator
> 'separator-undo)
If it's too late to push this to the release branch,
then this definitely can't be done after the release.
So probably this bug report should be closed?
Meanwhile, I noticed another inconsistency
where context menus for some modes are named
with the -mode suffix, and some without it.
With `-mode':
lisp/help-mode.el
(defun help-mode-context-menu (menu click)
lisp/textmodes/text-mode.el
(defun text-mode-context-menu (menu click)
Without `-mode':
lisp/progmodes/prog-mode.el
(defun prog-context-menu (menu click)
lisp/progmodes/elisp-mode.el
(defun elisp-context-menu (menu click)
Maybe it's too late to fix this inconsistency too?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 15 Jan 2022 19:14:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 52286 <at> debbugs.gnu.org
> Date: Sat, 15 Jan 2022 20:57:39 +0200
>
> With `-mode':
>
> lisp/help-mode.el
> (defun help-mode-context-menu (menu click)
>
> lisp/textmodes/text-mode.el
> (defun text-mode-context-menu (menu click)
>
> Without `-mode':
>
> lisp/progmodes/prog-mode.el
> (defun prog-context-menu (menu click)
>
> lisp/progmodes/elisp-mode.el
> (defun elisp-context-menu (menu click)
>
> Maybe it's too late to fix this inconsistency too?
I don't even understand why we should care about this nit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 15 Jan 2022 19:21:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 52286 <at> debbugs.gnu.org (full text, mbox):
>> With `-mode':
>>
>> lisp/help-mode.el
>> (defun help-mode-context-menu (menu click)
>>
>> lisp/textmodes/text-mode.el
>> (defun text-mode-context-menu (menu click)
>>
>> Without `-mode':
>>
>> lisp/progmodes/prog-mode.el
>> (defun prog-context-menu (menu click)
>>
>> lisp/progmodes/elisp-mode.el
>> (defun elisp-context-menu (menu click)
>>
>> Maybe it's too late to fix this inconsistency too?
>
> I don't even understand why we should care about this nit.
For purely aesthetic purposes :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 15 Jan 2022 19:24:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 52286 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: jporterbugs <at> gmail.com, 52286 <at> debbugs.gnu.org
> Date: Sat, 15 Jan 2022 21:19:04 +0200
>
> >> With `-mode':
> >>
> >> lisp/help-mode.el
> >> (defun help-mode-context-menu (menu click)
> >>
> >> lisp/textmodes/text-mode.el
> >> (defun text-mode-context-menu (menu click)
> >>
> >> Without `-mode':
> >>
> >> lisp/progmodes/prog-mode.el
> >> (defun prog-context-menu (menu click)
> >>
> >> lisp/progmodes/elisp-mode.el
> >> (defun elisp-context-menu (menu click)
> >>
> >> Maybe it's too late to fix this inconsistency too?
> >
> > I don't even understand why we should care about this nit.
>
> For purely aesthetic purposes :-)
I suggest to forget about this. We have enough real problems on our
hands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52286
; Package
emacs
.
(Sat, 15 Jan 2022 19:28:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 52286 <at> debbugs.gnu.org (full text, mbox):
tags 52286 wontfix
close 52286 29.0.50
quit
>> >> Maybe it's too late to fix this inconsistency too?
>> >
>> > I don't even understand why we should care about this nit.
>>
>> For purely aesthetic purposes :-)
>
> I suggest to forget about this. We have enough real problems on our
> hands.
Ok, so closing.
Added tag(s) wontfix.
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Jan 2022 19:28:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 29.0.50, send any further explanations to
52286 <at> debbugs.gnu.org and Jim Porter <jporterbugs <at> gmail.com>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Jan 2022 19:28:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 13 Feb 2022 12:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 146 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.