GNU bug report logs -
#17170
24.3.50; debug: Terminal 3 is locked, cannot read from it
Previous Next
Full log
View this message in rfc822 format
Le 07/05/2014 17:17, Eli Zaretskii a écrit :
>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> 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 <at> 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.
This bug report was last modified 9 years and 203 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.