bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

(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''

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

Drew Adams <drew.adams@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

> > 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.

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

Drew Adams <drew.adams@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

> >> > 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.

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

Drew Adams <drew.adams@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

> > 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...

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

Drew Adams <drew.adams@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

> >> > 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?

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

Drew Adams <drew.adams@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

On Feb 08 2022, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

On Mär 09 2022, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Andreas Schwab]

On Mär 09 2022, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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#23130: [External] : Re: bug#23130: 25.1.50; `C-h f' etc.: escaping in symbol names

[Drew Adams]

> 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.