[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibu
From: |
martin rudalics |
Subject: |
bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer |
Date: |
Thu, 15 Jul 2010 16:57:40 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> 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.
Using `next-window' to find all windows is generally unsafe since
windows might get created and deleted in between (in particular the one
you named `start'). Always use `window-list' instead. The doc-string
of `next-window'
If you use consistent values for MINIBUF and ALL-FRAMES, you can use
`next-window' to iterate through the entire cycle of acceptable
windows, eventually ending up back at the window you started with.
is IMHO misleading in this regard.
> 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?
C-g should work. If it doesn't we have a bug. IIUC the only occurrence
of `switch-to-buffer' is ifdefd out in the source code so there can't be
any harm from an inhibit-quitted call from C. Could you try to run Emacs
in the debugger to find out where it hangs? Or post a self-contained
emacs -Q based recipe here?
martin