bug#21131: minibuffer repl delay

bug#21131: minibuffer repl delay

[Chris Stacy]

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.

bug#21131: minibuffer repl delay

[Andreas Schwab]

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

bug#21131: minibuffer repl delay

[Chris Stacy]

> On Jul 25, 2015, at 2:44 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> Chris Stacy <cstacy@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!

bug#21131: minibuffer repl delay

[Glenn Morris]

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.

bug#21131: minibuffer repl delay

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 25 Jul 2015 14:28:19 -0400
> Cc: 21131@debbugs.gnu.org, Chris Stacy <cstacy@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.

bug#21131: bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072

[Richard Copley]

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.