GNU bug report logs -
#23130
25.1.50; `C-h f' etc.: escaping in symbol names
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sun, 27 Mar 2016 23:26:02 UTC
Severity: minor
Tags: moreinfo
Found in version 25.1.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
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 23130 in the body.
You can then email your comments to 23130 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#23130; Package
emacs.
(Sun, 27 Mar 2016 23:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 27 Mar 2016 23:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
(defun foo. () (message "FOOOOOO"))
Put point somewhere on the name `foo.'.
`C-h f'
You see this message: Describe function (default foo.):
^^^^
Hit `RET'. You see this output in *Help*:
foo\. is a Lisp function.
(foo\.)
Not sure what others might think of this. The name of the symbol is
"foo.", not "foo\.". This is correctly reflected in the prompt.
I'm thinking it should also be reflected in the first line of the *Help*
output: "foo. is a Lisp function."
Or better yet, to remove all ambiguity, even for characters such as SPC
in the function name, enclose the name in `...':
(defun bar\ () (message "BARRRR"))
`C-h f'
Describe function (default bar ): RET
bar\ is a Lisp function.
(bar\ )
Note that the first line here is not even correct - it should at least
have another SPC char after the `\ '. The way it is written now, it
suggests that the name is `bar\', i.e., that the symbol is bar\\.
I think it would be better to show something like this:
`foo.' is a Lisp function.
(foo\.)
`bar ' is a Lisp function.
(bar\ )
And it would be better to use `...' also in the prompt:
Describe function (default `foo.'):
Describe function (default `bar '):
The same thing holds for other help commands (`describe-variable',
`describe-mode', `describe-face', etc.). The first line of help output
gives the symbol's name. At least it should be enclosed in `...'. And
perhaps when the name is indicated, as opposed to the symbol itself,
such chars should not be escaped.
In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
of 2015-12-10
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
'configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
--enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
-ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 06:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> The name of the symbol is "foo.", not "foo\.".
Both refer to the same symbol, as does "\foo.".
> Or better yet, to remove all ambiguity, even for characters such as SPC
> in the function name, enclose the name in `...':
The name as printed is already unambigous.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 13:22:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 23130 <at> debbugs.gnu.org (full text, mbox):
> > The name of the symbol is "foo.", not "foo\.".
>
> Both refer to the same symbol, as does "\foo.".
Not as `symbol-name' values, they don't.
The point is to show the symbol _name_, and to do so in a
way that is clear to anyone.
> > Or better yet, to remove all ambiguity, even for characters
> > such as SPC in the function name, enclose the name in `...':
>
> The name as printed is already unambigous.
"bar\ is a Lisp function." is not only unclear; it is incorrect.
And if you want to be pedantic, and you think there is already
no room for ambiguity, substitute "possible confusion". Emacs
is not being as clear as it could be, and that is especially
important for someone new to Emacs and Emacs Lisp.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 14:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> > The name of the symbol is "foo.", not "foo\.".
>>
>> Both refer to the same symbol, as does "\foo.".
>
> Not as `symbol-name' values, they don't.
It's showing a symbol, not the result of calling symbol-name on it.
> The point is to show the symbol _name_, and to do so in a
> way that is clear to anyone.
The point is to show a symbol, unambigously.
>> > Or better yet, to remove all ambiguity, even for characters
>> > such as SPC in the function name, enclose the name in `...':
>>
>> The name as printed is already unambigous.
>
> "bar\ is a Lisp function." is not only unclear; it is incorrect.
Of course it's incorrect, but describe-function will never generate
that.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 14:49:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 23130 <at> debbugs.gnu.org (full text, mbox):
> >> > The name of the symbol is "foo.", not "foo\.".
> >>
> >> Both refer to the same symbol, as does "\foo.".
> >
> > Not as `symbol-name' values, they don't.
>
> It's showing a symbol, not the result of calling symbol-name on it.
Yes, we know.
> > The point is to show the symbol _name_, and to do so in a
> > way that is clear to anyone.
>
> The point is to show a symbol, unambigously.
The point of this bug report is that the symbol's name should be
shown clearly. The symbol is already printed using prin1 in the
signature: (foo\.)
Show it as Lisp when showing Lisp. Show it as a symbol name, as
is the Emacs convention, in help text. And in that case, show it
enclosed in `...'.
> >> > Or better yet, to remove all ambiguity, even for characters
> >> > such as SPC in the function name, enclose the name in `...':
> >>
> >> The name as printed is already unambigous.
> >
> > "bar\ is a Lisp function." is not only unclear; it is incorrect.
>
> Of course it's incorrect, but describe-function will never generate
> that.
Why don't you read the bug report and try the recipe for yourself,
starting with `emacs -Q'? That's exactly what `describe-funcction'
"generates":
(defun bar\ () (message "BARRRR"))
`C-h f RET' with point on "bar\ ":
bar\ is a Lisp function.
(bar\ )
Not documented.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 15:20:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> Show it as Lisp when showing Lisp. Show it as a symbol name, as
> is the Emacs convention, in help text. And in that case, show it
> enclosed in `...'.
How will that help in case of weird names?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 15:25:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 23130 <at> debbugs.gnu.org (full text, mbox):
> > Show it as Lisp when showing Lisp. Show it as a symbol name, as
> > is the Emacs convention, in help text. And in that case, show it
> > enclosed in `...'.
>
> How will that help in case of weird names?
You can figure it out, I'm sure...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 16:12:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> > Show it as Lisp when showing Lisp. Show it as a symbol name, as
>> > is the Emacs convention, in help text. And in that case, show it
>> > enclosed in `...'.
>>
>> How will that help in case of weird names?
>
> You can figure it out, I'm sure...
So why do you want to make things worse?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 17:10:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 23130 <at> debbugs.gnu.org (full text, mbox):
> >> > Show it as Lisp when showing Lisp. Show it as a symbol name, as
> >> > is the Emacs convention, in help text. And in that case, show it
> >> > enclosed in `...'.
> >>
> >> How will that help in case of weird names?
> >
> > You can figure it out, I'm sure...
>
> So why do you want to make things worse?
So why do keep trolling?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 28 Mar 2016 17:19:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> >> > Show it as Lisp when showing Lisp. Show it as a symbol name, as
>> >> > is the Emacs convention, in help text. And in that case, show it
>> >> > enclosed in `...'.
>> >>
>> >> How will that help in case of weird names?
>> >
>> > You can figure it out, I'm sure...
>>
>> So why do you want to make things worse?
>
> So why do keep trolling?
I don't.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Tue, 08 Feb 2022 07:05:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> (defun foo. () (message "FOOOOOO"))
>
> Put point somewhere on the name `foo.'.
> `C-h f'
> You see this message: Describe function (default foo.):
> ^^^^
>
> Hit `RET'. You see this output in *Help*:
>
> foo\. is a Lisp function.
>
> (foo\.)
>
> Not sure what others might think of this. The name of the symbol is
> "foo.", not "foo\.". This is correctly reflected in the prompt.
Why is `prin1' quoting the "." anyway? It's not a special character for
the Lisp reader, is it?
> (defun bar\ () (message "BARRRR"))
>
> `C-h f'
> Describe function (default bar ): RET
>
> bar\ is a Lisp function.
>
> (bar\ )
>
> Note that the first line here is not even correct - it should at least
> have another SPC char after the `\ '. The way it is written now, it
> suggests that the name is `bar\', i.e., that the symbol is bar\\.
I've now fixed this in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Tue, 08 Feb 2022 07:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Tue, 08 Feb 2022 09:14:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 23130 <at> debbugs.gnu.org (full text, mbox):
On Feb 08 2022, Lars Ingebrigtsen wrote:
> Why is `prin1' quoting the "." anyway? It's not a special character for
> the Lisp reader, is it?
The following characters are always escaped in a symbol:
if (c == '\"' || c == '\\' || c == '\''
|| c == ';' || c == '#' || c == '(' || c == ')'
|| c == ',' || c == '.' || c == '`'
|| c == '[' || c == ']' || c == '?' || c <= 040
|| c == NO_BREAK_SPACE
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Tue, 08 Feb 2022 09:31:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
>> Why is `prin1' quoting the "." anyway? It's not a special character for
>> the Lisp reader, is it?
>
> The following characters are always escaped in a symbol:
>
> if (c == '\"' || c == '\\' || c == '\''
> || c == ';' || c == '#' || c == '(' || c == ')'
> || c == ',' || c == '.' || c == '`'
> || c == '[' || c == ']' || c == '?' || c <= 040
> || c == NO_BREAK_SPACE
But why "."?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Tue, 08 Feb 2022 09:42:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 23130 <at> debbugs.gnu.org (full text, mbox):
On Feb 08 2022, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>>> Why is `prin1' quoting the "." anyway? It's not a special character for
>>> the Lisp reader, is it?
>>
>> The following characters are always escaped in a symbol:
>>
>> if (c == '\"' || c == '\\' || c == '\''
>> || c == ';' || c == '#' || c == '(' || c == ')'
>> || c == ',' || c == '.' || c == '`'
>> || c == '[' || c == ']' || c == '?' || c <= 040
>> || c == NO_BREAK_SPACE
>
> But why "."?
Because it is special to the reader.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Wed, 09 Mar 2022 16:32:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
>>> The following characters are always escaped in a symbol:
>>>
>>> if (c == '\"' || c == '\\' || c == '\''
>>> || c == ';' || c == '#' || c == '(' || c == ')'
>>> || c == ',' || c == '.' || c == '`'
>>> || c == '[' || c == ']' || c == '?' || c <= 040
>>> || c == NO_BREAK_SPACE
>>
>> But why "."?
>
> Because it is special to the reader.
Is it special to the reader inside a symbol? I'm trying to come up with
an example and failing.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Wed, 09 Mar 2022 17:10:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 23130 <at> debbugs.gnu.org (full text, mbox):
On Mär 09 2022, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>>>> The following characters are always escaped in a symbol:
>>>>
>>>> if (c == '\"' || c == '\\' || c == '\''
>>>> || c == ';' || c == '#' || c == '(' || c == ')'
>>>> || c == ',' || c == '.' || c == '`'
>>>> || c == '[' || c == ']' || c == '?' || c <= 040
>>>> || c == NO_BREAK_SPACE
>>>
>>> But why "."?
>>
>> Because it is special to the reader.
>
> Is it special to the reader inside a symbol?
. and \. are different syntactic entities.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Wed, 09 Mar 2022 17:12:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
>> Is it special to the reader inside a symbol?
>
> . and \. are different syntactic entities.
So the answer is "no"?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Wed, 09 Mar 2022 17:40:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 23130 <at> debbugs.gnu.org (full text, mbox):
On Mär 09 2022, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>>> Is it special to the reader inside a symbol?
>>
>> . and \. are different syntactic entities.
>
> So the answer is "no"?
\. is a symbol.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Wed, 09 Mar 2022 17:43:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
>>> . and \. are different syntactic entities.
>>
>> So the answer is "no"?
>
> \. is a symbol.
I know. So are foo. and foo\. -- the same symbol. If your point is
that "." should always be quoted in symbols because the standalone
`.' symbol has to be quoted (to avoid special-casing anything here), then
that's fair enough, but I wondered whether there was anything further
beyond that.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 14 Mar 2022 09:25:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 23130 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> foo\. is a Lisp function.
>
> (foo\.)
This has now been fixed in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
23130 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 14 Mar 2022 09:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23130; Package
emacs.
(Mon, 14 Mar 2022 14:51:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 23130 <at> debbugs.gnu.org (full text, mbox):
> This has now been fixed in Emacs 29.
No, I don't think so. Based on what you've written
so far, this should be classed as "Won't Fix".
You seem to have ignored both the bug that was
reported and all that's been said about it. And
you've gone off and instead implemented something
you wanted to that's, at best, orthogonal, and
perhaps even antithetical.
Not too surprising, but still disappointing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 12 Apr 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.