[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
From: |
Nicolas Richard |
Subject: |
bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it |
Date: |
Fri, 20 Mar 2015 16:47:50 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
Le 07/05/2014 17:17, Eli Zaretskii a écrit :
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>, 17170@debbugs.gnu.org
>> Date: Wed, 07 May 2014 13:07:18 +0200
>>
>> Could it be that the patch in bug#17413 will fix this problem ?
>
> Why not try that?
I think it helped but I'm not sure.
Anyway, I still have similar problems sometimes.
In my current session I have the following configuration of frames :
(mapconcat (lambda (f)
(format "Frame: %s\nTree: %s" f (window-tree f)))
(frame-list)
"\n\n")
;; =>
;; "Frame: #<frame *TABUF*<6> -- emacs@localhost (server) 0xfdaa5d8>
;; Tree: (#<window 552 on *TABUF*<6>> #<window 471 on *Minibuf-0*>)
;; Frame: #<frame F1 0x87b1a30>
;; Tree: ((t (0 0 10 9) #<window 1 on *scratch*> #<window 4 on *scratch*>)
#<window 2 on *Minibuf-0*>)"
And I was facing this problem:
(debug)
;; => debug: Terminal 0 is locked, cannot read from it
;; (but at this point I'm not left in a recursive edit -- which is a change
from the initial bugreport I made)
;; I did:
(setq debugger-previous-window (selected-window))
;; and it went away:
(debug)
;; works fine
So emacs sometimes tries to use the initial frame F1. That's not good because
that frame doesn't really exist (it's the frame created by "emacs --daemon").
I'll appreciate any help. I guess I should somehow detect when/why emacs tries
to access that initial frame, F1, but where would I hook ?
Nico.