From: "Jason S. Cornez" <jcornez@ravenpack.com>
To: 6585@debbugs.gnu.org
Subject: bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer
Date: Thu, 15 Jul 2010 14:05:14 +0200 [thread overview]
Message-ID: <4C3EF97A.5080208@ravenpack.com> (raw)
In-Reply-To: <handler.6585.B.12786062373280.ack@debbugs.gnu.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I believe I have found the problem. A custom function to switch to a
buffer is being called. It looks like...
- ----
(defun my::switch-to-buffer (buffer)
;; if buffer is in some window, go to it, otherwise switch-to-buffer
(let ((start (selected-window))
(current (next-window (selected-window) 'no-minibuffer 'visible))
(found nil))
(while (and (not (eq current start))
(not found))
(if (eq buffer (window-buffer current))
(setq found current))
(setq current (next-window current 'no-minibuffer 'visible)))
(if (null found)
(switch-to-buffer buffer)
(select-window found))))
- ----
Now, if start == (selected-window) is the minibuffer, then it should be
clear that current == (next-window ... 'no-minibuffer ...) will never
result in (eq start current). And if the buffer that is passed in isn't
visible then (not found) will never be nil and we are stuck in an
infinite loop.
So this part is not an emacs problem at all. But I am puzzled as to why
if this is byte-compiled I can't C-g and break out of this.
I'll fix my code and then the problem goes away. So if you want to
consider this "not-a-bug", ok. But shouldn't C-g work here?
Thanks,
- -Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkw++XoACgkQQlm6HDTMLyM0FACgivAX/CS3aQ8GjHguFJmPUoOs
HkwAoOevvsIpPWnEYEHl/By38pnh4DqV
=EHpz
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-07-15 12:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-08 14:19 bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer Jason Cornez
2010-07-08 16:52 ` Eli Zaretskii
2010-07-09 7:06 ` Jason S. Cornez
2010-07-14 10:27 ` Jason S. Cornez
[not found] ` <handler.6585.B.12786062373280.ack@debbugs.gnu.org>
2010-07-15 12:05 ` Jason S. Cornez [this message]
2010-07-15 14:57 ` martin rudalics
2010-07-15 15:33 ` Jason S. Cornez
2010-07-16 8:27 ` martin rudalics
2010-07-16 8:39 ` Jason S. Cornez
2010-07-15 15:53 ` Johan Bockgård
2010-07-15 15:59 ` Jason S. Cornez
2010-08-31 6:42 ` Jason S. Cornez
2010-08-31 10:24 ` Stefan Monnier
2010-08-31 10:34 ` Jason S. Cornez
2010-08-31 13:09 ` Stefan Monnier
2010-08-31 15:09 ` Jason S. Cornez
2012-04-10 19:37 ` Stefan Monnier
2010-09-13 13:22 ` bug#6585: Patch welcome? Jason S. Cornez
2010-09-13 15:55 ` Stefan Monnier
2011-11-21 22:54 ` bug#6585: status of patch? Tim Connors
2011-11-22 21:47 ` Stefan Monnier
2011-11-23 7:02 ` Jason S. Cornez
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=4C3EF97A.5080208@ravenpack.com \
--to=jcornez@ravenpack.com \
--cc=6585@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).