GNU bug report logs - #21131
printing character representation of numbers can be slow

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 21131 in the body.
You can then email your comments to 21131 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: Chris Stacy <cstacy <at> dtpq.com>
To: bug-gnu-emacs <at> gnu.org
Subject: minibuffer repl delay
Date: Fri, 24 Jul 2015 21:40:23 -0400

In Aquamacs 3.2 GNU Emacs 24.4.51.2
(x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14)
 of 2014-11-07 (Aquamacs-3.2) on watson.local
Operating System: OS X Version 10.10.4 (Build 14E46)
Configured using:
 `configure --with-ns --without-x 'CFLAGS=-arch x86_64 -O3 -g
 -mtune=corei7 -mmacosx-version-min=10.6' 'LDFLAGS=-arch x86_64 -O3 -g
 -mtune=corei7 -mmacosx-version-min=10.6''

Important settings:
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  savehist-mode: t
  smart-frame-positioning-mode: t
  aquamacs-autoface-mode: t
  recentf-mode: t
  show-paren-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  column-number-mode: t
  line-number-mode: t


I think this still happens in vanilla 24.5 and doesn't have anything to do with Aquamacs.
Can’t remember when it first appeared but it’s not a very new bug.

When I eval something in the scratch buffer, I get the answer immediately:

(+ 1997 120 400)
2517

But doing the same thing in the minibuffer (eval-expression)
incurs a huge delay after I hit ENTER and before seeing the answer.
For example, the above expression took over 7 seconds before I saw:

2117 (#o4105, #x845)

I can't tell if it is just arithmetic because the delays seem to random.

Sometimes there doesn't seem to be a delay.
This always comes back right away:

(length '(a b c d e))
5 (#o5, #x5, ?\C-e)

Sometimes this has a 2 second delay and sometimes not:
(cons 'a 'b)
(a . b)

Sometimes the delay goes away for a while in some cases.
Although never for any addition where one of the operands
is more than 4 digits.   This always has a 7 second delay:

(+ 1299 120)

Mysterious!

Makes it impossible to use the minibuffer as the always-available
quick desk calculator on the system, which I (used to) do constantly.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Chris Stacy <cstacy <at> dtpq.com>
Cc: 21131 <at> debbugs.gnu.org
Subject: Re: bug#21131: minibuffer repl delay
Date: Sat, 25 Jul 2015 08:44:43 +0200

Chris Stacy <cstacy <at> dtpq.com> writes:

> But doing the same thing in the minibuffer (eval-expression)
> incurs a huge delay after I hit ENTER and before seeing the answer.
> For example, the above expression took over 7 seconds before I saw:
>
> 2117 (#o4105, #x845)
>
> I can't tell if it is just arithmetic because the delays seem to random.

It comes from trying to render the number as a character, and it can
take some time to find a font that contains this character, if any.

> Sometimes there doesn't seem to be a delay.
> This always comes back right away:
>
> (length '(a b c d e))
> 5 (#o5, #x5, ?\C-e)

5 isn't a printable character, so it is rendered as ?\C-e.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Chris Stacy <cstacy <at> dtpq.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21131 <at> debbugs.gnu.org, Christopher Stacy <cstacy <at> dtpq.com>
Subject: Re: bug#21131: minibuffer repl delay
Date: Sat, 25 Jul 2015 04:20:35 -0400

> On Jul 25, 2015, at 2:44 AM, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> 
> Chris Stacy <cstacy <at> dtpq.com> writes:
> 
>> But doing the same thing in the minibuffer (eval-expression)
>> incurs a huge delay after I hit ENTER and before seeing the answer.
>> For example, the above expression took over 7 seconds before I saw:
>> 
>> 2117 (#o4105, #x845)
>> 
>> I can't tell if it is just arithmetic because the delays seem to random.
> 
> It comes from trying to render the number as a character, and it can
> take some time to find a font that contains this character, if any.

Is there some setting that would prevent it from doing that?
Maybe I should just write my own command; maybe there is something I can bind?
i just want a straight PRINT, like I get in *scratch*

Thank you!

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

From: Glenn Morris <rgm <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21131 <at> debbugs.gnu.org, Chris Stacy <cstacy <at> dtpq.com>
Subject: Re: bug#21131: minibuffer repl delay
Date: Sat, 25 Jul 2015 14:28:19 -0400

Andreas Schwab wrote:

>> I can't tell if it is just arithmetic because the delays seem to random.
>
> It comes from trying to render the number as a character, and it can
> take some time to find a font that contains this character, if any.

I really think this behaviour should be optional, and off by default, or
on a separate command. I've seen it cause this same problem over and
over again. (I'm pretty sure there is at least one open bug report with
the same root cause.)

Personally I have never wanted/needed the character representation of
numbers printed in this way.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 21131 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, cstacy <at> dtpq.com
Subject: Re: bug#21131: minibuffer repl delay
Date: Sat, 25 Jul 2015 21:48:46 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Sat, 25 Jul 2015 14:28:19 -0400
> Cc: 21131 <at> debbugs.gnu.org, Chris Stacy <cstacy <at> dtpq.com>
> 
> I really think this behaviour should be optional, and off by default, or
> on a separate command.

Separate command or an optional behavior triggered by an argument,
would be fine, I think.

> Personally I have never wanted/needed the character representation of
> numbers printed in this way.

I have.  One frequent (for me) use case is when I see a codepoint in
hex and want to know which character that is.

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

From: Richard Copley <rcopley <at> gmail.com>
To: 21131 <at> debbugs.gnu.org, control <at> debbugs.gnu.org, 
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072
Date: Sat, 9 Jul 2016 23:13:04 +0100

merge 23930 21131
thanks

Noam Postavsky wrote:
> Maybe a dup of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21131

Looks like it! Thanks, merging.

Previous Next

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