evaluating numbers

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

evaluating numbers

Jean-Christophe Helary-4
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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Stephen Berman
On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 7, 2019, at 18:57, Stephen Berman <[hidden email]> wrote:
>
> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Stephen Berman
On Thu, 7 Nov 2019 19:20:23 +0900 Jean-Christophe Helary <[hidden email]> wrote:

>> On Nov 7, 2019, at 18:57, Stephen Berman <[hidden email]> wrote:
>>
>> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary
>> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 7, 2019, at 19:30, Stephen Berman <[hidden email]> wrote:
>
> On Thu, 7 Nov 2019 19:20:23 +0900 Jean-Christophe Helary <[hidden email]> wrote:
>
>>> On Nov 7, 2019, at 18:57, Stephen Berman <[hidden email]> wrote:
>>>
>>> On Thu, 7 Nov 2019 18:43:40 +0900 Jean-Christophe Helary
>>> <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
> From: Jean-Christophe Helary <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 7, 2019, at 23:39, Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
> From: Jean-Christophe Helary <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 8, 2019, at 19:03, Eli Zaretskii <[hidden email]> wrote:
>
>> From: Jean-Christophe Helary <[hidden email]>
>> 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



Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
In reply to this post by Jean-Christophe Helary-4
> From: Jean-Christophe Helary <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 8, 2019, at 22:49, Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4
In reply to this post by Stefan Monnier


On Nov 8, 2019, at 22:22, Stefan Monnier <[hidden email]> wrote:

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.

Except that currently this only works for a very limited subset of the Emacs supported character set. So it's not really a "convenience"...

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.


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


Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
In reply to this post by Jean-Christophe Helary-4
> From: Jean-Christophe Helary <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
In reply to this post by Jean-Christophe Helary-4
> From: Jean-Christophe Helary <[hidden email]>
> 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".

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4
In reply to this post by Eli Zaretskii


> On Nov 9, 2019, at 16:22, Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Eli Zaretskii
> From: Jean-Christophe Helary <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Stefan Monnier
In reply to this post by Jean-Christophe Helary-4
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4


> On Nov 10, 2019, at 1:03, Stefan Monnier <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: evaluating numbers

Jean-Christophe Helary-4
In reply to this post by Eli Zaretskii


> On Nov 9, 2019, at 20:48, Eli Zaretskii <[hidden email]> 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



1234