From: Chris Stacy <cstacy@dtpq.com>
To: 21131@debbugs.gnu.org
Subject: bug#21131: minibuffer repl delay
Date: Fri, 24 Jul 2015 21:40:23 -0400 [thread overview]
Message-ID: <FFF03935-2868-4BF8-8DCB-10A2E27BD620@dtpq.com> (raw)
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.
next reply other threads:[~2015-07-25 1:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-25 1:40 Chris Stacy [this message]
2015-07-25 6:44 ` bug#21131: minibuffer repl delay Andreas Schwab
2015-07-25 8:20 ` Chris Stacy
2015-07-25 18:28 ` Glenn Morris
2015-07-25 18:48 ` Eli Zaretskii
2016-07-09 22:13 ` bug#21131: bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 Richard Copley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FFF03935-2868-4BF8-8DCB-10A2E27BD620@dtpq.com \
--to=cstacy@dtpq.com \
--cc=21131@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).