evaluating numbers

evaluating numbers

[Jean-Christophe Helary]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 485 bytes --]

A while ago the biggest number that evaluated to a character (that I could not display) was 1114111 (evaluated to "?􏿿 ").

Now, I can only go up to 127 (#o177, #x7f, ?\C-?) and 128 evaluates to (#o200, #x80) which looks like the ASCII character set, but I was under the impression that Emacs had its own character set...

What's going on here ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Stephen Berman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1133 bytes --]

On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:

> A while ago the biggest number that evaluated to a character (that I could not
> display) was 1114111 (evaluated to "?􏿿 ").
>
> Now, I can only go up to 127 (#o177, #x7f, ?\C-?) and 128 evaluates to (#o200,
> #x80) which looks like the ASCII character set, but I was under the impression
> that Emacs had its own character set...
>
> What's going on here ?
>
> Jean-Christophe Helary
> -----------------------------------------------
> http://mac4translators.blogspot.com @brandelune

This:

  eval-expression-print-maximum-character is a variable defined in ‘simple.el’.
  Its value is 127
  
    You can customize this variable.
  
  
  This variable was introduced, or its default value was changed, in
  version 26.1 of Emacs.
    Probably introduced at or before Emacs version 26.1.
  
  Documentation:
  The largest integer that will be displayed as a character.
  This affects printing by ‘eval-expression’ (via
  ‘eval-expression-print-format’).

Steve Berman

Re: evaluating numbers

[Jean-Christophe Helary]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1229 bytes --]



> On Nov 7, 2019, at 18:57, Stephen Berman <stephen.berman@gmx.net> wrote:
> 
> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
>> A while ago the biggest number that evaluated to a character (that I could not
>> display) was 1114111 (evaluated to "?􏿿 ").
>> 
>> Now, I can only go up to 127 (#o177, #x7f, ?\C-?) and 128 evaluates to (#o200,
>> #x80) which looks like the ASCII character set, but I was under the impression
>> that Emacs had its own character set...
>> 
>> What's going on here ?
> 
> This:
> 
>  eval-expression-print-maximum-character is a variable defined in ‘simple.el’.
>  Its value is 127
> 
>    You can customize this variable.
> 
> 
>  This variable was introduced, or its default value was changed, in
>  version 26.1 of Emacs.
>    Probably introduced at or before Emacs version 26.1.

Thank you very much.

What's the rationale behind this change ?

I find that's a bit silly to limit the character set range available with this evaluation.

Anybody knows ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Stephen Berman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1474 bytes --]

On Thu, 7 Nov 2019 19:20:23 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:

>> On Nov 7, 2019, at 18:57, Stephen Berman <stephen.berman@gmx.net> wrote:
>> 
>> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary
>> <jean.christophe.helary@traduction-libre.org> wrote:
>> 
>>> A while ago the biggest number that evaluated to a character (that I could not
>>> display) was 1114111 (evaluated to "?􏿿 ").
>>> 
>>> Now, I can only go up to 127 (#o177, #x7f, ?\C-?) and 128 evaluates to (#o200,
>>> #x80) which looks like the ASCII character set, but I was under the impression
>>> that Emacs had its own character set...
>>> 
>>> What's going on here ?
>> 
>> This:
>> 
>>  eval-expression-print-maximum-character is a variable defined in ‘simple.el’.
>>  Its value is 127
>> 
>>    You can customize this variable.
>> 
>> 
>>  This variable was introduced, or its default value was changed, in
>>  version 26.1 of Emacs.
>>    Probably introduced at or before Emacs version 26.1.
>
> Thank you very much.
>
> What's the rationale behind this change ?
>
> I find that's a bit silly to limit the character set range available with this
> evaluation.
>
> Anybody knows ?

I think the main rationale was that it could take a long time for Emacs
to return the evaluation when the system had a lot of fonts installed,
because Emacs would try them all to display the character.

Steve Berman

Re: evaluating numbers

[Jean-Christophe Helary]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1984 bytes --]



> On Nov 7, 2019, at 19:30, Stephen Berman <stephen.berman@gmx.net> wrote:
> 
> On Thu, 7 Nov 2019 19:20:23 +0900 Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> wrote:
> 
>>> On Nov 7, 2019, at 18:57, Stephen Berman <stephen.berman@gmx.net> wrote:
>>> 
>>> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary
>>> <jean.christophe.helary@traduction-libre.org> wrote:
>>> 
>>>> A while ago the biggest number that evaluated to a character (that I could not
>>>> display) was 1114111 (evaluated to "?􏿿 ").
>>>> 
>>>> Now, I can only go up to 127 (#o177, #x7f, ?\C-?) and 128 evaluates to (#o200,
>>>> #x80) which looks like the ASCII character set, but I was under the impression
>>>> that Emacs had its own character set...
>>>> 
>>>> What's going on here ?
>>> 
>>> This:
>>> 
>>> eval-expression-print-maximum-character is a variable defined in ‘simple.el’.
>>> Its value is 127
>>> 
>>>   You can customize this variable.
>>> 
>>> 
>>> This variable was introduced, or its default value was changed, in
>>> version 26.1 of Emacs.
>>>   Probably introduced at or before Emacs version 26.1.
>> 
>> Thank you very much.
>> 
>> What's the rationale behind this change ?
>> 
>> I find that's a bit silly to limit the character set range available with this
>> evaluation.
>> 
>> Anybody knows ?
> 
> I think the main rationale was that it could take a long time for Emacs
> to return the evaluation when the system had a lot of fonts installed,
> because Emacs would try them all to display the character.

Thank you for the explanation.

Wouldn't it be more logical to only try the font used in the buffer at stake and give a proper evaluation of the number ?

How do we expect people to understand that there is a limitation when they don't see anything above 127 ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 7 Nov 2019 19:40:26 +0900
> 
> Wouldn't it be more logical to only try the font used in the buffer at stake and give a proper evaluation of the number ?

Emacs uses quite a few fonts in the default configuration, and it
would be hard to explain why we sometimes display the character and
sometimes don't.

> How do we expect people to understand that there is a limitation when they don't see anything above 127 ?

By reading the documentation?

Anyway, this train has left the station: we originally didn't limit
the values at all, and always displayed the corresponding character.
We changed that because people complained that sometimes evaluating an
integer expression takes a long time.

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 7, 2019, at 23:39, Eli Zaretskii <eliz@gnu.org> wrote:

> we originally didn't limit
> the values at all, and always displayed the corresponding character.
> We changed that because people complained that sometimes evaluating an
> integer expression takes a long time.

What's the rationale behind limiting it to ascii and not to 0 displayed characters ? That would make much more sense. Are there use cases where displaying an ascii character when evaluating an integer is more important than displaying an "é" ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 8 Nov 2019 09:36:32 +0900
> 
> What's the rationale behind limiting it to ascii and not to 0 displayed characters ?

Any font used by Emacs for the default face will always be able to
support ASCII characters, but that is not necessarily true for
non-ASCII, not even for Latin (although in practice most if not all
fonts do support the Latin-1 Supplement block.

> Are there use cases where displaying an ascii character when evaluating an integer is more important than displaying an "é" ?

This isn't about importance, this is about potential slowdown in
displaying a simple integer result because Emacs needs to look for a
suitable font.

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 8, 2019, at 19:03, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Fri, 8 Nov 2019 09:36:32 +0900
>> 
>> What's the rationale behind limiting it to ascii and not to 0 displayed characters ?
> 
> Any font used by Emacs for the default face will always be able to
> support ASCII characters, but that is not necessarily true for
> non-ASCII, not even for Latin (although in practice most if not all
> fonts do support the Latin-1 Supplement block.
> 
>> Are there use cases where displaying an ascii character when evaluating an integer is more important than displaying an "é" ?
> 
> This isn't about importance, this is about potential slowdown in
> displaying a simple integer result because Emacs needs to look for a
> suitable font.

Ok, so there are no needs whatsoever to display *any* character when evaluating an integer, am I correct ?

Also, eval-expression-print-maximum-character is described in "24.9 Evaluating Emacs Lisp Expressions" but unlike eval-expression-print-length and eval-expression-print-level it is not indexed in the elisp reference even though both are also described only in that same chapter. Is that an oversight ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Stefan Monnier]

> Ok, so there are no needs whatsoever to display *any* character when
> evaluating an integer, am I correct ?

Indeed, it's merely a convenience for the case where the integer that is
returned is actually meant to represent a character.


        Stefan

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 8 Nov 2019 21:23:00 +0900
> 
> > This isn't about importance, this is about potential slowdown in
> > displaying a simple integer result because Emacs needs to look for a
> > suitable font.
> 
> Ok, so there are no needs whatsoever to display *any* character when evaluating an integer, am I correct ?

There are situations where it is useful.  For example:

  M-: (char-after) RET

> Also, eval-expression-print-maximum-character is described in "24.9 Evaluating Emacs Lisp Expressions" but unlike eval-expression-print-length and eval-expression-print-level it is not indexed in the elisp reference even though both are also described only in that same chapter. Is that an oversight ?

I don't think it's an oversight.  This is a user option, so its place
is generally on the user manual.  The ELisp manual has a
cross-reference to where that variable is described; the ELisp manual
mentions eval-expression-print-length and eval-expression-print-level
only because they are relevant to print-length and print-eval
described there.

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 8, 2019, at 22:49, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary 
>> 
>> Ok, so there are no needs whatsoever to display *any* character when evaluating an integer, am I correct ?
> 
> There are situations where it is useful.  For example:
> 
>  M-: (char-after) RET

But that doesn't work for non-ascii characters. Hence my previous question about the relative importance of "e" vs "é" for ex.

If we have a function like (char-after) that is defined as "Return(ing) character in current buffer at position POS." then it should do that for all the characters defined in the emacs supported character set, shouldn't it?

I'm fine with integers evaluation displaying only number values by the way. But maybe (char-after) and similar functions should use a different value for eval-expression-print-maximum-character.


>> Also, eval-expression-print-maximum-character is described in "24.9 Evaluating Emacs Lisp Expressions" but unlike eval-expression-print-length and eval-expression-print-level it is not indexed in the elisp reference even though both are also described only in that same chapter. Is that an oversight ?
> 
> I don't think it's an oversight.  This is a user option, so its place is generally on the user manual.

Ok, I see, Thank you. Is there a general policy to just mention/define variables and not give default values in the manual ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/html, Size: 1129 bytes --]

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sat, 9 Nov 2019 09:15:30 +0900
> 
> >  M-: (char-after) RET
> 
> But that doesn't work for non-ascii characters. Hence my previous question about the relative importance of "e" vs "é" for ex.

Yes, and we have just made a full circle.  Users who want this to work
for any character should customize
eval-expression-print-maximum-character to a suitable value.  The
current default is a compromise, which is still tremendously useful
because at least IME examining ASCII characters is a very frequent use
case.  AFAIR we had a long discussion back when this option was
introduced and its default set to 127, and this is the compromise we
have reached.  If you don't like the default, you can have a different
value that satisfies you.  But I see no reason to continue questioning
the default any further.

> If we have a function like (char-after) that is defined as "Return(ing) character in current buffer at position POS." then it should do that for all the characters defined in the emacs supported character set, shouldn't it?

Characters are just integers in Emacs.

> I'm fine with integers evaluation displaying only number values by the way. But maybe (char-after) and similar functions should use a different value for eval-expression-print-maximum-character.

Feel free to file a feature-request bug report about this.

> Is there a general policy to just mention/define variables and not give default values in the manual ?

No.

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sat, 9 Nov 2019 09:20:45 +0900
> 
> It seems to me that setting eval-expression-print-maximum-character to support only ascii is only a good
> option if we don't have a smart way to evaluate integers without sifting through all the available fonts.

What does that mean, exactly?  If you want to suggest a different way
of looking for a suitable font, please do.  Otherwise, what we have
now is the best our past and current font wizards could have come up
with, and it's supposed to be quite "smart".

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 9, 2019, at 16:22, Eli Zaretskii <eliz@gnu.org> wrote:

> But I see no reason to continue questioning the default any further.

I'm not questioning the default, I'm trying to understand a feature and it's default setting. Apologies if that takes time.

>> If we have a function like (char-after) that is defined as "Return(ing) character in current buffer at position POS." then it should do that for all the characters defined in the emacs supported character set, shouldn't it?
> 
> Characters are just integers in Emacs.

I know that. You're not really answering the above question. When people expect a character to be returned, they expect a character and not a code point.

How useful is:

(decode-char 'emacs 345)
345 (#o531, #x159)

?

I already know that the code point is 345.

> If you want to suggest a different way of looking for a suitable font, please do.

Maybe not "look for a suitable font" but set a default font for that action. There is a finite number of standard fonts on systems that support emacs.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sat, 9 Nov 2019 20:18:58 +0900
> 
> > But I see no reason to continue questioning the default any further.
> 
> I'm not questioning the default, I'm trying to understand a feature and it's default setting. Apologies if that takes time.

I'm happy to explain what is still unclear.  It seemed to me that the
latest questions all aim at asking why not do something other than the
default, they don't ask clarifications about the feature, which is
really quite simple.  Apologies if this is my misunderstanding.

> >> If we have a function like (char-after) that is defined as "Return(ing) character in current buffer at position POS." then it should do that for all the characters defined in the emacs supported character set, shouldn't it?
> > 
> > Characters are just integers in Emacs.
> 
> I know that. You're not really answering the above question. When people expect a character to be returned, they expect a character and not a code point.

I don't think I agree, not when you say it in such general form.  It
is definitely possible that the user does want to see the codepoint.
I know I sometimes do.

> How useful is:
> 
> (decode-char 'emacs 345)
> 345 (#o531, #x159)
> 
> ?
> 
> I already know that the code point is 345.

Yes, but did you know its octal and hex codes as well?  I sometimes do
the above, or something similar, for those reasons.

> > If you want to suggest a different way of looking for a suitable font, please do.
> 
> Maybe not "look for a suitable font" but set a default font for that action. There is a finite number of standard fonts on systems that support emacs.

Unfortunately, the last sentence is in general incorrect.  The reality
is that no font (at least none that I know of) supports all of
Unicode, so we will need to have several fonts from which to select.
And that is tricky if you want the result work on all platforms.

Re: evaluating numbers

[Stefan Monnier]

>> Characters are just integers in Emacs.
> I know that. You're not really answering the above question. When people
> expect a character to be returned, they expect a character and not
> a code point.

Emacs can't know what the user expects.

> How useful is:
> (decode-char 'emacs 345)
> 345 (#o531, #x159)

And the code that displays "345 (#o531, #x159)" doesn't know that this
345 is coming out of a function which is expected to return characters.
All it knows is that it has to print the integer 345.


        Stefan

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 10, 2019, at 1:03, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> Characters are just integers in Emacs.
>> I know that. You're not really answering the above question. When people
>> expect a character to be returned, they expect a character and not
>> a code point.
> 
> Emacs can't know what the user expects.

Developers can know.

>> How useful is:
>> (decode-char 'emacs 345)
>> 345 (#o531, #x159)
> 
> And the code that displays "345 (#o531, #x159)" doesn't know that this
> 345 is coming out of a function which is expected to return characters.

Considering the documentation of decode-char ("returns a character"), that's either an implementation error or a documentation error...

And if the intent is "returns an integer that is the code point of the character that sometimes gets to be displayed and sometimes not... etc." then let it be documented that way. But you can't say "it's a character, except when it's not, and Emacs wouldn't know the difference anyway, so oops".

:)

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Jean-Christophe Helary]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2356 bytes --]



> On Nov 9, 2019, at 20:48, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> I'm not questioning the default, I'm trying to understand a feature and it's default setting. Apologies if that takes time.
> 
> I'm happy to explain what is still unclear.  It seemed to me that the
> latest questions all aim at asking why not do something other than the
> default, they don't ask clarifications about the feature, which is
> really quite simple.  Apologies if this is my misunderstanding.

As I just replied to Stephan, there is a big cognitive gap here. And it's not easy to wrap my mind around it.

>>> If you want to suggest a different way of looking for a suitable font, please do.
>> 
>> Maybe not "look for a suitable font" but set a default font for that action. There is a finite number of standard fonts on systems that support emacs.
> 
> Unfortunately, the last sentence is in general incorrect.  The reality
> is that no font (at least none that I know of) supports all of
> Unicode, so we will need to have several fonts from which to select.
> And that is tricky if you want the result work on all platforms.

I understand that.

So allow me to get back to my original issue, it's a repetition of what I've written already but please bear with me.

65 (#o101, #x41, ?A)

is perfect

Not so long ago I had

1114111 (#o4177777, #x10ffff, ?􏿿 )

and it was fine, because the glitch at the end meant to me that the font did not cover that code point. I've known that for a long time.

Now I have 

1114111 (#o4177777, #x10ffff)

And I even have

232 (#o350, #xe8)

even though 232 is clearly covered by my default fonts.

The issue here is that I can't know for sure that there is a corresponding glyph or not.

For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like

1114111 (#o4177777, #x10ffff, t)

232 (#o350, #xe8, t)

or something similar where t is the value of characterp for that integer when the integer is above the value of eval-expression-print-maximum-character.

That way I *know* when an integer is a character and when it is not. And I can find ways to look for it separately.

Would that break things ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Stefan Monnier]

>>>> Characters are just integers in Emacs.
>>> I know that. You're not really answering the above question. When people
>>> expect a character to be returned, they expect a character and not
>>> a code point.
>> Emacs can't know what the user expects.
> Developers can know.
>>> How useful is:
>>> (decode-char 'emacs 345)
>>> 345 (#o531, #x159)
>> And the code that displays "345 (#o531, #x159)" doesn't know that this
>> 345 is coming out of a function which is expected to return characters.
> Considering the documentation of decode-char ("returns a character"), that's
> either an implementation error or a documentation error...

So you're suggesting that the eval-expression function should look at
the `car` of the expression that it evaluated, then fetch its docstring
and see if it claims to return a character?

I'd encourage you try and write such a hack.  Then consider whether (and
how) it should try and handle cases such as

    (let ((x 345)) (decode-char 'emacs x))
or
    (1+ (decode-char 'emacs 345))
or
    (funcall #'decode-char 'emacs 345)
or
    (aref s 3)

[ Side note: I'm the guy who wrote the code that displays those ?<char>
  thingies, and I'm a great fan of them (and I remove the
  eval-expression-print-maximum-character limit).  But I'll also note
  that if you want to see the char, you can simply wrap your expression
  inside a `string` call, as in M-: (string (decode-char 'emacs 345)) RET ]

I think you're just beginning to discover that XEmacs's decision to have
characters as a built-in type, separate from integers, does occasionally
offer some benefits ;-)


        Stefan

Re: evaluating numbers

[Andreas Schwab]

On Nov 10 2019, Jean-Christophe Helary wrote:

> That way I *know* when an integer is a character and when it is not.

Set eval-expression-print-maximum-character to (max-char).

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

Re: evaluating numbers

[Juri Linkov]

>> That way I *know* when an integer is a character and when it is not.
>
> Set eval-expression-print-maximum-character to (max-char).

eval-expression-print-maximum-character is a customizable variable,
but has no option for max-char.  Should it?

Re: evaluating numbers

[Juri Linkov]

>>> That way I *know* when an integer is a character and when it is not.
>>
>> Set eval-expression-print-maximum-character to (max-char).
>
> eval-expression-print-maximum-character is a customizable variable,
> but has no option for max-char.  Should it?

diff --git a/lisp/simple.el b/lisp/simple.el
index 47d4adb0fd..8b1f9e3e52 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1561,7 +1561,9 @@ eval-expression-print-maximum-character
 This affects printing by `eval-expression' (via
 `eval-expression-print-format')."
   :group 'lisp
-  :type 'integer
+  :type `(choice (const :tag "ASCII characters" 127)
+                 (const :tag "Maximum number" ,(max-char))
+                 (integer :tag "Custom number"))
   :version "26.1")
 

RE: evaluating numbers

[Drew Adams]

I don't see the default value there, but shouldn't it be the value of (max-char)?

If the point of printing the value as a character is to print it as a character, why wouldn't the default behavior be to print any possible character as a character?

RE: evaluating numbers

[Eli Zaretskii]

On November 12, 2019 10:05:50 PM GMT, Drew Adams <drew.adams@oracle.com> wrote:
> I don't see the default value there, but shouldn't it be the value of
> (max-char)?
> 
> If the point of printing the value as a character is to print it as a
> character, why wouldn't the default behavior be to print any possible
> character as a character?

Please don't reopen old disputes.  The default is 127.

RE: evaluating numbers

[Drew Adams]

> > I don't see the default value there, but shouldn't it
> > be the value of (max-char)?
> >
> > If the point of printing the value as a character is
> > to print it as a character, why wouldn't the default
> > behavior be to print any possible character as a character?
> 
> Please don't reopen old disputes.  The default is 127.

I didn't realize there was a "dispute", old or young.

I just came across this thread.  Tracing it back to
its beginning (which was only 5 days ago), I see that
the default is 127, and it was apparently previously
much bigger.  Too bad, but not a big deal.

RE: evaluating numbers

[Eli Zaretskii]

On November 12, 2019 11:30:47 PM GMT, Drew Adams <drew.adams@oracle.com> wrote:
> > > I don't see the default value there, but shouldn't it
> > > be the value of (max-char)?
> > >
> > > If the point of printing the value as a character is
> > > to print it as a character, why wouldn't the default
> > > behavior be to print any possible character as a character?
> > 
> > Please don't reopen old disputes.  The default is 127.
> 
> I didn't realize there was a "dispute", old or young.
> 
> I just came across this thread.  Tracing it back to
> its beginning (which was only 5 days ago), I see that
> the default is 127, and it was apparently previously
> much bigger.  Too bad, but not a big deal.

Originally, there was no limit.  But people complained about Emacs displaying characters they didn't care about and slowly searching for a suitable font while at that.  So we've added a customizable limit some time ago, after a long discussion.

RE: evaluating numbers

[Drew Adams]

> Originally, there was no limit.  But people complained about Emacs
> displaying characters they didn't care about and slowly searching for a
> suitable font while at that.  So we've added a customizable limit some
> time ago, after a long discussion.

I see.  Thanks for the explanation.

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 10, 2019, at 13:47, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>>> Characters are just integers in Emacs.
>>>> I know that. You're not really answering the above question. When people
>>>> expect a character to be returned, they expect a character and not
>>>> a code point.
>>> Emacs can't know what the user expects.
>> Developers can know.
>>>> How useful is:
>>>> (decode-char 'emacs 345)
>>>> 345 (#o531, #x159)
>>> And the code that displays "345 (#o531, #x159)" doesn't know that this
>>> 345 is coming out of a function which is expected to return characters.
>> Considering the documentation of decode-char ("returns a character"), that's
>> either an implementation error or a documentation error...
> 
> So you're suggesting that the eval-expression function should look at
> the `car` of the expression that it evaluated, then fetch its docstring
> and see if it claims to return a character?

No. I'm suggesting that the developer who wrote that code and that documentation is creating expectations by using the word "character" and thus could have implemented the function so that it returns a "character", or a "glyph" (which are synonymous) and not only its code point. That's what I mean when I write "Developers can know" vs your "Emacs can't know".

> [ Side note: I'm the guy who wrote the code that displays those ?<char>
> thingies, and I'm a great fan of them (and I remove the
> eval-expression-print-maximum-character limit).  But I'll also note
> that if you want to see the char, you can simply wrap your expression
> inside a `string` call, as in M-: (string (decode-char 'emacs 345)) RET ]

As I replied to Eli on the 10th:

> For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like
> 
> 1114111 (#o4177777, #x10ffff, t)
> 
> 232 (#o350, #xe8, t)
> 
> or something similar where t is the value of characterp for that integer when the integer is above the value of eval-expression-print-maximum-character.
> 
> That way I *know* when an integer is a character and when it is not. And I can find ways to look for it separately.
> 
> Would that break things ?


Would that break things ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 10 Nov 2019 09:22:19 +0900
> 
> >> (decode-char 'emacs 345)
> >> 345 (#o531, #x159)
> > 
> > And the code that displays "345 (#o531, #x159)" doesn't know that this
> > 345 is coming out of a function which is expected to return characters.
> 
> Considering the documentation of decode-char ("returns a character"), that's either an implementation error or a documentation error...

It's neither, because characters are integers in Emacs, and a
character is identical to its codepoint.

> And if the intent is "returns an integer that is the code point of the character that sometimes gets to be displayed and sometimes not... etc." then let it be documented that way. But you can't say "it's a character, except when it's not, and Emacs wouldn't know the difference anyway, so oops".

See above.

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Sun, 10 Nov 2019 09:59:14 +0900
> 
> For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like
> 
> 1114111 (#o4177777, #x10ffff, t)
> 
> 232 (#o350, #xe8, t)
> 
> or something similar where t is the value of characterp for that integer when the integer is above the value of eval-expression-print-maximum-character.

IMO, this would be extremely confusing.  We don't have any other APIs
like that, and using characterp in this case,m if appropriate, is very
easy.

So I very much dislike this proposal, especially since the solution is
easy, and was already pointed out: customize that option.

Re: evaluating numbers

[Yuri Khan]

On Thu, 14 Nov 2019 at 16:26, Eli Zaretskii <eliz@gnu.org> wrote:

> > For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like
> >
> > 1114111 (#o4177777, #x10ffff, t)
> >
> > 232 (#o350, #xe8, t)
> >
> > or something similar where t is the value of characterp for that integer when the integer is above the value of eval-expression-print-maximum-character.
>
> IMO, this would be extremely confusing.  We don't have any other APIs
> like that, and using characterp in this case, if appropriate, is very
> easy.

A non-confusing solution to the issue “I have a code point and I’d
like to know which character that is, but I don’t want Emacs to spend
time trying all fonts to see if any of them has a glyph” could be to
show the Unicode name for code points greater than
eval-expression-print-maximum-character and less than (max-char).

    232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
    1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 14, 2019, at 18:20, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> It's neither, because characters are integers in Emacs, and a
> character is identical to its codepoint.

How can I understand that ?
I mean, what part of the documentation, or the code, or anything, is there to help people grasp this notion ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 14, 2019, at 18:46, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> 
> On Thu, 14 Nov 2019 at 16:26, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>>> For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like
>>> 
>>> 1114111 (#o4177777, #x10ffff, t)
>>> 
>>> 232 (#o350, #xe8, t)
>>> 
>>> or something similar where t is the value of characterp for that integer when the integer is above the value of eval-expression-print-maximum-character.
>> 
>> IMO, this would be extremely confusing.  We don't have any other APIs
>> like that, and using characterp in this case, if appropriate, is very
>> easy.
> 
> A non-confusing solution to the issue “I have a code point and I’d
> like to know which character that is, but I don’t want Emacs to spend
> time trying all fonts to see if any of them has a glyph” could be to
> show the Unicode name for code points greater than
> eval-expression-print-maximum-character and less than (max-char).
> 
>    232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
>    1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)

Yes !!! :)


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 12 Nov 2019 22:28:41 +0200
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>,
>  Emacs development discussions <emacs-devel@gnu.org>
> 
> -  :type 'integer
> +  :type `(choice (const :tag "ASCII characters" 127)
> +                 (const :tag "Maximum number" ,(max-char))

This is sub-optimal, because it leaves the meaning of "maximum number"
unclear.  I suggest "Any character" or "No limitation" instead.

> +                 (integer :tag "Custom number"))

And here, I'd suggest "Max codepoint to display as character" instead.

Thanks.

Re: evaluating numbers

[Noam Postavsky]

On Thu, 14 Nov 2019 at 06:35, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> > On Nov 14, 2019, at 18:20, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > It's neither, because characters are integers in Emacs, and a
> > character is identical to its codepoint.
>
> How can I understand that ?
> I mean, what part of the documentation, or the code, or anything, is there to help people grasp this notion ?

(info "(elisp) String Basics")

4.1 String and Character Basics
===============================

A character is a Lisp object which represents a single character of
text.  In Emacs Lisp, characters are simply integers; whether an
integer is a character or not is determined only by how it is used.
*Note Character Codes::, for details about character representation in
Emacs.

Re: evaluating numbers

[Stefan Monnier]

> No. I'm suggesting that the developer who wrote that code and that
> documentation is creating expectations by using the word "character" and
> thus could have implemented the function so that it returns a "character",
> or a "glyph" (which are synonymous) and not only its code point.

Emacs Lisp doesn't have a separate "character" data type (contrary to
XEmacs) and uses their integer code points for that instead.

As for glyphs, we do have some such notion, but it's different from
a character so wouldn't be appropriate here either.

>> For "discoverability" (or "cognitive gap reduction") purposes, I'd rather have something like
>> 1114111 (#o4177777, #x10ffff, t)

Maybe it would be helpful to you, but I don't think it will be helpful
in general.  The naive user will just wonder why there's a "t" in there
(I can already foresee the questions and discussions on gnu.emacs.help
and friends).  And in my experience it's extremely rare to have to
wonder "is this integer a valid char".  So adding a ", t" for this very
rare situation doesn't make much sense.


        Stefan

Re: evaluating numbers

[Stefan Monnier]

> A non-confusing solution to the issue “I have a code point and I’d
> like to know which character that is, but I don’t want Emacs to spend
> time trying all fonts to see if any of them has a glyph” could be to
> show the Unicode name for code points greater than
> eval-expression-print-maximum-character and less than (max-char).
>
>     232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
>     1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)

To the extent that "LATIN SMALL LETTER E WITH GRAVE" can't be used to
write 232 I don't like this suggestion, but I think you're on to
something: what if eval-expression-print-maximum-character was used only
to decide between `?<CHAR>` and `?\u<HEX>` ?


        Stefan

Re: evaluating numbers

[Noam Postavsky]

On Thu, 14 Nov 2019 at 08:55, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > A non-confusing solution to the issue “I have a code point and I’d
> > like to know which character that is, but I don’t want Emacs to spend
> > time trying all fonts to see if any of them has a glyph” could be to
> > show the Unicode name for code points greater than
> > eval-expression-print-maximum-character and less than (max-char).
> >
> >     232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
> >     1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)
>
> To the extent that "LATIN SMALL LETTER E WITH GRAVE" can't be used to
> write 232 I don't like this suggestion,

Actually ?\N{LATIN SMALL LETTER E WITH GRAVE} seems to work.

Re: evaluating numbers

[Andreas Schwab]

On Nov 14 2019, Stefan Monnier wrote:

> to decide between `?<CHAR>` and `?\u<HEX>` ?

There is no point in ?\u<HEX> if you already have #x<HEX>

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: evaluating numbers

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 14 Nov 2019 16:46:21 +0700
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Thu, 14 Nov 2019 at 16:26, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> A non-confusing solution to the issue “I have a code point and I’d
> like to know which character that is, but I don’t want Emacs to spend
> time trying all fonts to see if any of them has a glyph” could be to
> show the Unicode name for code points greater than
> eval-expression-print-maximum-character and less than (max-char).
> 
>     232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
>     1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)

I don't think this is less confusing, and I'm not really interested in
opening that old debate again.  The train has left the station, so
people who are unhappy with the current defaults should customize the
option we provided back then.

Re: evaluating numbers

[Stefan Monnier]

> Actually ?\N{LATIN SMALL LETTER E WITH GRAVE} seems to work.

Indeed, that works for me!


        Stefan

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Thu, 14 Nov 2019 20:35:17 +0900
> 
> > It's neither, because characters are integers in Emacs, and a
> > character is identical to its codepoint.
> 
> How can I understand that ?

By reading the documentation, of course.

> I mean, what part of the documentation, or the code, or anything, is there to help people grasp this notion ?

ELisp section "String and Character Basics":

  A character is a Lisp object which represents a single character of
  text.  In Emacs Lisp, characters are simply integers; whether an integer
  is a character or not is determined only by how it is used.  *Note
  Character Codes::, for details about character representation in Emacs.

And the cross-reference leads you to a much more detailed description
of these issues.

Re: evaluating numbers

[Paul Eggert]

On 11/14/19 6:10 AM, Eli Zaretskii wrote:
>>      232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
>>      1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)
> I don't think this is less confusing, and I'm not really interested in
> opening that old debate again.  The train has left the station, so
> people who are unhappy with the current defaults should customize the
> option we provided back then.

Although I agree this topic has been discussed a lot, I wouldn't be so 
hasty to reject Yuri's suggestion. I don't see how to customize Emacs so 
that eval-expression outputs a string like "232 (#o350, #xe8, LATIN 
SMALL LETTER E WITH GRAVE)". The behavior that Yuri's suggesting would 
be more convenient to me than what Emacs currently does, as I often deal 
with characters where it's more important to know the character's name 
than what it looks like. I don't see the harm of adding this feature to 
eval-expression by default, or at least as an option.

Re: evaluating numbers

[Eli Zaretskii]

> Cc: jean.christophe.helary@traduction-libre.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 14 Nov 2019 09:10:02 -0800
> 
> On 11/14/19 6:10 AM, Eli Zaretskii wrote:
> >>      232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
> >>      1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)
> > I don't think this is less confusing, and I'm not really interested in
> > opening that old debate again.  The train has left the station, so
> > people who are unhappy with the current defaults should customize the
> > option we provided back then.
> 
> Although I agree this topic has been discussed a lot, I wouldn't be so 
> hasty to reject Yuri's suggestion. I don't see how to customize Emacs so 
> that eval-expression outputs a string like "232 (#o350, #xe8, LATIN 
> SMALL LETTER E WITH GRAVE)". The behavior that Yuri's suggesting would 
> be more convenient to me than what Emacs currently does, as I often deal 
> with characters where it's more important to know the character's name 
> than what it looks like. I don't see the harm of adding this feature to 
> eval-expression by default, or at least as an option.

Sorry, I don't want to make user-visible enhancements in this feature
which has barely debuted.  I would like to collect more user input
first.

FWIW, my personal opinion is that it's jarring to see something like
"LATIN SMALL LETTER E WITH GRAVE" when all I asked was to evaluate an
integer expression.  (Showing the corresponding character is also
jarring, but it's much less prominent, and it was there for a long
time.)  So the next we will hear is how to customize this not to show
the character's name, etc. etc.  Let's stop the feature creep right
here, even though it's tempting (it always is).

Re: evaluating numbers

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 14 Nov 2019 09:10:02 -0800
> Cc: jean.christophe.helary@traduction-libre.org, emacs-devel@gnu.org
> 
> The behavior that Yuri's suggesting would be more convenient to me
> than what Emacs currently does, as I often deal with characters
> where it's more important to know the character's name than what it
> looks like.

The right way of doing this is "C-u C-x =".  And if we think that this
shows way too much info, I'm OK with modifying "C-x =" to show the
character name as an optional feature.  These are commands that were
specifically designed to describe text; doing that as part of integer
evaluation is too general for that.

Re: evaluating numbers

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 160 bytes --]

> Actually ?\N{LATIN SMALL LETTER E WITH GRAVE} seems to work.

Not to mention `insert-char':

C-x 8 <RET>  LATIN SMALL LETTER E WITH GRAVE <RET>

=> è

[-- Attachment #2: Type: text/html, Size: 249 bytes --]

Re: evaluating numbers

[Juri Linkov]

>> -  :type 'integer
>> +  :type `(choice (const :tag "ASCII characters" 127)
>> +                 (const :tag "Maximum number" ,(max-char))
>
> This is sub-optimal, because it leaves the meaning of "maximum number"
> unclear.  I suggest "Any character" or "No limitation" instead.
>
>> +                 (integer :tag "Custom number"))
>
> And here, I'd suggest "Max codepoint to display as character" instead.

Ok, will use this text.  But I have more doubts about using (max-char).
What if this .el is compiled on 64-bit, where a larger value of 'max-char'
will be saved to .elc, but loaded on 32-bit.  Will it fail to load such .elc?

Maybe instead of (max-char) it would be better to use the value 't'
to mean no limitation.  Then to check this value explicitly
in the implementation of 'eval-expression-print-format'.

Re: evaluating numbers

[Juri Linkov]

> A non-confusing solution to the issue “I have a code point and I’d
> like to know which character that is, but I don’t want Emacs to spend
> time trying all fonts to see if any of them has a glyph” could be to
> show the Unicode name for code points greater than
> eval-expression-print-maximum-character and less than (max-char).
>
>     232 (#o350, #xe8, LATIN SMALL LETTER E WITH GRAVE)
>     1114109 (#o4177775, #x10fffd, <Plane 16 Private Use>)

Good idea.  We definitely need an option to enable this
(its default value could be discussed separately).

Re: evaluating numbers

[Noam Postavsky]

On Thu, 14 Nov 2019 at 18:22, Juri Linkov <juri@linkov.net> wrote:

> Ok, will use this text.  But I have more doubts about using (max-char).
> What if this .el is compiled on 64-bit, where a larger value of 'max-char'
> will be saved to .elc, but loaded on 32-bit.  Will it fail to load such .elc?

The value of (max-char) is independent of bitness (unlike, say,
most-positive-fixnum).

Re: evaluating numbers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: schwab@linux-m68k.org,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org
> Date: Fri, 15 Nov 2019 00:50:55 +0200
> 
> Ok, will use this text.  But I have more doubts about using (max-char).
> What if this .el is compiled on 64-bit, where a larger value of 'max-char'
> will be saved to .elc, but loaded on 32-bit.  Will it fail to load such .elc?

max-char yields a 22-bit value, so it fits an integer in any Emacs
build.

> Maybe instead of (max-char) it would be better to use the value 't'
> to mean no limitation.  Then to check this value explicitly
> in the implementation of 'eval-expression-print-format'.

IMO, that'd be over-engineering, since the max Unicode codepoint is
unlikely to change any time soon.

Re: evaluating numbers

[Štěpán Němec]

On Thu, 14 Nov 2019 20:39:44 +0200
Eli Zaretskii wrote:

>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Thu, 14 Nov 2019 09:10:02 -0800
>> Cc: jean.christophe.helary@traduction-libre.org, emacs-devel@gnu.org
>> 
>> The behavior that Yuri's suggesting would be more convenient to me
>> than what Emacs currently does, as I often deal with characters
>> where it's more important to know the character's name than what it
>> looks like.
>
> The right way of doing this is "C-u C-x =".  And if we think that this
> shows way too much info, I'm OK with modifying "C-x =" to show the
> character name as an optional feature.

Although I don't really mind using C-u C-x = (I do it all the time),
having the character name in the single line info does seem sensible and
I for one would welcome such option. Or, when at it, maybe even a
`what-cursor-position-format' to customize the output further (e.g., I'm
not interested in position info as I have that in the mode-line
already).

-- 
Štěpán

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 14, 2019, at 23:20, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Thu, 14 Nov 2019 20:35:17 +0900
>> 
>>> It's neither, because characters are integers in Emacs, and a
>>> character is identical to its codepoint.
>> 
>> How can I understand that ?
> 
> By reading the documentation, of course.

I wish.

>> I mean, what part of the documentation, or the code, or anything, is there to help people grasp this notion ?
> 
> ELisp section "String and Character Basics":
> 
>  A character is a Lisp object which represents a single character of
>  text.  In Emacs Lisp, characters are simply integers; whether an integer
>  is a character or not is determined only by how it is used.  *Note
>  Character Codes::, for details about character representation in Emacs.
> 
> And the cross-reference leads you to a much more detailed description
> of these issues.


"In Emacs Lisp, characters are simply integers; whether an integer is a character or not is determined only by how it is used."

([Character Codes] has seemingly nothing relevant)


[Character Type]

"A character in Emacs Lisp is nothing more than an integer."
"In other words, characters are represented by their character codes."

"Since characters are really integers, the printed representation of a character is a decimal number."

(btw: "Emacs provides several types of escape syntax that you can use to specify non-ASCII text characters." is not true since *any* character can use those escape syntaxes.)

Whatever I read about characters starts with the statement "Characters are integers" or a differently worded equivalent.

There is nothing that says why or how.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 15 Nov 2019 19:36:21 +0900
> 
> Whatever I read about characters starts with the statement "Characters are integers" or a differently worded equivalent.
> 
> There is nothing that says why or how.

The answer to "why" is "because that's how characters are
implemented".  The answer to "how" is "by interpreting the integer as
character when the context requires that".

Re: evaluating numbers

[Robert Pluim]

>>>>> On Thu, 14 Nov 2019 20:39:44 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> The right way of doing this is "C-u C-x =".  And if we think that this
    Eli> shows way too much info, I'm OK with modifying "C-x =" to show the
    Eli> character name as an optional feature.  These are commands that were
    Eli> specifically designed to describe text; doing that as part of integer
    Eli> evaluation is too general for that.

I like my bikesheds painted in #ff7f00

(what-cursor-position could definitely benefit from some refactoring
of those format strings).

diff --git a/lisp/simple.el b/lisp/simple.el
index e3ac709408..a9d2a152dc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1389,6 +1389,12 @@ line-number-at-pos
         (forward-line 0)
         (1+ (count-lines start (point)))))))
 
+(defcustom what-cursor-show-names nil
+  "Whether to show character names in `what-cursor-position'."
+  :type 'boolean
+  :version "27.1"
+  :group 'editing-basics)
+
 (defun what-cursor-position (&optional detail)
   "Print info on cursor position (on screen and within buffer).
 Also describe the character after point, and give its character code
@@ -1404,6 +1410,9 @@ what-cursor-position
 in *Help* buffer.  See also the command `describe-char'."
   (interactive "P")
   (let* ((char (following-char))
+         (char-name-fmt (if what-cursor-show-names
+                            (format ", ?\\N{%s}" (get-char-code-property char 'name))
+                          ""))
 	 (bidi-fixer
 	  ;; If the character is one of LRE, LRO, RLE, RLO, it will
 	  ;; start a directional embedding, which could completely
@@ -1449,7 +1458,7 @@ what-cursor-position
 	    (setq coding (default-value 'buffer-file-coding-system)))
 	(if (eq (char-charset char) 'eight-bit)
 	    (setq encoding-msg
-		  (format "(%d, #o%o, #x%x, raw-byte)" char char char))
+		  (format "(%d, #o%o, #x%x%s, raw-byte)" char char char char-name-fmt))
 	  ;; Check if the character is displayed with some `display'
 	  ;; text property.  In that case, set under-display to the
 	  ;; buffer substring covered by that property.
@@ -1468,17 +1477,17 @@ what-cursor-position
 	  (setq encoding-msg
 		(if display-prop
 		    (if (not (stringp display-prop))
-			(format "(%d, #o%o, #x%x, part of display \"%s\")"
-				char char char under-display)
-		      (format "(%d, #o%o, #x%x, part of display \"%s\"->\"%s\")"
-			      char char char under-display display-prop))
+			(format "(%d, #o%o, #x%x%s, part of display \"%s\")"
+				char char char char-name-fmt under-display)
+		      (format "(%d, #o%o, #x%x%s, part of display \"%s\"->\"%s\")"
+			      char char char char-name-fmt under-display display-prop))
 		  (if encoded
-		      (format "(%d, #o%o, #x%x, file %s)"
-			      char char char
+		      (format "(%d, #o%o, #x%x%s, file %s)"
+			      char char char char-name-fmt
 			      (if (> (length encoded) 1)
 				  "..."
 				(encoded-string-description encoded coding)))
-		    (format "(%d, #o%o, #x%x)" char char char)))))
+		    (format "(%d, #o%o, #x%x%s)" char char char char-name-fmt)))))
 	(if detail
 	    ;; We show the detailed information about CHAR.
 	    (describe-char (point)))

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
>   jean.christophe.helary@traduction-libre.org,  emacs-devel@gnu.org,
>   yuri.v.khan@gmail.com
> Date: Fri, 15 Nov 2019 15:54:46 +0100
>
> I like my bikesheds painted in #ff7f00

SGTM, thanks.

> +         (char-name-fmt (if what-cursor-show-names
> +                            (format ", ?\\N{%s}" (get-char-code-property char 'name))

What does this yield for codepoints below 32 decimal?

Re: evaluating numbers

[Eli Zaretskii]

> Date: Fri, 15 Nov 2019 17:16:38 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jean.christophe.helary@traduction-libre.org, yuri.v.khan@gmail.com,
>  eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > +         (char-name-fmt (if what-cursor-show-names
> > +                            (format ", ?\\N{%s}" (get-char-code-property char 'name))
> 
> What does this yield for codepoints below 32 decimal?

And, btw, why the ?\N{} part? why not just show the name?

Re: evaluating numbers

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 17:16:38 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Paul Eggert <eggert@cs.ucla.edu>,
    >> jean.christophe.helary@traduction-libre.org,  emacs-devel@gnu.org,
    >> yuri.v.khan@gmail.com
    >> Date: Fri, 15 Nov 2019 15:54:46 +0100
    >> 
    >> I like my bikesheds painted in #ff7f00

    Eli> SGTM, thanks.

    >> +         (char-name-fmt (if what-cursor-show-names
    >> +                            (format ", ?\\N{%s}" (get-char-code-property char 'name))

    Eli> What does this yield for codepoints below 32 decimal?

Hmm, they donʼt have a 'name property? I guess we could do

(or (get-char-code-property char 'name) (get-char-code-property char 'old-name))

Robert

Re: evaluating numbers

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 17:32:04 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Fri, 15 Nov 2019 17:16:38 +0200
    >> From: Eli Zaretskii <eliz@gnu.org>
    >> Cc: jean.christophe.helary@traduction-libre.org, yuri.v.khan@gmail.com,
    >> eggert@cs.ucla.edu, emacs-devel@gnu.org
    >> 
    >> > +         (char-name-fmt (if what-cursor-show-names
    >> > +                            (format ", ?\\N{%s}" (get-char-code-property char 'name))
    >> 
    >> What does this yield for codepoints below 32 decimal?

    Eli> And, btw, why the ?\N{} part? why not just show the name?

So that people can directly use it elsewhere, without having to do C-x
8 RET. But itʼs a minor detail, Iʼm certainly not wedded to it.

Robert

Re: evaluating numbers

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 16:55:13 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Fri, 15 Nov 2019 17:32:04 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >>> Date: Fri, 15 Nov 2019 17:16:38 +0200
    >>> From: Eli Zaretskii <eliz@gnu.org>
    >>> Cc: jean.christophe.helary@traduction-libre.org, yuri.v.khan@gmail.com,
    >>> eggert@cs.ucla.edu, emacs-devel@gnu.org
    >>> 
    >>> > +         (char-name-fmt (if what-cursor-show-names
    >>> > +                            (format ", ?\\N{%s}" (get-char-code-property char 'name))
    >>> 
    >>> What does this yield for codepoints below 32 decimal?

    Eli> And, btw, why the ?\N{} part? why not just show the name?

    Robert> So that people can directly use it elsewhere, without having to do C-x
    Robert> 8 RET. But itʼs a minor detail, Iʼm certainly not wedded to it.

Actually, thatʼs a totally bogus reason, since this all ends up in the
echo area, and itʼs not done for the other representations. Removed.

Robert

Re: evaluating numbers

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Actually, thatʼs a totally bogus reason, since this all ends up in the
> echo area, and itʼs not done for the other representations. Removed.

I thought it made sense -- you could skip to the *Messages* buffer and
kill any of the four representations and then M-: (insert C-y ) RET and
insert the character in the buffer.

If the ?\N{...} isn't there, you can't do that with the fourth
representation.

And it's also nice as a discoverability thing, since I'd guess most
people don't know about that representation.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: eggert@cs.ucla.edu,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org,  yuri.v.khan@gmail.com
> Date: Fri, 15 Nov 2019 16:53:11 +0100
> 
>     Eli> What does this yield for codepoints below 32 decimal?
> 
> Hmm, they donʼt have a 'name property?

Nope.  Control characters don't.

> I guess we could do
> 
> (or (get-char-code-property char 'name) (get-char-code-property char 'old-name))

Yes.

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jean.christophe.helary@traduction-libre.org,  yuri.v.khan@gmail.com,
>   eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Fri, 15 Nov 2019 16:55:13 +0100
> 
>     Eli> And, btw, why the ?\N{} part? why not just show the name?
> 
> So that people can directly use it elsewhere, without having to do C-x
> 8 RET. But itʼs a minor detail, Iʼm certainly not wedded to it.

It looks a bit too much.  But maybe I'm the only one bothered by that.

Re: evaluating numbers

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 17:11:14 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Actually, thatʼs a totally bogus reason, since this all ends up in the
    >> echo area, and itʼs not done for the other representations. Removed.

    Lars> I thought it made sense -- you could skip to the *Messages* buffer and
    Lars> kill any of the four representations and then M-: (insert C-y ) RET and
    Lars> insert the character in the buffer.

    Lars> If the ?\N{...} isn't there, you can't do that with the fourth
    Lars> representation.

You can skip to the *Messages* buffer, kill 3 of the 4
representations, and do C-x 8 RET C-y if the ?\N{...} isnʼt there,
which I think is shorter. Of course, since this is all about the
output from "C-x =", you could just copy the character you already
have in the buffer :-)

    Lars> And it's also nice as a discoverability thing, since I'd guess most
    Lars> people don't know about that representation.

That I canʼt deny. Iʼll add in (info "(elisp) General Escape Syntax") in
my next patch ;-)

Robert

Re: evaluating numbers

[Robert Pluim]

>>>>> On Fri, 15 Nov 2019 18:13:09 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: eggert@cs.ucla.edu,  jean.christophe.helary@traduction-libre.org,
    >> emacs-devel@gnu.org,  yuri.v.khan@gmail.com
    >> Date: Fri, 15 Nov 2019 16:53:11 +0100
    >> 
    Eli> What does this yield for codepoints below 32 decimal?
    >> 
    >> Hmm, they donʼt have a 'name property?

    Eli> Nope.  Control characters don't.

    >> I guess we could do
    >> 
    >> (or (get-char-code-property char 'name) (get-char-code-property char 'old-name))

    Eli> Yes.

And the characters that have neither? #x80, #x81, #x84, and #x99 by my
reckoning.

Robert

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: eggert@cs.ucla.edu,  jean.christophe.helary@traduction-libre.org,
>   emacs-devel@gnu.org,  yuri.v.khan@gmail.com
> Date: Fri, 15 Nov 2019 17:43:03 +0100
> 
>     >> (or (get-char-code-property char 'name) (get-char-code-property char 'old-name))
> 
>     Eli> Yes.
> 
> And the characters that have neither? #x80, #x81, #x84, and #x99 by my
> reckoning.

Don't display anything, I guess?

Re: evaluating numbers

[Juri Linkov]

> The right way of doing this is "C-u C-x =".  And if we think that this
> shows way too much info, I'm OK with modifying "C-x =" to show the
> character name as an optional feature.  These are commands that were
> specifically designed to describe text; doing that as part of integer
> evaluation is too general for that.

There are other cases where displaying Unicode names might be needed
in the echo area, e.g. sometimes using query-replace to strip accents
messes the prompt with combining accent characters stacked on each other
that enlarges the minibuffer window:

  Query replace regexp (default [́̀̂] → ):

Wouldn't such prompt be more readable?

  Query replace regexp (default [?\N{COMBINING ACUTE ACCENT}] → ):

Re: evaluating numbers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And, btw, why the ?\N{} part? why not just show the name?

{} makes it easier for people to see where that name starts and ends.
I think that is a good convenience.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: evaluating numbers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
>   jean.christophe.helary@traduction-libre.org,  emacs-devel@gnu.org,
>   yuri.v.khan@gmail.com
> Date: Sat, 16 Nov 2019 22:40:42 +0200
> 
> > The right way of doing this is "C-u C-x =".  And if we think that this
> > shows way too much info, I'm OK with modifying "C-x =" to show the
> > character name as an optional feature.  These are commands that were
> > specifically designed to describe text; doing that as part of integer
> > evaluation is too general for that.
> 
> There are other cases where displaying Unicode names might be needed
> in the echo area, e.g. sometimes using query-replace to strip accents
> messes the prompt with combining accent characters stacked on each other
> that enlarges the minibuffer window:
> 
>   Query replace regexp (default [́̀̂] → ):

This is a bug in the command that issues the prompt: it should
insulate the combining characters so that they don't combine with the
brackets.  But that might be a separate issue.

> Wouldn't such prompt be more readable?
> 
>   Query replace regexp (default [?\N{COMBINING ACUTE ACCENT}] → ):

The original prompt had 3 characters, but in the latter you show only
one.  How is this the same?  And even one character takes a lot of
screen estate, so imagine how it will look with 3.  Doesn't sound like
a good idea.

Though we might provide a separate feature: a minor mode whereby
hovering the mouse over a character shows its name in a tooltip.  But
using the minibuffer for that is not something I like.

Re: evaluating numbers

[Robert Pluim]

>>>>> On Sat, 16 Nov 2019 21:15:33 -0500, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> And, btw, why the ?\N{} part? why not just show the name?

    Richard> {} makes it easier for people to see where that name starts and ends.
    Richard> I think that is a good convenience.

We could just as easily enclose the name in quotes. Using ?\N{}
informs people about that syntax. Personally Iʼm neutral on it, so
Iʼll go with whatever Eli decides.

Robert

Re: evaluating numbers

[Juri Linkov]

>> Wouldn't such prompt be more readable?
>>
>>   Query replace regexp (default [?\N{COMBINING ACUTE ACCENT}] → ):
>
> The original prompt had 3 characters, but in the latter you show only
> one.  How is this the same?  And even one character takes a lot of
> screen estate, so imagine how it will look with 3.  Doesn't sound like
> a good idea.

Yes, more characters would make the prompt too long.  Maybe using
multi-line rx expressions in regexp prompts would help a bit:

(rx (any ?\N{COMBINING ACUTE ACCENT}
         ?\N{COMBINING GRAVE ACCENT}
         ?\N{COMBINING CIRCUMFLEX ACCENT}))
=> "[̀-̂]"

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>   jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
>   yuri.v.khan@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 17 Nov 2019 21:02:02 +0100
> 
>     >> And, btw, why the ?\N{} part? why not just show the name?
> 
>     Richard> {} makes it easier for people to see where that name starts and ends.
>     Richard> I think that is a good convenience.
> 
> We could just as easily enclose the name in quotes. Using ?\N{}
> informs people about that syntax. Personally Iʼm neutral on it, so
> Iʼll go with whatever Eli decides.

If we want a clear indication where the name starts and ends, it's
better to use ("..."), i.e. just parentheses.

Re: evaluating numbers

[Robert Pluim]

>>>>> On Mon, 18 Nov 2019 18:25:47 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,
    >> jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
    >> yuri.v.khan@gmail.com,  emacs-devel@gnu.org
    >> Date: Sun, 17 Nov 2019 21:02:02 +0100
    >> 
    >> >> And, btw, why the ?\N{} part? why not just show the name?
    >> 
    Richard> {} makes it easier for people to see where that name starts and ends.
    Richard> I think that is a good convenience.
    >> 
    >> We could just as easily enclose the name in quotes. Using ?\N{}
    >> informs people about that syntax. Personally Iʼm neutral on it, so
    >> Iʼll go with whatever Eli decides.

    Eli> If we want a clear indication where the name starts and ends, it's
    Eli> better to use ("..."), i.e. just parentheses.

Char: i (105, #o151, #x69, (LATIN SMALL LETTER I)) point=55242 of 379127 (15%) column=43

That seems ... suboptimal to me (at least, I donʼt like it).

Robert

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org,  rms@gnu.org,  yuri.v.khan@gmail.com
> Date: Mon, 18 Nov 2019 17:54:18 +0100
> 
> Char: i (105, #o151, #x69, (LATIN SMALL LETTER I)) point=55242 of 379127 (15%) column=43
> 
> That seems ... suboptimal to me (at least, I donʼt like it).

Fine, then let's go with just the name.

Thanks.

Re: evaluating numbers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We could just as easily enclose the name in quotes.

That might complicate Lisp mode parsing of Lisp code, if we give more
meanings to quotes.  For instance, if we want the \N syntax to be used
inside a string constant, using doublequotes for this would cause complicaions.
Using singlequotes would cause other complications.
-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: evaluating numbers

[Robert Pluim]

>>>>> On Tue, 19 Nov 2019 01:08:14 -0500, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> We could just as easily enclose the name in quotes.

    Richard> That might complicate Lisp mode parsing of Lisp code, if we give more
    Richard> meanings to quotes.  For instance, if we want the \N syntax to be used
    Richard> inside a string constant, using doublequotes for this would cause complicaions.
    Richard> Using singlequotes would cause other complications.

Iʼm not following. This is about the output of `what-cursor-position',
itʼs not about changing the existing ?\N{} syntax, which I donʼt think
anyone has proposed.

Robert

Re: evaluating numbers

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

>>>>> On Mon, 18 Nov 2019 19:05:37 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
    >> emacs-devel@gnu.org,  rms@gnu.org,  yuri.v.khan@gmail.com
    >> Date: Mon, 18 Nov 2019 17:54:18 +0100
    >> 
    >> Char: i (105, #o151, #x69, (LATIN SMALL LETTER I)) point=55242 of 379127 (15%) column=43
    >> 
    >> That seems ... suboptimal to me (at least, I donʼt like it).

    Eli> Fine, then let's go with just the name.

Latest version attached, which produces output like so:

Char: i (105, #o151, #x69, LATIN SMALL LETTER I) point=1482 of 1715 (86%) <860-1716> column=13

Iʼll push this weekend if everyone's ok with it.

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Have-what-cursor-position-optionally-show-character-.patch --]
[-- Type: text/x-patch, Size: 5144 bytes --]

From 8f8a3888439d959cff60a0cdea2070b1d3ebc15d Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Tue, 19 Nov 2019 11:33:10 +0100
Subject: [PATCH] Have what-cursor-position optionally show character name
To: emacs-devel@gnu.org

* lisp/simple.el (what-cursor-show-names): New defcustom, default nil.
(what-cursor-position): Show character names if what-cursor-show-names
is non-nil.

* doc/emacs/basic.texi (Position Info): Add what-cursor-show-names
description.

* etc/NEWS: Announce what-cursor-show-names.
---
 doc/emacs/basic.texi | 10 ++++++++++
 etc/NEWS             |  5 +++++
 lisp/simple.el       | 31 ++++++++++++++++++++++---------
 3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/doc/emacs/basic.texi b/doc/emacs/basic.texi
index d0bd46c35f..79a546f9e7 100644
--- a/doc/emacs/basic.texi
+++ b/doc/emacs/basic.texi
@@ -696,6 +696,16 @@ Position Info
 horizontal position of point, in columns counting from the left edge
 of the window.
 
+@vindex what-cursor-show-names
+  If the user option @code{what-cursor-show-names} is non-@code{nil},
+the name of the character is shown as well, so the part in parentheses
+would become:
+
+@smallexample
+(99, #o143, #x63, LATIN SMALL LETTER C)
+@end smallexample
+
+
   If the buffer has been narrowed, making some of the text at the
 beginning and the end temporarily inaccessible, @kbd{C-x =} displays
 additional text describing the currently accessible range.  For
diff --git a/etc/NEWS b/etc/NEWS
index 4887b8e681..fdfe2d8692 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -231,6 +231,11 @@ To get the old, less-secure behavior, you can set the
 *** When run by root, emacsclient no longer connects to non-root sockets.
 (Instead you can use Tramp methods to run root commands in a non-root Emacs.)
 
++++
+** New user option 'what-cursor-show-names'.
+When non-nil, what-cursor-position will show the name of the character
+in addition to the decimal/hex/octal representation. Default nil.
+
 +++
 ** New function 'network-lookup-address-info'.
 This does IPv4 and/or IPv6 address lookups on hostnames.
diff --git a/lisp/simple.el b/lisp/simple.el
index c61ccd511c..a63f2552df 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1389,10 +1389,17 @@ line-number-at-pos
         (forward-line 0)
         (1+ (count-lines start (point)))))))
 
+(defcustom what-cursor-show-names nil
+  "Whether to show character names in `what-cursor-position'."
+  :type 'boolean
+  :version "27.1"
+  :group 'editing-basics)
+
 (defun what-cursor-position (&optional detail)
   "Print info on cursor position (on screen and within buffer).
-Also describe the character after point, and give its character code
-in octal, decimal and hex.
+Also describe the character after point, and give its character
+code in octal, decimal and hex, plus its name if
+`what-cursor-show-names' is non-nil.
 
 For a non-ASCII multibyte character, also give its encoding in the
 buffer's selected coding system if the coding system encodes the
@@ -1404,6 +1411,12 @@ what-cursor-position
 in *Help* buffer.  See also the command `describe-char'."
   (interactive "P")
   (let* ((char (following-char))
+         (char-name (and what-cursor-show-names
+                         (or (get-char-code-property char 'name)
+                             (get-char-code-property char 'old-name))))
+         (char-name-fmt (if char-name
+                            (format ", %s" char-name)
+                          ""))
 	 (bidi-fixer
 	  ;; If the character is one of LRE, LRO, RLE, RLO, it will
 	  ;; start a directional embedding, which could completely
@@ -1449,7 +1462,7 @@ what-cursor-position
 	    (setq coding (default-value 'buffer-file-coding-system)))
 	(if (eq (char-charset char) 'eight-bit)
 	    (setq encoding-msg
-		  (format "(%d, #o%o, #x%x, raw-byte)" char char char))
+		  (format "(%d, #o%o, #x%x%s, raw-byte)" char char char char-name-fmt))
 	  ;; Check if the character is displayed with some `display'
 	  ;; text property.  In that case, set under-display to the
 	  ;; buffer substring covered by that property.
@@ -1468,17 +1481,17 @@ what-cursor-position
 	  (setq encoding-msg
 		(if display-prop
 		    (if (not (stringp display-prop))
-			(format "(%d, #o%o, #x%x, part of display \"%s\")"
-				char char char under-display)
-		      (format "(%d, #o%o, #x%x, part of display \"%s\"->\"%s\")"
-			      char char char under-display display-prop))
+			(format "(%d, #o%o, #x%x%s, part of display \"%s\")"
+				char char char char-name-fmt under-display)
+		      (format "(%d, #o%o, #x%x%s, part of display \"%s\"->\"%s\")"
+			      char char char char-name-fmt under-display display-prop))
 		  (if encoded
-		      (format "(%d, #o%o, #x%x, file %s)"
+		      (format "(%d, #o%o, #x%x%s, file %s)"
 			      char char char
 			      (if (> (length encoded) 1)
 				  "..."
 				(encoded-string-description encoded coding)))
-		    (format "(%d, #o%o, #x%x)" char char char)))))
+		    (format "(%d, #o%o, #x%x%s)" char char char char-name-fmt)))))
 	(if detail
 	    ;; We show the detailed information about CHAR.
 	    (describe-char (point)))
-- 
2.23.0

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org,  rms@gnu.org,  yuri.v.khan@gmail.com
> Date: Wed, 20 Nov 2019 14:00:16 +0100
> 
> Latest version attached, which produces output like so:
> 
> Char: i (105, #o151, #x69, LATIN SMALL LETTER I) point=1482 of 1715 (86%) <860-1716> column=13

LGTM.

> +@vindex what-cursor-show-names
> +  If the user option @code{what-cursor-show-names} is non-@code{nil},
> +the name of the character is shown as well, so the part in parentheses

I'd qualify "the name of the character" somehow, so that people
understand where we get the name, and why it is in all-caps.  For
example:

  ...the name of the character as defined by the Unicode Character
  Database...

> +** New user option 'what-cursor-show-names'.
> +When non-nil, what-cursor-position will show the name of the character
                 ^^^^^^^^^^^^^^^^^^^^
Please quote symbol names in NEWS.

> +in addition to the decimal/hex/octal representation. Default nil.
                                                      ^^
Two spaces.

> +Also describe the character after point, and give its character
> +code in octal, decimal and hex, plus its name if
> +`what-cursor-show-names' is non-nil.

I wonder if non-native English speakers will understand that the part
after "if" is only about the name.

Thanks.

Re: evaluating numbers

[Robert Pluim]

>>>>> On Wed, 20 Nov 2019 18:40:12 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli>   ...the name of the character as defined by the Unicode Character
    Eli>   Database...

Done

    >> +** New user option 'what-cursor-show-names'.
    >> +When non-nil, what-cursor-position will show the name of the character
    Eli>                  ^^^^^^^^^^^^^^^^^^^^
    Eli> Please quote symbol names in NEWS.

Done

    >> +in addition to the decimal/hex/octal representation. Default nil.
    Eli>                                                       ^^
    Eli> Two spaces.

Done (do we have a checkdoc-like mode for NEWS?).

    >> +Also describe the character after point, and give its character
    >> +code in octal, decimal and hex, plus its name if
    >> +`what-cursor-show-names' is non-nil.

    Eli> I wonder if non-native English speakers will understand that the part
    Eli> after "if" is only about the name.

Good point.

    Also describe the character after point, and give its character
    code in octal, decimal and hex. If `what-cursor-show-names' is
    non-nil, additionally show the name of the character.

(I donʼt really want to say 'also' again)

Robert

Re: evaluating numbers

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jean.christophe.helary@traduction-libre.org,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org,  rms@gnu.org,  yuri.v.khan@gmail.com
> Date: Wed, 20 Nov 2019 18:09:31 +0100
> 
>     Also describe the character after point, and give its character
>     code in octal, decimal and hex. If `what-cursor-show-names' is
>     non-nil, additionally show the name of the character.

Great, thanks.

Re: evaluating numbers

[Jean-Christophe Helary]

> On Nov 15, 2019, at 22:03, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Fri, 15 Nov 2019 19:36:21 +0900
>> 
>> Whatever I read about characters starts with the statement "Characters are integers" or a differently worded equivalent.
>> 
>> There is nothing that says why or how.
> 
> The answer to "why" is "because that's how characters are
> implemented".  The answer to "how" is "by interpreting the integer as
> character when the context requires that".

I'm sorry to get back to this now, but I'm reading an introduction to C in French where I found:

"Une des particularités du type char en C est qu’il peut être assimilé à un entier: tout objet de type char peut être utilisé dans une expression qui utilise des objets de type entier. Par exemple, si c est de type char, l’expression c + 1 est valide."

Is that the reason why characters are integers in emacs lisp too ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Tue, 28 Apr 2020 23:52:48 +0900
> 
> > The answer to "why" is "because that's how characters are
> > implemented".  The answer to "how" is "by interpreting the integer as
> > character when the context requires that".
> 
> I'm sorry to get back to this now, but I'm reading an introduction to C in French where I found:
> 
> "Une des particularités du type char en C est qu’il peut être assimilé à un entier: tout objet de type char peut être utilisé dans une expression qui utilise des objets de type entier. Par exemple, si c est de type char, l’expression c + 1 est valide."
> 
> Is that the reason why characters are integers in emacs lisp too ?

If you are asking why this happened historically, then I don't know: I
wasn't there.  Maybe Richard can answer that.

Re: evaluating numbers

[Paul Eggert]

>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Tue, 28 Apr 2020 23:52:48 +0900

>> I'm sorry to get back to this now, but I'm reading an introduction to C in French where I found:
>>
>> "Une des particularités du type char en C est qu’il peut être assimilé à un entier: tout objet de type char peut être utilisé dans une expression qui utilise des objets de type entier. Par exemple, si c est de type char, l’expression c + 1 est valide."
>>
>> Is that the reason why characters are integers in emacs lisp too ?

Surely not. Maclisp (which predates C) also represented characters as fixnums:
Maclisp #/x was equivalent to Emacs Lisp ?x. So the heritage runs through
Cambridge, not through Murray Hill.

Disclaimer: I never used Maclisp (I jumped straight from Lisp 1.5 to Emacs Lisp
and Scheme) and of course Richard is the authority here.

Re: evaluating numbers

[Jean-Christophe Helary]

Paul, Eli, thank you for the replies.

> On Apr 29, 2020, at 0:05, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Tue, 28 Apr 2020 23:52:48 +0900
>> 
>>> The answer to "why" is "because that's how characters are
>>> implemented".  The answer to "how" is "by interpreting the integer as
>>> character when the context requires that".
>> 
>> I'm sorry to get back to this now, but I'm reading an introduction to C in French where I found:
>> 
>> "Une des particularités du type char en C est qu’il peut être assimilé à un entier: tout objet de type char peut être utilisé dans une expression qui utilise des objets de type entier. Par exemple, si c est de type char, l’expression c + 1 est valide."
>> 
>> Is that the reason why characters are integers in emacs lisp too ?
> 
> If you are asking why this happened historically, then I don't know: I
> wasn't there.  Maybe Richard can answer that.

@Eli Maybe historically but also generally speaking, is it more convenient to implement characters as integers because that was the way it is done in other languages like C (which plays an important part in Emacs) ?

@Paul I was asking about C because it seems to me that this part of emacs lisp is implemented in C, so if C does that then my uninformed idea is that it's easier create a similar implementation for emacslisp ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Paul Eggert]

On 4/28/20 4:16 PM, Jean-Christophe Helary wrote:
> @Paul I was asking about C because it seems to me that this part of emacs lisp is implemented in C, so if C does that then my uninformed idea is that it's easier create a similar implementation for emacslisp ?

It's a bit simpler for the C interpreter to treat characters as integers, but
it's not simpler enough that it makes a significant difference.

The main idea, I expect, was that Emacs Lisp programs would be simpler and/or
more-compatible with other Lisp implementations and/or better in some other way;
any compatibility with C was secondary. But again, Richard is the authority here.

Re: evaluating numbers

[Jean-Christophe Helary]

Thank you Paul.

> On Apr 29, 2020, at 9:08, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 4/28/20 4:16 PM, Jean-Christophe Helary wrote:
>> @Paul I was asking about C because it seems to me that this part of emacs lisp is implemented in C, so if C does that then my uninformed idea is that it's easier create a similar implementation for emacslisp ?
> 
> It's a bit simpler for the C interpreter to treat characters as integers, but
> it's not simpler enough that it makes a significant difference.
> 
> The main idea, I expect, was that Emacs Lisp programs would be simpler and/or
> more-compatible with other Lisp implementations and/or better in some other way;
> any compatibility with C was secondary. But again, Richard is the authority here.

It's just one of those itches that you scratch until it bleeds and then you realize that should have taken some time to just walk outside and take a deep breath ... :)

But if Richard has a concluding remark on that, I'd love to hear it.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is that the reason why characters are integers in emacs lisp too ?

  > If you are asking why this happened historically, then I don't know: I
  > wasn't there.  Maybe Richard can answer that.

I decided to represent characters using integers that just to keep
Emacs simple and small.  In the 1980s, people wanted to run Emacs on
machines with 1 meg of memory and a hard limit on process size.  I had
to work hard to make that operate at all.

A separate character type would have required a number of extra
conversion and test functions as well as read and print support.

Those space considerations are no longer significant.  But there may
be another problem: whether there is room in the representation of
Lisp_Object for another type.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: evaluating numbers

[Jean-Christophe Helary]

> On Apr 29, 2020, at 12:23, Richard Stallman <rms@gnu.org> wrote:
> 
>>> Is that the reason why characters are integers in emacs lisp too ?
> 
>> If you are asking why this happened historically, then I don't know: I
>> wasn't there.  Maybe Richard can answer that.
> 
> I decided to represent characters using integers that just to keep
> Emacs simple and small.  In the 1980s, people wanted to run Emacs on
> machines with 1 meg of memory and a hard limit on process size.  I had
> to work hard to make that operate at all.
> 
> A separate character type would have required a number of extra
> conversion and test functions as well as read and print support.
> 
> Those space considerations are no longer significant.  But there may
> be another problem: whether there is room in the representation of
> Lisp_Object for another type.

Thank you very much for the explanation.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Stefan Monnier]

> Those space considerations are no longer significant.  But there may
> be another problem: whether there is room in the representation of
> Lisp_Object for another type.

We do know the answer to this question, since XEmacs has had a separate
character type since even before it was renamed to XEmacs.
Basically: you make the room for it.


        Stefan


PS: For what it's worth, I think it's a mostly irrelevant design choice
(tho maybe it was different back in the days of 1MB machines): having
a separate character type would occasionally be convenient, but then
again it would also occasionally be less convenient.  I don't think
either choice is clearly superior in this context.
[ In the context of a statically typed language, OTOH, I think you do
  want to have a separate character type.  ]

Re: evaluating numbers

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Wed, 29 Apr 2020 08:16:47 +0900
> 
> @Eli Maybe historically but also generally speaking, is it more convenient to implement characters as integers because that was the way it is done in other languages like C (which plays an important part in Emacs) ?

I think for the rest of this discussion to be meaningful you should
tell what alternatives to the current representation do you have in
mind.  Otherwise, when you say "more convenient", that begs the
question "more convenient compared to what?"

Re: evaluating numbers

[Jean-Christophe Helary]

> On Apr 29, 2020, at 16:08, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Wed, 29 Apr 2020 08:16:47 +0900
>> 
>> @Eli Maybe historically but also generally speaking, is it more convenient to implement characters as integers because that was the way it is done in other languages like C (which plays an important part in Emacs) ?
> 
> I think for the rest of this discussion to be meaningful you should
> tell what alternatives to the current representation do you have in
> mind.  Otherwise, when you say "more convenient", that begs the
> question "more convenient compared to what?"

My original mail was about the Emacs lisp manual where it is written that characters are implemented as integers and I did not understand what that meant. Richard replied that it was indeed more convenient at the time to have that implementation rather than another. As far as I'm concerned, Richard's reply was the best conclusion I could expect.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: evaluating numbers

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Those space considerations are no longer significant.  But there may
>> be another problem: whether there is room in the representation of
>> Lisp_Object for another type.
>
> We do know the answer to this question, since XEmacs has had a separate
> character type since even before it was renamed to XEmacs.
> Basically: you make the room for it.
>
>
>         Stefan
>
>
> PS: For what it's worth, I think it's a mostly irrelevant design choice
> (tho maybe it was different back in the days of 1MB machines): having
> a separate character type would occasionally be convenient, but then
> again it would also occasionally be less convenient.  I don't think
> either choice is clearly superior in this context.
> [ In the context of a statically typed language, OTOH, I think you do
>   want to have a separate character type.  ]

IIRC, a tag bit was freed not too long ago by the removal of Lisp_Misc.
I don't think making a separate type for characters is worth it though.

Re: evaluating numbers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Those space considerations are no longer significant.  But there may
  > > be another problem: whether there is room in the representation of
  > > Lisp_Object for another type.

  > We do know the answer to this question, since XEmacs has had a separate
  > character type since even before it was renamed to XEmacs.
  > Basically: you make the room for it.

That would be an answer about the general design approach, but the
question I posed is about the current format of Lisp_Object.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: evaluating numbers

[Stefan Monnier]

>   > We do know the answer to this question, since XEmacs has had a separate
>   > character type since even before it was renamed to XEmacs.
> That would be an answer about the general design approach, but the
> question I posed is about the current format of Lisp_Object.

Basically: if we wanted to have characters as a distinct type, then we'd
make room for it in Lisp_Object.

In any case, I don't think anyone is suggesting to make such a change
(and if someone proposes it, I'd object strongly.  Not because I think
having as a distinct type would be bad, but because it wouldn't be
better, so it would be gratuitous pain).


        Stefan