GNU bug report logs - #16828
24.3.50; eval-expression, character representation of integer results time-consuming

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16828 in the body.
You can then email your comments to 16828 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; eval-expression, character representation of integer results
 time-consuming
Date: Fri, 21 Feb 2014 11:01:36 +0100

[Message part 1 (text/plain, inline)]

The command `eval-expression' prints integer results both as decimal, hex,
octal, and (sometimes) as a character.

Some integers take a very long time to print, probably due to the fact that
it takes a long time to find a suitable font to render the character
variant in. The slow-down typically only occur once.

Steps to repeat:

    M-: 3200 RET

Here, it takes 22.5 seconds for Emacs to respond: 3200 (#o6200, #xc80)

Under 24.3 this was fast (well under a second).

This is on OS X 10.9 -- I haven't got access to any other system to test
this on.


In addition, sometimes it looks like the echo area splits the text into two
parts, effective only showing the second part. Unfortunately, I haven't
figured out when and how this occurs. Anyway, when it does, the *Messages*
buffer look like:


3200
 (#o6200, #xc80)
3200 (#o6200, #xc80) [2 times]

A simple solution would be to suppress printing of characters outside the
0-255 range (or at least give the user an option to do so).

Sincerely,
    Anders Lindgren

In GNU Emacs 24.3.50.2 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
 of 2014-02-16 on macpro.lan
Repository revision: 116451
jan.h.d <at> swipnet.se-20140216095141-cop794qd0bf30tmt
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --with-ns'

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> : 3 2 0 0 <return> <escape> x r e p o s r
t - <backspace> <backspace> <backspace> t <backspace>
<backspace> r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
3200 (#o6200, #xc80)
<s-backspace> is undefined [2 times]
s-b is undefined

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils mule-util time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)

[Message part 2 (text/html, inline)]

Message #8 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer
 results	time-consuming
Date: Fri, 21 Feb 2014 12:29:11 +0200

> Date: Fri, 21 Feb 2014 11:01:36 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> 
> Some integers take a very long time to print, probably due to the fact that
> it takes a long time to find a suitable font to render the character
> variant in. The slow-down typically only occur once.

Yes, this is because Emacs looks for and loads a suitable font.

Message #11 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "16828 <at> debbugs.gnu.org" <16828 <at> debbugs.gnu.org>
Subject: Re: bug#16828: 24.3.50; eval-expression, character representation of
 integer results time-consuming
Date: Sat, 22 Feb 2014 13:49:24 +0100

[Message part 1 (text/plain, inline)]

Ok, good, then we know what caused the problem. The question now it what
should be done about it.

Personally, I see little value of always seeing the char representation of
integers >255, and if that comes at the cost of a 22 second delay I don't
see that it's worth it.

   -- Anders

On Friday, February 21, 2014, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 21 Feb 2014 11:01:36 +0100
>> From: Anders Lindgren <andlind <at> gmail.com>
>>
>> Some integers take a very long time to print, probably due to the fact
that
>> it takes a long time to find a suitable font to render the character
>> variant in. The slow-down typically only occur once.
>
> Yes, this is because Emacs looks for and loads a suitable font.
>

[Message part 2 (text/html, inline)]

Message #14 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sat, 22 Feb 2014 15:11:05 +0200

> Date: Sat, 22 Feb 2014 13:49:24 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> Cc: "16828 <at> debbugs.gnu.org" <16828 <at> debbugs.gnu.org>
> 
> Personally, I see little value of always seeing the char representation of
> integers >255, and if that comes at the cost of a 22 second delay I don't
> see that it's worth it.

A user option should be a good compromise (we could argue about its
default value later ;-).

Message #17 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sat, 22 Feb 2014 19:53:13 +0100

On Sat, 22 Feb 2014 15:11:05 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Date: Sat, 22 Feb 2014 13:49:24 +0100
>> From: Anders Lindgren <andlind <at> gmail.com>
>> Cc: "16828 <at> debbugs.gnu.org" <16828 <at> debbugs.gnu.org>
>> 
>> Personally, I see little value of always seeing the char representation of
>> integers >255, and if that comes at the cost of a 22 second delay I don't
>> see that it's worth it.
>
> A user option should be a good compromise (we could argue about its
> default value later ;-).

An option for whether to show the character representation of integers
higher than 255 may be the easiest way to deal with this issue, but the
problem has wider scope (at least for me): it happens with any command
that makes Emacs look for and load a suitable font, e.g. `C-h h' or
opening an email or newsgroup posting that contains such a character.
In my case the delay can be as long as ~90 (ninety!) seconds.  Even
though this happens only once per session, such a long delay, during
which Emacs is effectively frozen, is quite annoying, especially when
reading mail or news, where it is typically unexpected.  Could the
option be a timeout, say if the font isn't found within X seconds (with
a low default), then just some placeholder will be shown, and maybe a
message indicating the failure to find the font in that time?

Steve Berman

Message #20 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 16828 <at> debbugs.gnu.org, andlind <at> gmail.com
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sat, 22 Feb 2014 23:00:10 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Anders Lindgren <andlind <at> gmail.com>,  16828 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2014 19:53:13 +0100
> 
> In my case the delay can be as long as ~90 (ninety!) seconds.  Even
> though this happens only once per session, such a long delay, during
> which Emacs is effectively frozen, is quite annoying, especially when
> reading mail or news, where it is typically unexpected.  Could the
> option be a timeout, say if the font isn't found within X seconds (with
> a low default), then just some placeholder will be shown, and maybe a
> message indicating the failure to find the font in that time?

I don't think the time this takes is spend _looking_ for a font, I
think it's spend loading a font.  But someone will have to trace and
profile this, and then come up with an analysis.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Achim Gratz <Stromeko <at> nexgo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 23 Feb 2014 10:06:18 +0100

Eli Zaretskii writes:
> I don't think the time this takes is spend _looking_ for a font, I
> think it's spend loading a font.  But someone will have to trace and
> profile this, and then come up with an analysis.

Like Stephen I am fairly certain that most of the time is indeed spent
looking for a suitable font, based on the disk noises that indicate
seeking through many directories.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Message #26 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Tue, 25 Feb 2014 09:42:22 +0900

Achim Gratz wrote:
> Eli Zaretskii writes:
>> I don't think the time this takes is spend _looking_ for a font, I
>> think it's spend loading a font.  But someone will have to trace and
>> profile this, and then come up with an analysis.

> Like Stephen I am fairly certain that most of the time is indeed spent
> looking for a suitable font, based on the disk noises that indicate
> seeking through many directories.

Especially on Cygwin, it's very annoying when edebugging.  Displaying
a character for the number of a point or a result of a calculation is
useless.  I use:

(if (eq system-type 'cygwin)
    (defadvice eval-expression-print-format
	(around dont-try-to-convert-char-to-string-when-edebugging
		(value) activate)
      "Don't try to convert char to string when edebugging."
      (if (and (boundp 'edebug-active) (eval 'edebug-active))
	  (if (and (integerp value)
		   (or (eq standard-output t)
		       (zerop (prefix-numeric-value current-prefix-arg))))
	      (format " (#o%o, #x%x)" value value))
	ad-do-it)))

Message #29 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;	eval-expression, character representation
 of integer results	time-consuming
Date: Wed, 26 Feb 2014 11:16:14 +0100

> Especially on Cygwin, it's very annoying when edebugging.  Displaying
> a character for the number of a point or a result of a calculation is
> useless.

The most annoying aspect here is that it very often finds a character
with a superscript and increases the height of my echo area.  Think of
how valuable this is when debugging code resizing the echo area ;-)

martin

Message #36 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: martin rudalics <rudalics <at> gmx.at>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer
 results	time-consuming
Date: Sat, 25 Mar 2017 23:45:22 -0400

[Message part 1 (text/plain, inline)]

tags 16828 patch
quit

martin rudalics <rudalics <at> gmx.at> writes:

>> Especially on Cygwin, it's very annoying when edebugging.  Displaying
>> a character for the number of a point or a result of a calculation is
>> useless.
>
> The most annoying aspect here is that it very often finds a character
> with a superscript and increases the height of my echo area.  Think of
> how valuable this is when debugging code resizing the echo area ;-)

I wonder how it could take so long to fix this silly thing.

[v1-0001-Limit-integers-printed-as-characters-Bug-16828.patch (text/x-diff, inline)]

From 301202a7963ee377bf0f51f703e0282782c7a6c1 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Sat, 25 Mar 2017 23:31:11 -0400
Subject: [PATCH v1] Limit integers printed as characters (Bug#16828)

* lisp/simple.el (eval-expression-print-maximum-character): New
variable.
(eval-expression-print-format): Only display value as character if
it's equal or less than `eval-expression-print-maximum-character'.
* doc/emacs/building.texi (Lisp Eval): Document it.
* etc/NEWS: Announce it.
---
 doc/emacs/building.texi |  6 +++++-
 etc/NEWS                |  4 ++++
 lisp/simple.el          | 14 +++++++++++---
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi
index ba8eae0759..2ee08e2505 100644
--- a/doc/emacs/building.texi
+++ b/doc/emacs/building.texi
@@ -1485,7 +1485,8 @@ Lisp Eval
 Emacs Lisp expression preceding point in the buffer, and displays the
 value in the echo area.  When the result of an evaluation is an
 integer, it is displayed together with the value in other formats
-(octal, hexadecimal, and character).
+(octal, hexadecimal, and character if
+@code{eval-expression-print-maximum-character} allows it).
 
   If @kbd{M-:} or @kbd{C-x C-e} is given a prefix argument, it inserts
 the value into the current buffer at point, rather than displaying it
@@ -1524,6 +1525,7 @@ Lisp Eval
 
 @vindex eval-expression-print-level
 @vindex eval-expression-print-length
+@vindex eval-expression-print-maximum-character
 @vindex eval-expression-debug-on-error
   The options @code{eval-expression-print-level} and
 @code{eval-expression-print-length} control the maximum depth and
@@ -1533,6 +1535,8 @@ Lisp Eval
 printed in full.  @code{eval-expression-debug-on-error} controls
 whether evaluation errors invoke the debugger when these commands are
 used; its default is @code{t}.
+@code{eval-expression-print-maximum-character} prevents large integers
+from being displayed as characters.
 
 @node Lisp Interaction
 @section Lisp Interaction Buffers
diff --git a/etc/NEWS b/etc/NEWS
index 62d06f3561..c09cc390bb 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -334,6 +334,10 @@ always restricting the margin to a quarter of the window.
 ** Emacsclient has a new option -u/--suppress-output.  The option
 suppresses display of return values from the server process.
 
++++
+** The new variable 'eval-expression-print-maximum-character' prevents
+large integers from being displayed as characters.
+
 
 * Editing Changes in Emacs 26.1
 
diff --git a/lisp/simple.el b/lisp/simple.el
index 681cf83807..599c7ebf30 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1450,6 +1450,13 @@ eval-expression-debug-on-error
   :type 'boolean
   :version "21.1")
 
+(defcustom eval-expression-print-maximum-character 127
+  "The largest integer that will be displayed as a character.
+This affects printing by `eval-expression-print-format'."
+  :group 'lisp
+  :type 'integer
+  :version "26.1")
+
 (defun eval-expression-print-format (value)
   "If VALUE in an integer, return a specially formatted string.
 This string will typically look like \" (#o1, #x1, ?\\C-a)\".
@@ -1460,9 +1467,10 @@ eval-expression-print-format
 	   (or (eq standard-output t)
 	       (zerop (prefix-numeric-value current-prefix-arg))))
       (let ((char-string
-	     (if (and (characterp value)
-		      (char-displayable-p value))
-		 (prin1-char value))))
+             (and (characterp value)
+                  (<= value eval-expression-print-maximum-character)
+                  (char-displayable-p value)
+                  (prin1-char value))))
         (if char-string
             (format " (#o%o, #x%x, %s)" value value char-string)
           (format " (#o%o, #x%x)" value value)))))
-- 
2.11.1

Message #41 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: rudalics <at> gmx.at, yamaoka <at> jpl.org, 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer
 results	time-consuming
Date: Sun, 26 Mar 2017 17:13:35 +0300

> From: npostavs <at> users.sourceforge.net
> Date: Sat, 25 Mar 2017 23:45:22 -0400
> Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 16828 <at> debbugs.gnu.org
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> >> Especially on Cygwin, it's very annoying when edebugging.  Displaying
> >> a character for the number of a point or a result of a calculation is
> >> useless.
> >
> > The most annoying aspect here is that it very often finds a character
> > with a superscript and increases the height of my echo area.  Think of
> > how valuable this is when debugging code resizing the echo area ;-)
> 
> I wonder how it could take so long to fix this silly thing.

It isn't silly IME, I actually use this feature.

So, under this proposal, is there any way to get the character for a
single invocation of M-:, without setting the option, if I only need
that sometimes?  Should there be such a way?

Thanks.

Message #44 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50; eval-expression, character representation of
 integer results time-consuming
Date: Sun, 26 Mar 2017 10:19:50 -0400

On Sun, Mar 26, 2017 at 10:13 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> So, under this proposal, is there any way to get the character for a
> single invocation of M-:, without setting the option, if I only need
> that sometimes?  Should there be such a way?

Isn't M-: (prin1-char value) sufficient?

Message #47 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: yamaoka <at> jpl.org, 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50; eval-expression, character representation of
 integer results time-consuming
Date: Sun, 26 Mar 2017 17:37:58 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sun, 26 Mar 2017 10:19:50 -0400
> Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 16828 <at> debbugs.gnu.org
> 
> On Sun, Mar 26, 2017 at 10:13 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > So, under this proposal, is there any way to get the character for a
> > single invocation of M-:, without setting the option, if I only need
> > that sometimes?  Should there be such a way?
> 
> Isn't M-: (prin1-char value) sufficient?

No, not after years of using "M-: #xNNNN RET".

Message #50 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 10:55:44 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> >
>> > So, under this proposal, is there any way to get the character for a
>> > single invocation of M-:, without setting the option, if I only need
>> > that sometimes?  Should there be such a way?
>> 
>> Isn't M-: (prin1-char value) sufficient?
>
> No, not after years of using "M-: #xNNNN RET".

If you want to keep muscle memory,

    (setq eval-expression-print-maximum-character most-positive-fixnum)

should give you back the old behaviour.  If you only want this only some
of the time, perhaps we should add a toggle-print-maximum-character
command?

Message #53 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 18:22:48 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 16828 <at> debbugs.gnu.org
> Date: Sun, 26 Mar 2017 10:55:44 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >
> >> > So, under this proposal, is there any way to get the character for a
> >> > single invocation of M-:, without setting the option, if I only need
> >> > that sometimes?  Should there be such a way?
> >> 
> >> Isn't M-: (prin1-char value) sufficient?
> >
> > No, not after years of using "M-: #xNNNN RET".
> 
> If you want to keep muscle memory,
> 
>     (setq eval-expression-print-maximum-character most-positive-fixnum)
> 
> should give you back the old behaviour.  If you only want this only some
> of the time, perhaps we should add a toggle-print-maximum-character
> command?

What about a special value of prefix argument, like zero?  If that's
OK, it's more convenient than any of the above.

Message #56 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 13:39:52 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: npostavs <at> users.sourceforge.net
>> Cc: 16828 <at> debbugs.gnu.org
>> Date: Sun, 26 Mar 2017 10:55:44 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> >
>> >> > So, under this proposal, is there any way to get the character for a
>> >> > single invocation of M-:, without setting the option, if I only need
>> >> > that sometimes?  Should there be such a way?
>> >> 
>> >> Isn't M-: (prin1-char value) sufficient?
>> >
>> > No, not after years of using "M-: #xNNNN RET".
>> 
>> If you want to keep muscle memory,
>> 
>>     (setq eval-expression-print-maximum-character most-positive-fixnum)
>> 
>> should give you back the old behaviour.  If you only want this only some
>> of the time, perhaps we should add a toggle-print-maximum-character
>> command?
>
> What about a special value of prefix argument, like zero?  If that's
> OK, it's more convenient than any of the above.

Sure, it's just a matter of deciding how to fit this in with the
existing interpretation of the prefix argument.  Right now, a non-nil
prefix argument means to insert the result into the buffer.

Message #59 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 20:51:42 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 16828 <at> debbugs.gnu.org
> Date: Sun, 26 Mar 2017 13:39:52 -0400
> 
> > What about a special value of prefix argument, like zero?  If that's
> > OK, it's more convenient than any of the above.
> 
> Sure, it's just a matter of deciding how to fit this in with the
> existing interpretation of the prefix argument.  Right now, a non-nil
> prefix argument means to insert the result into the buffer.

Yes, I propose that the current behavior wrt the argument will be left
unchanged, except when the argument is zero, i.e. "C-u 0".

Message #62 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 14:16:52 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: npostavs <at> users.sourceforge.net
>> Cc: 16828 <at> debbugs.gnu.org
>> Date: Sun, 26 Mar 2017 13:39:52 -0400
>> 
>> > What about a special value of prefix argument, like zero?  If that's
>> > OK, it's more convenient than any of the above.
>> 
>> Sure, it's just a matter of deciding how to fit this in with the
>> existing interpretation of the prefix argument.  Right now, a non-nil
>> prefix argument means to insert the result into the buffer.
>
> Yes, I propose that the current behavior wrt the argument will be left
> unchanged, except when the argument is zero, i.e. "C-u 0".

Currently, zero also means no truncation, keeping that meaning seems
important too.  Perhaps a negative argument would be a better choice?

Excerpt from current docstring:

    Optional argument INSERT-VALUE non-nil (interactively, with
    prefix argument) means insert the result into the current buffer
    instead of printing it in the echo area.

    Normally, this function truncates long output according to the value
    of the variables `eval-expression-print-length' and
    `eval-expression-print-level'.  With a prefix argument of zero,
    however, there is no such truncation.

Message #65 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sun, 26 Mar 2017 21:40:38 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 16828 <at> debbugs.gnu.org
> Date: Sun, 26 Mar 2017 14:16:52 -0400
> 
> > Yes, I propose that the current behavior wrt the argument will be left
> > unchanged, except when the argument is zero, i.e. "C-u 0".
> 
> Currently, zero also means no truncation, keeping that meaning seems
> important too.  Perhaps a negative argument would be a better choice?

Yes, that'd be fine with me.  Thanks.

Message #68 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Thu, 18 May 2017 19:56:53 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Yes, I propose that the current behavior wrt the argument will be left
>> > unchanged, except when the argument is zero, i.e. "C-u 0".
>> 
>> Currently, zero also means no truncation, keeping that meaning seems
>> important too.  Perhaps a negative argument would be a better choice?
>
> Yes, that'd be fine with me.  Thanks.

I added `-' to echo in character format, and `-1' to print it to the
buffer.  I split the patch in 2 parts, the first just refactors the
printing code, the 2nd adds the new behaviour.

[v2-0001-Refactor-lisp-eval-result-printing.patch (text/plain, attachment)]

[v2-0002-Limit-integers-printed-as-characters-Bug-16828.patch (text/plain, attachment)]

Message #71 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Fri, 19 May 2017 09:34:52 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 16828 <at> debbugs.gnu.org
> Date: Thu, 18 May 2017 19:56:53 -0400
> 
> >> Currently, zero also means no truncation, keeping that meaning seems
> >> important too.  Perhaps a negative argument would be a better choice?
> >
> > Yes, that'd be fine with me.  Thanks.
> 
> I added `-' to echo in character format, and `-1' to print it to the
> buffer.  I split the patch in 2 parts, the first just refactors the
> printing code, the 2nd adds the new behaviour.

Thanks.

A couple of nits regarding the documentation part:

> +(defcustom eval-expression-print-maximum-character 127
> +  "The largest integer that will be displayed as a character.
> +This affects printing by `eval-expression-print-format'."

I would suggest to also mention eval-expression here.

> --- a/doc/emacs/building.texi
> +++ b/doc/emacs/building.texi
> @@ -1485,7 +1485,8 @@ Lisp Eval
>  Emacs Lisp expression preceding point in the buffer, and displays the
>  value in the echo area.  When the result of an evaluation is an
>  integer, it is displayed together with the value in other formats
> -(octal, hexadecimal, and character).
> +(octal, hexadecimal, and character if
> +@code{eval-expression-print-maximum-character} allows it).

Please add a "see below" here, as the description of the variable is
several dozens of lines farther.

> +@code{eval-expression-print-maximum-character} prevents large integers
> +from being displayed as characters.

This is too terse, IMO; please state explicitly that values larger
than this will not be displayed as characters.

Message #74 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Fri, 19 May 2017 16:52:20 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> I would suggest to also mention eval-expression here.

Right, I also noticed eval-expression-print-format's docstring refers to
`prin1' which seems to be wrong.

 (defcustom eval-expression-print-maximum-character 127
   "The largest integer that will be displayed as a character.
-This affects printing by `eval-expression-print-format'."
+This affects printing by `eval-expression' (via
+`eval-expression-print-format')."
   :group 'lisp
   :type 'integer
   :version "26.1")
 
 (defun eval-expression-print-format (value)
   "If VALUE in an integer, return a specially formatted string.
 This string will typically look like \" (#o1, #x1, ?\\C-a)\".
 If VALUE is not an integer, nil is returned.
-This function is used by functions like `prin1' that display the
-result of expression evaluation."
+This function is used by commands like `eval-expression' that
+display the result of expression evaluation."

>> +(octal, hexadecimal, and character if
>> +@code{eval-expression-print-maximum-character} allows it).
>
> Please add a "see below" here, as the description of the variable is
> several dozens of lines farther.

Right.  Is it okay to have nested parentheses?  I use this quite often
when I write emails and such, but I have the idea it might be frowned
upon in more formal contexts.

+@code{eval-expression-print-maximum-character} (see below) allows it).

>
> This is too terse, IMO; please state explicitly that values larger
> than this will not be displayed as characters.

Yeah, I have a tendency to be overly terse.

+@code{eval-expression-print-maximum-character} prevents integers which
+are larger than it from being displayed as characters.

[v3-0002-Limit-integers-printed-as-characters-Bug-16828.patch (text/plain, attachment)]

Message #77 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Sat, 20 May 2017 00:09:24 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 16828 <at> debbugs.gnu.org
> Date: Fri, 19 May 2017 16:52:20 -0400
> 
> >> +(octal, hexadecimal, and character if
> >> +@code{eval-expression-print-maximum-character} allows it).
> >
> > Please add a "see below" here, as the description of the variable is
> > several dozens of lines farther.
> 
> Right.  Is it okay to have nested parentheses?

Personally, I prefer to use commas in these cases:

 +(octal, hexadecimal, and character if
 +@code{eval-expression-print-maximum-character}, described below, allows it).

Thanks, the new version is fine with me.

Message #80 received at 16828 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16828 <at> debbugs.gnu.org
Subject: Re: bug#16828: 24.3.50;
 eval-expression, character representation of integer results
 time-consuming
Date: Fri, 19 May 2017 18:28:55 -0400

tags 16828 fixed
close 16828 26.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, the new version is fine with me.

Pushed to master [1: acd58c9198] [2: 267be4bdc2].

[1: acd58c9198]: 2017-05-19 18:16:38 -0400
  Limit integers printed as characters (Bug#16828)
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=acd58c9198c08c3eb631a3f036b4f95073f7fe10

[2: 267be4bdc2]: 2017-05-19 18:16:15 -0400
  Refactor lisp eval result printing
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=267be4bdc28564a99f45da29e84eb98838117b50

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.