GNU bug report logs -
#77326
[PATCH] Add symbol-mode
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77326 in the body.
You can then email your comments to 77326 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#77326
; Package
emacs
.
(Fri, 28 Mar 2025 04:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gabriel Santos <gabriel.santos.smtp <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 28 Mar 2025 04:42: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)]
Greetings,
This patch provides a new package for interacting with symbols, based on
the current word commands and the built-in package "subword".
A minor mode that replaces the word commands is also provided, also
inspired by the subword package, but additionally on the usage of
defvar-keymap I made in a PR I opened for the puni package[1].
- Points of discussion
Would the mention of this mode be a good addition to the documentation?
I don't know how to contribute to the docs, but I would look into doing
so if you think it's a good idea
[1] <https://github.com/AmaiKinono/puni/pull/75>
P.S.: This is being sent from a different e-mail from the patch because
my e-mail provider, viz. Disroot, is having issues with spam, and that
was blocking my messages, so I decided to create a Gmail account to go
around that.
Regards,
--
Gabriel Santos
[0001-Add-symbol-mode.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 08:55:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 77326 <at> debbugs.gnu.org (full text, mbox):
> Cc: Gabriel Santos <gabrielsantosdesouza <at> disroot.org>
> From: Gabriel Santos <gabriel.santos.smtp <at> gmail.com>
> Date: Thu, 27 Mar 2025 19:44:21 -0300
>
> Greetings,
>
> This patch provides a new package for interacting with symbols, based on
> the current word commands and the built-in package "subword".
>
> A minor mode that replaces the word commands is also provided, also
> inspired by the subword package, but additionally on the usage of
> defvar-keymap I made in a PR I opened for the puni package[1].
>
> - Points of discussion
>
> Would the mention of this mode be a good addition to the documentation?
>
> I don't know how to contribute to the docs, but I would look into doing
> so if you think it's a good idea
>
> [1] <https://github.com/AmaiKinono/puni/pull/75>
>
> P.S.: This is being sent from a different e-mail from the patch because
> my e-mail provider, viz. Disroot, is having issues with spam, and that
> was blocking my messages, so I decided to create a Gmail account to go
> around that.
Thanks.
Any comments to the patch, or objections to adding this mode to Emacs?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 12:29:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77326 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2025 at 4:55 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: Gabriel Santos <gabrielsantosdesouza <at> disroot.org>
> > From: Gabriel Santos <gabriel.santos.smtp <at> gmail.com>
> > Date: Thu, 27 Mar 2025 19:44:21 -0300
> >
> > Greetings,
> >
> > This patch provides a new package for interacting with symbols, based on
> > the current word commands and the built-in package "subword".
> >
> > A minor mode that replaces the word commands is also provided, also
> > inspired by the subword package, but additionally on the usage of
> > defvar-keymap I made in a PR I opened for the puni package[1].
> >
> > - Points of discussion
> >
> > Would the mention of this mode be a good addition to the documentation?
> >
> > I don't know how to contribute to the docs, but I would look into doing
> > so if you think it's a good idea
> >
> > [1] <https://github.com/AmaiKinono/puni/pull/75>
> >
> > P.S.: This is being sent from a different e-mail from the patch because
> > my e-mail provider, viz. Disroot, is having issues with spam, and that
> > was blocking my messages, so I decided to create a Gmail account to go
> > around that.
>
> Thanks.
>
> Any comments to the patch, or objections to adding this mode to Emacs?
>
One nice feature this patch could have is to cycle among symbol naming
conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
others?) and that would make it convenient when a variable name with the
same components are used across modalities; e.g. in config files, json,
xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C code,
cycling among to Fsymbol_name or Ssymbol_name?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 77326 <at> debbugs.gnu.org (full text, mbox):
>One nice feature this patch could have is to cycle among symbol naming
>conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
>others?) and that would make it convenient when a variable name with the
>same components are used across modalities; e.g. in config files, json,
>xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C code,
>cycling among to Fsymbol_name or Ssymbol_name?
There are multiple packages like this[1, 2, 3, 4, 5, 6].
Despite that, I think I could give it a try, I just have to
avoid looking into them because of copyright.
So a comnand that changes between different symbol naming conventions,
Like how the capitalization commands work?
Point is "|":
>M-x cycle-convention-symbol
>|this-is-a-symbol
>thisIsASymbol|
>cycle among symbol naming conventions:
So subsequent calls would switch to another convention? I think this
would be ok if the point didn't move.
>M-x mark-sexp
>this-is-a-symbol
>M-x cycle-convention-symbol
>thisIsASymbol
>M-x cycle-convention-symbol
>this_is_a_symbol
>M-x cycle-convention-symbol
>ThisIsASymbol
Besides cycling, maybe choosing a convention with
completion?
>CamelCase, snakeCase, hyphen-case, underscore_case
This could be another issue. The names I know these as
are, respectively:
- PascalCase
- camelCase
- kebab-case (yes, really)
- snake_case
>There are multiple packages like this[1, 2, 3, 4, 5, 6].
Another interesting option would be to contact the author
of one of these packages for inclusion in this file.
[1] <https://github.com/HKey/caseformat>
[2] <https://hg.sr.ht/~zck/caser.el>
[3] <https://github.com/TakesxiSximada/change-case.el>
[4] <https://github.com/jcs-elpa/cycle-case-style>
[5] <https://codeberg.org/acdw/titlecase.el>
[6] <https://github.com/akicho8/string-inflection>
--
Gabriel Santos
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 14:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 77326 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2025 at 10:10 AM Gabriel Santos <
gabrielsantosdesouza <at> disroot.org> wrote:
> >One nice feature this patch could have is to cycle among symbol naming
> >conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
> >others?) and that would make it convenient when a variable name with the
> >same components are used across modalities; e.g. in config files, json,
> >xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C code,
> >cycling among to Fsymbol_name or Ssymbol_name?
>
> There are multiple packages like this[1, 2, 3, 4, 5, 6].
>
> Despite that, I think I could give it a try, I just have to
> avoid looking into them because of copyright.
>
> So a comnand that changes between different symbol naming conventions,
> Like how the capitalization commands work?
>
> Point is "|":
>
> >M-x cycle-convention-symbol
> >|this-is-a-symbol
> >thisIsASymbol|
>
It would be most convenient if point could be anywhere in or around a
symbol when cycling.
> >cycle among symbol naming conventions:
>
> So subsequent calls would switch to another convention? I think this
> would be ok if the point didn't move.
>
I'd think the default cycling options would be mode specific as I
mentioned. In Python mode, for example, kebabs aren't tasty as
identifiers, unless they're in a quoted string or comment so some context
would be helpful. The code would not have to know what constitutes a valid
identifier, though, so if in Python I want to convert my/tasty-kebab to
my/tasty_kebab, it would fail as a Python identifier unless we also offer
some kind of character or syntax-table driven kind of trickery? Not an
expert with the syntax tables so I'm just guessing.
> >M-x mark-sexp
> >this-is-a-symbol
> >M-x cycle-convention-symbol
> >thisIsASymbol
> >M-x cycle-convention-symbol
> >this_is_a_symbol
> >M-x cycle-convention-symbol
> >ThisIsASymbol
>
> Besides cycling, maybe choosing a convention with
> completion?
>
> >CamelCase, snakeCase, hyphen-case, underscore_case
>
> This could be another issue. The names I know these as
> are, respectively:
>
> - PascalCase
> - camelCase
> - kebab-case (yes, really)
> - snake_case
>
Right, the snake bit me, it's PC, cC, k-C, s_c. Pop culture names.
>There are multiple packages like this[1, 2, 3, 4, 5, 6].
>
> Another interesting option would be to contact the author
> of one of these packages for inclusion in this file.
>
It seems "easy" enough to just do it without the hassle and as part of
core Emacs? Especially if the implementations below aren't optimal and
perhaps if tree sitter was leveraged this could be easier. I don't think
the below use any of that infrastructure.
> [1] <https://github.com/HKey/caseformat>
> [2] <https://hg.sr.ht/~zck/caser.el>
> [3] <https://github.com/TakesxiSximada/change-case.el>
> [4] <https://github.com/jcs-elpa/cycle-case-style>
> [5] <https://codeberg.org/acdw/titlecase.el>
> [6] <https://github.com/akicho8/string-inflection>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 15:08:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 77326 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2025 at 10:20 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Sat, Apr 5, 2025 at 10:10 AM Gabriel Santos <
> gabrielsantosdesouza <at> disroot.org> wrote:
>
>> >One nice feature this patch could have is to cycle among symbol naming
>> >conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
>> >others?) and that would make it convenient when a variable name with the
>> >same components are used across modalities; e.g. in config files, json,
>> >xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C
>> code,
>> >cycling among to Fsymbol_name or Ssymbol_name?
>>
>> There are multiple packages like this[1, 2, 3, 4, 5, 6].
>>
>> Despite that, I think I could give it a try, I just have to
>> avoid looking into them because of copyright.
>>
>> So a comnand that changes between different symbol naming conventions,
>> Like how the capitalization commands work?
>>
>> Point is "|":
>>
>> >M-x cycle-convention-symbol
>> >|this-is-a-symbol
>> >thisIsASymbol|
>>
>
> It would be most convenient if point could be anywhere in or around a
> symbol when cycling.
>
>
>> >cycle among symbol naming conventions:
>>
>> So subsequent calls would switch to another convention? I think this
>> would be ok if the point didn't move.
>>
>
> I'd think the default cycling options would be mode specific as I
> mentioned. In Python mode, for example, kebabs aren't tasty as
> identifiers, unless they're in a quoted string or comment so some context
> would be helpful. The code would not have to know what constitutes a valid
> identifier, though, so if in Python I want to convert my/tasty-kebab to
> my/tasty_kebab, it would fail as a Python identifier unless we also offer
> some kind of character or syntax-table driven kind of trickery? Not an
> expert with the syntax tables so I'm just guessing.
>
>
>> >M-x mark-sexp
>> >this-is-a-symbol
>> >M-x cycle-convention-symbol
>> >thisIsASymbol
>> >M-x cycle-convention-symbol
>> >this_is_a_symbol
>> >M-x cycle-convention-symbol
>> >ThisIsASymbol
>>
>> Besides cycling, maybe choosing a convention with
>> completion?
>>
>> >CamelCase, snakeCase, hyphen-case, underscore_case
>>
>> This could be another issue. The names I know these as
>> are, respectively:
>>
>> - PascalCase
>> - camelCase
>> - kebab-case (yes, really)
>> - snake_case
>
>
A very quick perusal of code within easy reach suggests these styles in
varying degrees across languages and configuration files:
PascalCase
camelCase
snake_case
kebab-case
dot.case
[conf.case]
[conf_case]
slash/case (also /slash/case, slash/case/ and /slash/case/ variants)
CONSTANT_CASE
And a few upcase/downcase variants of which CONSTANT_CASE is an obvious
variant of snake.
I also see various symbol embraces that could be useful to cycle; e.g.,
name, $(name), ${name}, $name.
I'm sure there are a bunch more but this seems like a good taxonomy to
start with. What else do people use that are worth implementing?
Names that embed case-runs need to be handled: is DOMError DOME-rror or
DOM-error or domerror? I can imagine offering simple cycling to convert
repeated case streak as DOMError -> DomError (knowing where the case change
is) -> Domerror -> domerror, etc. (I have a convention on my teams that
this is illegal for names we control; it's "DomError" never "DOMError".)
Binding the cycling command to a single key would make cycling feel natural
and generally "free." I'd likely bind this to C-\\ since I don't use
multiple input methods or <f9> merely moving a finger up from the home
row. It would also be great to invoke the function on a region, cycling
all the symbols it found.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 15:15:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 77326 <at> debbugs.gnu.org (full text, mbox):
> This patch provides a new package for interacting with symbols, based on
> the current word commands and the built-in package "subword".
FWIW, in order to avoid confusion with functions operating on Lisp
symbol objects, I'd suggest to try and find another name.
I don't have a good suggestion to make, tho, because I haven't looked
closely enough to understand how it relates to `superword-mode`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 15:19:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 77326 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2025 at 11:15 AM Stefan Monnier via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> > This patch provides a new package for interacting with symbols, based on
> > the current word commands and the built-in package "subword".
>
> FWIW, in order to avoid confusion with functions operating on Lisp
> symbol objects, I'd suggest to try and find another name.
>
> I don't have a good suggestion to make, tho, because I haven't looked
> closely enough to understand how it relates to `superword-mode`.
>
identifier-mode?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 15:48:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 77326 <at> debbugs.gnu.org (full text, mbox):
> Cc: Gabriel Santos <gabrielsantosdesouza <at> disroot.org>, 77326 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 11:14:19 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > This patch provides a new package for interacting with symbols, based on
> > the current word commands and the built-in package "subword".
>
> FWIW, in order to avoid confusion with functions operating on Lisp
> symbol objects, I'd suggest to try and find another name.
symbol-name-mode?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 16:28:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77326 <at> debbugs.gnu.org (full text, mbox):
>> FWIW, in order to avoid confusion with functions operating on Lisp
>> symbol objects, I'd suggest to try and find another name.
> symbol-name-mode?
How is it different from `superword-mode`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 16:53:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 77326 <at> debbugs.gnu.org (full text, mbox):
>identifier-mode
I like this one.
--
Gabriel Santos
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 17:13:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 77326 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: gabriel.santos.smtp <at> gmail.com, gabrielsantosdesouza <at> disroot.org,
> 77326 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 12:27:09 -0400
>
> >> FWIW, in order to avoid confusion with functions operating on Lisp
> >> symbol objects, I'd suggest to try and find another name.
> > symbol-name-mode?
>
> How is it different from `superword-mode`?
The "symbol" part.
AFAIU, this is about programming-language symbols, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sat, 05 Apr 2025 17:16:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 77326 <at> debbugs.gnu.org (full text, mbox):
>How is it different from `superword-mode`?
I looked into `subword-mode`, but not `superword-mode`
(because I often used the former).
I tried it out and it seems to do most things here
(upcasing, lowercasing, transposing, forward, backward...).
The major difference I found is that the superword commands
don't appear as separate commands
(M-f appears as "forward-word" in the lossage despite
going forward a
symbol), because it modifies the word boundaries, while I defined specific symbol commands, that
couls be used separate from the mode.
--
Gabriel Santos
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sun, 13 Apr 2025 07:17:04 GMT)
Full text and
rfc822 format available.
Message #44 received at 77326 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 05 Apr 2025 11:10:48 -0300
> From: Gabriel Santos <gabrielsantosdesouza <at> disroot.org>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Stefan Kangas <stefankangas <at> gmail.com>, Andrea Corallo <acorallo <at> gnu.org>,
> Gabriel Santos <gabriel.santos.smtp <at> gmail.com>, 77326 <at> debbugs.gnu.org
>
> >One nice feature this patch could have is to cycle among symbol naming
> >conventions: CamelCase, snakeCase, hyphen-case, underscore_case (any
> >others?) and that would make it convenient when a variable name with the
> >same components are used across modalities; e.g. in config files, json,
> >xml, protobufs, C/C++ vs. python, and in emacs-lisp-mode and Emacs C code,
> >cycling among to Fsymbol_name or Ssymbol_name?
>
> There are multiple packages like this[1, 2, 3, 4, 5, 6].
>
> Despite that, I think I could give it a try, I just have to
> avoid looking into them because of copyright.
>
> So a comnand that changes between different symbol naming conventions,
> Like how the capitalization commands work?
>
> Point is "|":
>
> >M-x cycle-convention-symbol
> >|this-is-a-symbol
> >thisIsASymbol|
>
> >cycle among symbol naming conventions:
>
> So subsequent calls would switch to another convention? I think this
> would be ok if the point didn't move.
>
> >M-x mark-sexp
> >this-is-a-symbol
> >M-x cycle-convention-symbol
> >thisIsASymbol
> >M-x cycle-convention-symbol
> >this_is_a_symbol
> >M-x cycle-convention-symbol
> >ThisIsASymbol
>
> Besides cycling, maybe choosing a convention with
> completion?
>
> >CamelCase, snakeCase, hyphen-case, underscore_case
>
> This could be another issue. The names I know these as
> are, respectively:
>
> - PascalCase
> - camelCase
> - kebab-case (yes, really)
> - snake_case
>
> >There are multiple packages like this[1, 2, 3, 4, 5, 6].
>
> Another interesting option would be to contact the author
> of one of these packages for inclusion in this file.
So what do you suggest we do with this issue? Are you still offering
this mode for addition to Emacs?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77326
; Package
emacs
.
(Sun, 13 Apr 2025 10:13:04 GMT)
Full text and
rfc822 format available.
Message #47 received at 77326 <at> debbugs.gnu.org (full text, mbox):
>So what do you suggest we do with this issue? Are you still offering
>this mode for addition to Emacs?
Since superword-mode already does what this mode does, I think the mode
should be dropped.
Sorry about this, I just had subword-mode in mind instead so I didn't
look into it-despite them residing in the same file.
What I'm doing right now (the convention cycling function Ship
Mints mentioned) is only loosely related to this, so I don't
think this issue should remain open for that. Again, sorry
for wasting your maintainer time on discussing something
that is already built-in in Emacs.
If you want to read up on my progress with the convention
function, the below paragraphs are just on that.
I'm using kebab-case and PascalCase as tests. I managed to get
it working for the symbol at point and the region, but the logic
is inside a single function, so it's in
need of
some refactoring.
I also need to think of how to get the cycling working, but I
had another idea: a
(major-mode . convention-function) alist to define the preferred
convention of a language, falling back to the function preferred
by the user if the mode doesn't have one. But seeing the changes that will be done to
eglot-server-programs, namely, to make it a "mode-local" variable,
maybe that doesn't seem like the correct approach.
There's also the integration with tree-sitter that Ship
Mints mentioned. Tree-sitter could be used in multiple applications
here. Maybe, instead of relying on the "symbol" regexp, the
mode's definition of an identifier would be used, if it were
to be found in the grammar? Or, perhaps, a tree-sitter-"conventionalize"
function that changes the convention of every identifier in the
buffer? I don't think the latter should exist before a
tree-sitter-rename does, in the likes of eglot-rename.
Other conventions, viz. pascalCase, SCREAMING_SNAKE_CASE
(I got the name from the Rust book, really like this one) would
require different logic, but shouldn't be difficult to implement.
And I think that was it on the convention function, so I'm signing this message off.
Regards,
--
Gabriel Santos
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Tue, 15 Apr 2025 23:51:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gabriel Santos <gabriel.santos.smtp <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 15 Apr 2025 23:51:04 GMT)
Full text and
rfc822 format available.
Message #52 received at 77326-done <at> debbugs.gnu.org (full text, mbox):
Gabriel Santos <gabrielsantosdesouza <at> disroot.org> writes:
>>So what do you suggest we do with this issue? Are you still offering
>>this mode for addition to Emacs?
>
> Since superword-mode already does what this mode does, I think the mode
> should be dropped.
I'm therefore closing this bug report.
If this conclusion is incorrect and this should remain open, please
reply to this email (use "Reply to all" in your email client) and we can
reopen the bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 14 May 2025 11:24:55 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.