bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it

[Nicolas Richard <theonewiththeevillook@yahoo.fr>]

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.