unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
@ 2014-04-02 11:03 Nicolas Richard
  2014-04-02 16:26 ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2014-04-02 11:03 UTC (permalink / raw)
  To: 17170

I got the following error message
debug: Terminal 3 is locked, cannot read from it

It has already happened to me but I cannot reproduce. This however only
happeend to me in a situation where emacs is run (with -nw option) from
gdb which is run from tmux and I connect to that through ssh and
emacsclient.

In this specific occurrence of the problem, that initial frame was
active (on the host computer) but I was connecting to the emacs session
from ssh via emacsclient. There was a third frame also, a graphical one,
on the host computer.

If I hit ESC ESC ESC, I get the error message again and enter a new
level of recursive edit (i.e. another layer of brackets in the
modeline). I can't escape those : C-] just makes also the error again +
another level of recursive edit.

Any idea on how to debug this further ?

Thanks.

In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-03-27 on geodiff-mac3
Windowing system distributor `The X.Org Foundation', version 11.0.11304000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --with-x-toolkit=lucid 'CFLAGS= -O0 -g3''

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Edit Macro

Minor modes in effect:
  TeX-PDF-mode: t
  rcirc-track-minor-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  yas/global-mode: t
  projectile-global-mode: t
  projectile-mode: t
  dynamic-completion-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  server-mode: t
  minibuffer-depth-indicate-mode: t
  show-paren-mode: t
  recentf-mode: t
  winner-mode: t
  global-discover-mode: t
  discover-mode: t
  display-time-mode: t
  override-global-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down> <down> C-x C-s c M-x g n u s <return> C-x b 
<return> <C-home> C-x C-s C-c C-c y g <up> <down> q 
y C-c C-SPC C-z C-x b B B <return> C-x b b <backspace> 
B B Q C-g ESC [ > 1 ; 3 4 0 6 ; 0 c C-c C-c C-@ C-c 
C-@ C-u C-c C-@ ESC x C-g ESC x r c i r c RET ESC x 
g n u s RET C-n C-p RET RET , , C-p RET C-c C-@ C-c 
C-@ C-c C-@ C-c C-@ C-c C-@ C-c C-s C-x 1 C-l C-l ESC 
x g n u s RET RET q RET RET k q RET q C-n q y ESC < 
ESC > C-x b # e m RET ESC < ESC > C-c C-@ C-c C-@ C-c 
C-@ ESC < C-x K C-c C-@ ESC > C-x K ESC x ESC l o c 
a t e RET d e n i s RET C-s p d f C-n C-n C-n ESC x 
ESC O A RET d b o n h e RET C-x 1 C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p 
C-x K C-x C-c C-g C-x C-c C-g C-x ESC O C C-p C-p C-p 
C-p C-n C-n C-p C-o C-n C-c C-e d o c u TAB RET RET 
C-h l C-x C-k e C-h l ESC > C-@ C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-g ESC x r e p o r t SPC e m TAB SPC b u DEL DEL 
DEL TAB RET

Recent messages:
Mark set [6 times]
Mark saved where search started
Quit [2 times]
Beginning of buffer [3 times]
Sorting environment...
Removing duplicates... done
Entering debugger...
debug: Terminal 3 is locked, cannot read from it
Type C-x 1 to delete the help window.
Formatting keyboard macro...done

Load-path shadows:
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-blame hides ~/sources/magit/magit-blame
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-key-mode hides ~/sources/magit/magit-key-mode
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-pkg hides ~/sources/magit/magit-pkg
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-wip hides ~/sources/magit/magit-wip
/home/youngfrog/.emacs.d/elpa/git-commit-mode-20140125.1553/git-commit-mode hides ~/sources/magit/git-commit-mode
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-autoloads hides ~/sources/magit/magit-autoloads
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit hides ~/sources/magit/magit
/home/youngfrog/.emacs.d/elpa/git-rebase-mode-20140125.1553/git-rebase-mode hides ~/sources/magit/git-rebase-mode
~/.emacs.d/lisp/asy-mode hides /usr/local/texlive/2012/texmf/asymptote/asy-mode
~/sources/org-mode/lisp/org-footnote hides /home/youngfrog/sources/running-emacs/lisp/org/org-footnote
~/sources/org-mode/lisp/ob-asymptote hides /home/youngfrog/sources/running-emacs/lisp/org/ob-asymptote
~/sources/org-mode/lisp/ob-sqlite hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sqlite
~/sources/org-mode/lisp/ob-ditaa hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ditaa
~/sources/org-mode/lisp/org-protocol hides /home/youngfrog/sources/running-emacs/lisp/org/org-protocol
~/sources/org-mode/lisp/ox-beamer hides /home/youngfrog/sources/running-emacs/lisp/org/ox-beamer
~/sources/org-mode/lisp/org-irc hides /home/youngfrog/sources/running-emacs/lisp/org/org-irc
~/sources/org-mode/lisp/ob-scheme hides /home/youngfrog/sources/running-emacs/lisp/org/ob-scheme
~/sources/org-mode/lisp/org-capture hides /home/youngfrog/sources/running-emacs/lisp/org/org-capture
~/sources/org-mode/lisp/ob-plantuml hides /home/youngfrog/sources/running-emacs/lisp/org/ob-plantuml
~/sources/org-mode/lisp/ox-html hides /home/youngfrog/sources/running-emacs/lisp/org/ox-html
~/sources/org-mode/lisp/org-table hides /home/youngfrog/sources/running-emacs/lisp/org/org-table
~/sources/org-mode/lisp/ob-eval hides /home/youngfrog/sources/running-emacs/lisp/org/ob-eval
~/sources/org-mode/lisp/ob-exp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-exp
~/sources/org-mode/lisp/org-eshell hides /home/youngfrog/sources/running-emacs/lisp/org/org-eshell
~/sources/org-mode/lisp/ob-sql hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sql
~/sources/org-mode/lisp/org-colview hides /home/youngfrog/sources/running-emacs/lisp/org/org-colview
~/sources/org-mode/lisp/ox-publish hides /home/youngfrog/sources/running-emacs/lisp/org/ox-publish
~/sources/org-mode/lisp/ob-comint hides /home/youngfrog/sources/running-emacs/lisp/org/ob-comint
~/sources/org-mode/lisp/org-element hides /home/youngfrog/sources/running-emacs/lisp/org/org-element
~/sources/org-mode/lisp/org-indent hides /home/youngfrog/sources/running-emacs/lisp/org/org-indent
~/sources/org-mode/lisp/ob-sass hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sass
~/sources/org-mode/lisp/org-compat hides /home/youngfrog/sources/running-emacs/lisp/org/org-compat
~/sources/org-mode/lisp/org-list hides /home/youngfrog/sources/running-emacs/lisp/org/org-list
~/sources/org-mode/lisp/ox hides /home/youngfrog/sources/running-emacs/lisp/org/ox
~/sources/org-mode/lisp/ob-mscgen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-mscgen
~/sources/org-mode/lisp/ob-keys hides /home/youngfrog/sources/running-emacs/lisp/org/ob-keys
~/sources/org-mode/lisp/org-info hides /home/youngfrog/sources/running-emacs/lisp/org/org-info
~/sources/org-mode/lisp/org-ctags hides /home/youngfrog/sources/running-emacs/lisp/org/org-ctags
~/sources/org-mode/lisp/org-habit hides /home/youngfrog/sources/running-emacs/lisp/org/org-habit
~/sources/org-mode/lisp/org-datetree hides /home/youngfrog/sources/running-emacs/lisp/org/org-datetree
~/sources/org-mode/lisp/ox-texinfo hides /home/youngfrog/sources/running-emacs/lisp/org/ox-texinfo
~/sources/org-mode/lisp/org-clock hides /home/youngfrog/sources/running-emacs/lisp/org/org-clock
~/sources/org-mode/lisp/org-bbdb hides /home/youngfrog/sources/running-emacs/lisp/org/org-bbdb
~/sources/org-mode/lisp/ob-maxima hides /home/youngfrog/sources/running-emacs/lisp/org/ob-maxima
~/sources/org-mode/lisp/ob-fortran hides /home/youngfrog/sources/running-emacs/lisp/org/ob-fortran
~/sources/org-mode/lisp/ob-picolisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-picolisp
~/sources/org-mode/lisp/ob-java hides /home/youngfrog/sources/running-emacs/lisp/org/ob-java
~/sources/org-mode/lisp/ox-icalendar hides /home/youngfrog/sources/running-emacs/lisp/org/ox-icalendar
~/sources/org-mode/lisp/org-gnus hides /home/youngfrog/sources/running-emacs/lisp/org/org-gnus
~/sources/org-mode/lisp/ob-table hides /home/youngfrog/sources/running-emacs/lisp/org/ob-table
~/sources/org-mode/lisp/ob-ocaml hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ocaml
~/sources/org-mode/lisp/ob-tangle hides /home/youngfrog/sources/running-emacs/lisp/org/ob-tangle
~/sources/org-mode/lisp/ox-md hides /home/youngfrog/sources/running-emacs/lisp/org/ox-md
~/sources/org-mode/lisp/org-install hides /home/youngfrog/sources/running-emacs/lisp/org/org-install
~/sources/org-mode/lisp/ob-org hides /home/youngfrog/sources/running-emacs/lisp/org/ob-org
~/sources/org-mode/lisp/org-docview hides /home/youngfrog/sources/running-emacs/lisp/org/org-docview
~/sources/org-mode/lisp/org-timer hides /home/youngfrog/sources/running-emacs/lisp/org/org-timer
~/sources/org-mode/lisp/ob-makefile hides /home/youngfrog/sources/running-emacs/lisp/org/ob-makefile
~/sources/org-mode/lisp/ob-calc hides /home/youngfrog/sources/running-emacs/lisp/org/ob-calc
~/sources/org-mode/lisp/org-rmail hides /home/youngfrog/sources/running-emacs/lisp/org/org-rmail
~/sources/org-mode/lisp/org-plot hides /home/youngfrog/sources/running-emacs/lisp/org/org-plot
~/sources/org-mode/lisp/ob-haskell hides /home/youngfrog/sources/running-emacs/lisp/org/ob-haskell
~/sources/org-mode/lisp/ob-shen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-shen
~/sources/org-mode/lisp/ox-latex hides /home/youngfrog/sources/running-emacs/lisp/org/ox-latex
~/sources/org-mode/lisp/org-mhe hides /home/youngfrog/sources/running-emacs/lisp/org/org-mhe
~/sources/org-mode/lisp/org-pcomplete hides /home/youngfrog/sources/running-emacs/lisp/org/org-pcomplete
~/sources/org-mode/lisp/org-mouse hides /home/youngfrog/sources/running-emacs/lisp/org/org-mouse
~/sources/org-mode/lisp/ox-man hides /home/youngfrog/sources/running-emacs/lisp/org/ox-man
~/sources/org-mode/lisp/org-archive hides /home/youngfrog/sources/running-emacs/lisp/org/org-archive
~/sources/org-mode/lisp/ox-ascii hides /home/youngfrog/sources/running-emacs/lisp/org/ox-ascii
~/sources/org-mode/lisp/ob-python hides /home/youngfrog/sources/running-emacs/lisp/org/ob-python
~/sources/org-mode/lisp/ox-org hides /home/youngfrog/sources/running-emacs/lisp/org/ox-org
~/sources/org-mode/lisp/ob-gnuplot hides /home/youngfrog/sources/running-emacs/lisp/org/ob-gnuplot
~/sources/org-mode/lisp/org-agenda hides /home/youngfrog/sources/running-emacs/lisp/org/org-agenda
~/sources/org-mode/lisp/ob-core hides /home/youngfrog/sources/running-emacs/lisp/org/ob-core
~/sources/org-mode/lisp/ob-perl hides /home/youngfrog/sources/running-emacs/lisp/org/ob-perl
~/sources/org-mode/lisp/ob-octave hides /home/youngfrog/sources/running-emacs/lisp/org/ob-octave
~/sources/org-mode/lisp/org-crypt hides /home/youngfrog/sources/running-emacs/lisp/org/org-crypt
~/sources/org-mode/lisp/org-macs hides /home/youngfrog/sources/running-emacs/lisp/org/org-macs
~/sources/org-mode/lisp/org-w3m hides /home/youngfrog/sources/running-emacs/lisp/org/org-w3m
~/sources/org-mode/lisp/org-feed hides /home/youngfrog/sources/running-emacs/lisp/org/org-feed
~/sources/org-mode/lisp/org-mobile hides /home/youngfrog/sources/running-emacs/lisp/org/org-mobile
~/sources/org-mode/lisp/org-version hides /home/youngfrog/sources/running-emacs/lisp/org/org-version
~/sources/org-mode/lisp/ob-ledger hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ledger
~/sources/org-mode/lisp/org-inlinetask hides /home/youngfrog/sources/running-emacs/lisp/org/org-inlinetask
~/sources/org-mode/lisp/ob-latex hides /home/youngfrog/sources/running-emacs/lisp/org/ob-latex
~/sources/org-mode/lisp/ob-dot hides /home/youngfrog/sources/running-emacs/lisp/org/ob-dot
~/sources/org-mode/lisp/ob-screen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-screen
~/sources/org-mode/lisp/org-src hides /home/youngfrog/sources/running-emacs/lisp/org/org-src
~/sources/org-mode/lisp/ob-ruby hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ruby
~/sources/org-mode/lisp/org-macro hides /home/youngfrog/sources/running-emacs/lisp/org/org-macro
~/sources/org-mode/lisp/ob hides /home/youngfrog/sources/running-emacs/lisp/org/ob
~/sources/org-mode/lisp/ob-io hides /home/youngfrog/sources/running-emacs/lisp/org/ob-io
~/sources/org-mode/lisp/ob-matlab hides /home/youngfrog/sources/running-emacs/lisp/org/ob-matlab
~/sources/org-mode/lisp/ob-ref hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ref
~/sources/org-mode/lisp/org-bibtex hides /home/youngfrog/sources/running-emacs/lisp/org/org-bibtex
~/sources/org-mode/lisp/org-entities hides /home/youngfrog/sources/running-emacs/lisp/org/org-entities
~/sources/org-mode/lisp/org hides /home/youngfrog/sources/running-emacs/lisp/org/org
~/sources/org-mode/lisp/ob-R hides /home/youngfrog/sources/running-emacs/lisp/org/ob-R
~/sources/org-mode/lisp/ob-C hides /home/youngfrog/sources/running-emacs/lisp/org/ob-C
~/sources/org-mode/lisp/ob-lob hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lob
~/sources/org-mode/lisp/ob-awk hides /home/youngfrog/sources/running-emacs/lisp/org/ob-awk
~/sources/org-mode/lisp/ob-clojure hides /home/youngfrog/sources/running-emacs/lisp/org/ob-clojure
~/sources/org-mode/lisp/org-faces hides /home/youngfrog/sources/running-emacs/lisp/org/org-faces
~/sources/org-mode/lisp/ox-odt hides /home/youngfrog/sources/running-emacs/lisp/org/ox-odt
~/sources/org-mode/lisp/ob-css hides /home/youngfrog/sources/running-emacs/lisp/org/ob-css
~/sources/org-mode/lisp/ob-lisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lisp
~/sources/org-mode/lisp/ob-lilypond hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lilypond
~/sources/org-mode/lisp/org-attach hides /home/youngfrog/sources/running-emacs/lisp/org/org-attach
~/sources/org-mode/lisp/ob-emacs-lisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-emacs-lisp
~/sources/org-mode/lisp/ob-scala hides /home/youngfrog/sources/running-emacs/lisp/org/ob-scala
~/sources/org-mode/lisp/ob-js hides /home/youngfrog/sources/running-emacs/lisp/org/ob-js
~/sources/org-mode/lisp/org-id hides /home/youngfrog/sources/running-emacs/lisp/org/org-id
~/sources/org-mode/lisp/org-loaddefs hides /home/youngfrog/sources/running-emacs/lisp/org/org-loaddefs
/home/youngfrog/.emacs.d/elpa/tabulated-list-0/tabulated-list hides /home/youngfrog/sources/running-emacs/lisp/emacs-lisp/tabulated-list

Features:
(locate mailalias smtpmail url-queue shr-color color org-indent
org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
image-mode org-bibtex bibtex org-bbdb org-w3m url-cache debbugs-org
debbugs-gnu debbugs soap-client shadow bbdb-message emacsbug sendmail
vc-git gud reftex-dcr reftex-auc reftex reftex-vars preview prv-emacs
tex-buf font-latex latex tex-style tex dbus misearch multi-isearch
tramp-cache tramp-sh tramp tramp-compat tramp-loaddefs trampver
rcirc-color rcirc time-stamp gnus-draft flow-fill pp shr browse-url
mm-archive semantic/db-mode semantic/db semantic/idle semantic/format
ezimage semantic/tag-ls semantic/find semantic/ctxt semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local
cedet yasnippet assoc projectile pkg-info epl s completion ob-dot ob-R
ob-shell shell magit-key-mode magit view help-mode grep compile
diff-mode autorevert filenotify git-rebase-mode git-commit-mode log-edit
pcvs-util add-log sort gnus-cite mail-extr gnus-async gnus-bcklg qp
gnus-ml disp-table ffap thingatpt server nndraft nnmh nnmaildir gnutls
nnfolder parse-time bbdb-gnus bbdb-mua bbdb-com crm netrc network-stream
starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache
gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start
gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win gnus
gnus-ems nnheader mail-utils xterm hideshow org-caldav icalendar
diary-lib diary-loaddefs org-id latexenc ox-latex ox-icalendar ox-html
ox-ascii ox-publish ox org-element avl-tree url-dav url-http url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url-handlers etable
etable-selection-model etable-cell-renderer etable-table-column-model
etable-table-column etable-table-model eieio-base interval-list dash
helm-config helm-aliases bbdb bbdb-site timezone yf-asy preview-latex
mb-depth icomplete autoinsert hippie-exp warnings ert ewoc debug
jka-compr paredit windmove paren dired recentf tree-widget wid-edit
org-inlinetask winner ampc-autoloads nlinum-autoloads info
sicp-autoloads finder-inf w3-autoloads workspaces-autoloads
wtf-autoloads pcase discover makey-key-mode twittering-mode edmacro
kmacro epa derived epg epg-config tls cl-macs gv url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util url-parse auth-source eieio eieio-core gnus-util mm-util
mail-prsvr password-cache url-vars mailcap xml cl cl-loaddefs cl-lib
time cus-start cus-load two-mode-mode tex-site auto-loads ido-hacks ido
org byte-opt advice help-fns org-macro org-footnote org-pcomplete
pcomplete org-list org-faces org-entities time-date noutline outline
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu easymenu
calendar cal-loaddefs package use-package bytecomp byte-compile cconv
bind-key easy-mmode tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty emacs)

Memory information:
((conses 8 656834 83083)
 (symbols 24 62271 512)
 (miscs 20 1962 2817)
 (strings 16 152979 30540)
 (string-bytes 1 4975562)
 (vectors 8 55728)
 (vector-slots 4 979444 32758)
 (floats 8 895 956)
 (intervals 28 12031 1103)
 (buffers 512 136)
 (heap 1024 26255 7094))

-- 
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-02 11:03 bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it Nicolas Richard
@ 2014-04-02 16:26 ` Eli Zaretskii
  2014-04-02 17:57   ` Nicolas Richard
  2014-04-06 10:08   ` Nicolas Richard
  0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-04-02 16:26 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Wed, 02 Apr 2014 13:03:29 +0200
> 
> I got the following error message
> debug: Terminal 3 is locked, cannot read from it

This comes from keyboard.c, see the commentary there for details.

> It has already happened to me but I cannot reproduce.

Please try "C-h l" next time, and report the commands that cause this.

> This however only happeend to me in a situation where emacs is run
> (with -nw option) from gdb which is run from tmux and I connect to
> that through ssh and emacsclient.

Perhaps tmux tricks Emacs into some strange situation.

> In this specific occurrence of the problem, that initial frame was
> active (on the host computer) but I was connecting to the emacs session
> from ssh via emacsclient. There was a third frame also, a graphical one,
> on the host computer.
> 
> If I hit ESC ESC ESC, I get the error message again and enter a new
> level of recursive edit (i.e. another layer of brackets in the
> modeline). I can't escape those : C-] just makes also the error again +
> another level of recursive edit.

Do you have debug-on-error set non-nil or something?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-02 16:26 ` Eli Zaretskii
@ 2014-04-02 17:57   ` Nicolas Richard
  2014-04-02 20:22     ` Eli Zaretskii
  2014-04-06 10:08   ` Nicolas Richard
  1 sibling, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2014-04-02 17:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Nicolas Richard, 17170

Eli Zaretskii <eliz@gnu.org> writes:
> This comes from keyboard.c, see the commentary there for details.

Ok, will do.

> Please try "C-h l" next time, and report the commands that cause this.

The lossage in the bug report is pretty close to the problem. It happend
while doing C-c C-e ; which calls LaTeX-environment.

I must say however that that command often triggers an error on my
system due to my setup described in bug#17132, and so my guess is that
it is the error which causes emacs to try to enter the debugger, and
only then the "Terminal locked" error appears.

> Do you have debug-on-error set non-nil or something?

It is set to t.

--
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-02 17:57   ` Nicolas Richard
@ 2014-04-02 20:22     ` Eli Zaretskii
  2014-04-03  7:16       ` Nicolas Richard
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-04-02 20:22 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: theonewiththeevillook, 17170

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17170@debbugs.gnu.org
> Date: Wed, 02 Apr 2014 19:57:24 +0200
> 
> > Do you have debug-on-error set non-nil or something?
> 
> It is set to t.

I'm guessing that keeping it at nil will allow you to continue from
that error, instead of being stuck in an endless loop of recursive
editing.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-02 20:22     ` Eli Zaretskii
@ 2014-04-03  7:16       ` Nicolas Richard
  0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Richard @ 2014-04-03  7:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17170

Le 02/04/2014 22:22, Eli Zaretskii a écrit :
> I'm guessing that keeping it at nil will allow you to continue from
> that error, instead of being stuck in an endless loop of recursive
> editing.

Indeed. Now if I do C-], I  get "No catch for tag: exit"

-- 
Nico.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-02 16:26 ` Eli Zaretskii
  2014-04-02 17:57   ` Nicolas Richard
@ 2014-04-06 10:08   ` Nicolas Richard
  2014-04-06 16:25     ` Eli Zaretskii
  1 sibling, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2014-04-06 10:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Nicolas Richard, 17170

Eli Zaretskii <eliz@gnu.org> writes:
> Please try "C-h l" next time, and report the commands that cause this.

It just happened again. Again, I'm in emacs -nw through gdb through tmux
through ssh. Again, I apparently have left one GUI frame open on my
remote box.

When I saw the error, I did:
C-x C-k e		;; edit-kbd-macro
C-h l			;; view-lossage

The output isn't very interesting because most command names are wrong
(everytime I hit an arrow key, it reports "ESC O" then one of A B C D
separately), but here's the last bits :

C-c NUL			;; rcirc-next-active-buffer
C-x K
C-u C-u C-c NUL		;; rcirc-next-active-buffer
C-z			;; suspend-frame
C-x C-k e		;; edit-kbd-macro
C-h l			;; view-lossage

The error appeared when I did C-z for suspend-frame. "C-x K" kills
current buffer.

Note that suspend-frame makes an error:
x-win-suspend-error: Cannot suspend Emacs while running under X

If I do M-: (debug) RET, I get the "Terminal locked" message, and enter
another level of recursive edit and can't exit it (because of "No catch
for tag: exit").

At this moment I have three pairs of brackets in the modeline.

Now, I deleted the distant graphical frame (with (delete-frame (car
(frame-list))))

At this point M-: (debug) doesn't throw the terminal locked error
anymore and enter the debugger correctly (entering a 4th pair of
brackets ), and I can exit the debugger correctly too, but I'm stuck
within those 3 pairs of brackets. So it seems that the remote graphical
frame really was a problem and entered me into a weird state.

-- 
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-06 10:08   ` Nicolas Richard
@ 2014-04-06 16:25     ` Eli Zaretskii
  2014-04-06 16:41       ` Nicolas Richard
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-04-06 16:25 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17170@debbugs.gnu.org
> Date: Sun, 06 Apr 2014 12:08:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Please try "C-h l" next time, and report the commands that cause this.
> 
> It just happened again. Again, I'm in emacs -nw through gdb through tmux
> through ssh. Again, I apparently have left one GUI frame open on my
> remote box.

I'm confused: you in "emacs -nw", but you have a GUI frame open?  How
can both of these happen in the same session?

> C-c NUL			;; rcirc-next-active-buffer
> C-x K
> C-u C-u C-c NUL		;; rcirc-next-active-buffer
> C-z			;; suspend-frame
> C-x C-k e		;; edit-kbd-macro
> C-h l			;; view-lossage
> 
> The error appeared when I did C-z for suspend-frame. "C-x K" kills
> current buffer.
> 
> Note that suspend-frame makes an error:
> x-win-suspend-error: Cannot suspend Emacs while running under X

Looks like Emacs doesn't know it has a TTY frame, and thinks you are
in a GUI frame?

> If I do M-: (debug) RET, I get the "Terminal locked" message, and enter
> another level of recursive edit and can't exit it (because of "No catch
> for tag: exit").
> 
> At this moment I have three pairs of brackets in the modeline.
> 
> Now, I deleted the distant graphical frame (with (delete-frame (car
> (frame-list))))
> 
> At this point M-: (debug) doesn't throw the terminal locked error
> anymore and enter the debugger correctly (entering a 4th pair of
> brackets ), and I can exit the debugger correctly too, but I'm stuck
> within those 3 pairs of brackets. So it seems that the remote graphical
> frame really was a problem and entered me into a weird state.

Please describe how you started the remote session, and how you got
into "emacs -nw" in the same session.  There's something I must be
missing here.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-06 16:25     ` Eli Zaretskii
@ 2014-04-06 16:41       ` Nicolas Richard
  2014-04-06 17:00         ` Eli Zaretskii
  2014-04-06 17:01         ` Eli Zaretskii
  0 siblings, 2 replies; 24+ messages in thread
From: Nicolas Richard @ 2014-04-06 16:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Nicolas Richard, 17170

Eli Zaretskii <eliz@gnu.org> writes:
> Please describe how you started the remote session, and how you got
> into "emacs -nw" in the same session.  There's something I must be
> missing here.

the remote session was started by opening gnome-terminal, then doing:
$ tmux # this starts a new tmux session.
$ cd ~/path/to/emacs/src
$ gdb emacs # drops me in gdb.
(gdb) r -nw

now emacs is started. I can detach from tmux and open graphical frames
using "emacsclient -c".

When working remotely, I can either run emacsclient from ssh, or run
"tmux a" for reattaching the initial frame. The reason I do this is to
be able to reattach to the gdb session in case it takes control and I'm
working over ssh.

I hope the picture is now complete.

-- 
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-06 16:41       ` Nicolas Richard
@ 2014-04-06 17:00         ` Eli Zaretskii
  2014-04-06 17:01         ` Eli Zaretskii
  1 sibling, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-04-06 17:00 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: theonewiththeevillook, 17170

> X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
> 	RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17170@debbugs.gnu.org
> Date: Sun, 06 Apr 2014 18:41:54 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Please describe how you started the remote session, and how you got
> > into "emacs -nw" in the same session.  There's something I must be
> > missing here.
> 
> the remote session was started by opening gnome-terminal, then doing:
> $ tmux # this starts a new tmux session.
> $ cd ~/path/to/emacs/src
> $ gdb emacs # drops me in gdb.
> (gdb) r -nw
> 
> now emacs is started. I can detach from tmux and open graphical frames
> using "emacsclient -c".
> 
> When working remotely, I can either run emacsclient from ssh, or run
> "tmux a" for reattaching the initial frame. The reason I do this is to
> be able to reattach to the gdb session in case it takes control and I'm
> working over ssh.
> 
> I hope the picture is now complete.
> 
> -- 
> Nico.
> 





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-06 16:41       ` Nicolas Richard
  2014-04-06 17:00         ` Eli Zaretskii
@ 2014-04-06 17:01         ` Eli Zaretskii
  2014-05-07 11:07           ` Nicolas Richard
  1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-04-06 17:01 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: theonewiththeevillook, 17170

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17170@debbugs.gnu.org
> Date: Sun, 06 Apr 2014 18:41:54 +0200
> 
> the remote session was started by opening gnome-terminal, then doing:
> $ tmux # this starts a new tmux session.
> $ cd ~/path/to/emacs/src
> $ gdb emacs # drops me in gdb.
> (gdb) r -nw
> 
> now emacs is started. I can detach from tmux and open graphical frames
> using "emacsclient -c".
> 
> When working remotely, I can either run emacsclient from ssh, or run
> "tmux a" for reattaching the initial frame. The reason I do this is to
> be able to reattach to the gdb session in case it takes control and I'm
> working over ssh.
> 
> I hope the picture is now complete.

Yes, thanks.  However, I have no idea what does this tmux use do to
Emacs.  I guess someone who does should chime in.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-04-06 17:01         ` Eli Zaretskii
@ 2014-05-07 11:07           ` Nicolas Richard
  2014-05-07 15:17             ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2014-05-07 11:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Nicolas Richard, 17170

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,  17170@debbugs.gnu.org
>> Date: Sun, 06 Apr 2014 18:41:54 +0200
>> 
>> the remote session was started by opening gnome-terminal, then doing:
>> $ tmux # this starts a new tmux session.
>> $ cd ~/path/to/emacs/src
>> $ gdb emacs # drops me in gdb.
>> (gdb) r -nw
>> 
>> now emacs is started. I can detach from tmux and open graphical frames
>> using "emacsclient -c".
>> 
>> When working remotely, I can either run emacsclient from ssh, or run
>> "tmux a" for reattaching the initial frame. The reason I do this is to
>> be able to reattach to the gdb session in case it takes control and I'm
>> working over ssh.
>> 
>> I hope the picture is now complete.
>
> Yes, thanks.  However, I have no idea what does this tmux use do to
> Emacs.  I guess someone who does should chime in.

Could it be that the patch in bug#17413 will fix this problem ?

-- 
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-05-07 11:07           ` Nicolas Richard
@ 2014-05-07 15:17             ` Eli Zaretskii
  2014-05-07 15:26               ` Nicolas Richard
  2015-03-20 15:47               ` Nicolas Richard
  0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-05-07 15:17 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

> 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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-05-07 15:17             ` Eli Zaretskii
@ 2014-05-07 15:26               ` Nicolas Richard
  2015-03-20 15:47               ` Nicolas Richard
  1 sibling, 0 replies; 24+ messages in thread
From: Nicolas Richard @ 2014-05-07 15:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17170

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?

Because I can't reproduce my bug.

In fact I'll admit that my previous message was sent a bit hastily : I
was trying to cancel it and instead it got sent. Sorry for that noise.

-- 
Nico.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2014-05-07 15:17             ` Eli Zaretskii
  2014-05-07 15:26               ` Nicolas Richard
@ 2015-03-20 15:47               ` Nicolas Richard
  2015-03-20 16:42                 ` Eli Zaretskii
  2015-03-20 19:54                 ` martin rudalics
  1 sibling, 2 replies; 24+ messages in thread
From: Nicolas Richard @ 2015-03-20 15:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17170

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.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 15:47               ` Nicolas Richard
@ 2015-03-20 16:42                 ` Eli Zaretskii
  2015-03-20 16:55                   ` Nicolas Richard
  2015-03-20 19:54                 ` martin rudalics
  1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-03-20 16:42 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

> Date: Fri, 20 Mar 2015 16:47:50 +0100
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> CC: 17170@debbugs.gnu.org
> 
> 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 ?

Hard to tell.  Can you be more specific about "access that frame"?
What kind of access are we talking about?

What happens if you delete that frame?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 16:42                 ` Eli Zaretskii
@ 2015-03-20 16:55                   ` Nicolas Richard
  2015-03-20 17:47                     ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2015-03-20 16:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17170

Le 20/03/2015 17:42, Eli Zaretskii a écrit :
>> Date: Fri, 20 Mar 2015 16:47:50 +0100
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> CC: 17170@debbugs.gnu.org
>> 
>> 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 ?
> 
> Hard to tell.  Can you be more specific about "access that frame"?
> What kind of access are we talking about?

IMO that frame should not ever be used for displaying a buffer, so if emacs ever tries to do that, I want to know why it does it.

> What happens if you delete that frame?

I did (delete-frame (cadr (frame-list))), and now I can't delete my GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to exit emacs. If I do C-x 5 0, I get:
Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")

Nicolas.






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 16:55                   ` Nicolas Richard
@ 2015-03-20 17:47                     ` Eli Zaretskii
  2015-03-20 18:37                       ` Nicolas Richard
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-03-20 17:47 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

> Date: Fri, 20 Mar 2015 17:55:20 +0100
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> CC: 17170@debbugs.gnu.org
> 
> Le 20/03/2015 17:42, Eli Zaretskii a écrit :
> >> Date: Fri, 20 Mar 2015 16:47:50 +0100
> >> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> >> CC: 17170@debbugs.gnu.org
> >> 
> >> 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 ?
> > 
> > Hard to tell.  Can you be more specific about "access that frame"?
> > What kind of access are we talking about?
> 
> IMO that frame should not ever be used for displaying a buffer

Why not?  Isn't it just a regular frame?

> > What happens if you delete that frame?
> 
> I did (delete-frame (cadr (frame-list))), and now I can't delete my GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to exit emacs. If I do C-x 5 0, I get:
> Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")

That's expected, but the question is does the problem go away?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 17:47                     ` Eli Zaretskii
@ 2015-03-20 18:37                       ` Nicolas Richard
  0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Richard @ 2015-03-20 18:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Nicolas Richard, 17170

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> IMO that frame should not ever be used for displaying a buffer
>
> Why not?  Isn't it just a regular frame?

No : I never see it. IIUC running "emacs --daemon" creates that frame
but it is never shown to me.

>> > What happens if you delete that frame?
>> 
>> I did (delete-frame (cadr (frame-list))), and now I can't delete my
>> GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to
>> exit emacs. If I do C-x 5 0, I get:
>> Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")
>
> That's expected, but the question is does the problem go away?

The problem was already gone after changing debugger-previous-window.

-- 
Nicolas





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 15:47               ` Nicolas Richard
  2015-03-20 16:42                 ` Eli Zaretskii
@ 2015-03-20 19:54                 ` martin rudalics
  2015-03-21 17:46                   ` Nicolas Richard
  1 sibling, 1 reply; 24+ messages in thread
From: martin rudalics @ 2015-03-20 19:54 UTC (permalink / raw)
  To: Nicolas Richard, Eli Zaretskii; +Cc: 17170

 > ;; 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").

When it happens again please tell me the value of
`debugger-previous-window'.  AFAICT this can only happen when that
window was shown on the "initial frame F1" before.

martin





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-20 19:54                 ` martin rudalics
@ 2015-03-21 17:46                   ` Nicolas Richard
  2015-03-22 12:05                     ` martin rudalics
  0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2015-03-21 17:46 UTC (permalink / raw)
  To: martin rudalics; +Cc: Nicolas Richard, 17170

Hi martin,

martin rudalics <rudalics@gmx.at> writes:
>> ;; 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").
>
> When it happens again please tell me the value of
> `debugger-previous-window'.  AFAICT this can only happen when that
> window was shown on the "initial frame F1" before.

Yes it was a window on that frame (window 4 IIRC). I remember that
because this is the reason I did
    (setq debugger-previous-window (selected-window))
to bring the debugger back to my frame.

-- 
Nicolas.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-21 17:46                   ` Nicolas Richard
@ 2015-03-22 12:05                     ` martin rudalics
  2015-03-22 17:56                       ` Nicolas Richard
  0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2015-03-22 12:05 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

 >> When it happens again please tell me the value of
 >> `debugger-previous-window'.  AFAICT this can only happen when that
 >> window was shown on the "initial frame F1" before.
 >
 > Yes it was a window on that frame (window 4 IIRC). I remember that
 > because this is the reason I did
 >      (setq debugger-previous-window (selected-window))
 > to bring the debugger back to my frame.

I can't understand what happened here because the only way to set
`debugger-previous-window' is via invoking `debug' and then doing
unconditionally

(setq debugger-window (selected-window))

followed by

(setq debugger-previous-window debugger-window))

so the window must have been the selected window when `debug' was called
the last time and Emacs should have complained then already.

Anyway.  I checked in a fix for Emacs 24.5 which should avoid this
problem now.  If you want to try it immediately please apply:

--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -192,7 +192,9 @@ first will be printed into the backtrace buffer."
  	       debugger-buffer
  	       `((display-buffer-reuse-window
  		  display-buffer-in-previous-window)
-		  . (,(when debugger-previous-window
+		 . (,(when (and (window-live-p debugger-previous-window)
+				(frame-visible-p
+				 (window-frame debugger-previous-window)))
  			`(previous-window . ,debugger-previous-window)))))
  	      (setq debugger-window (selected-window))
  	      (if (eq debugger-previous-window debugger-window)

martin





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-22 12:05                     ` martin rudalics
@ 2015-03-22 17:56                       ` Nicolas Richard
  2015-12-26 14:08                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Richard @ 2015-03-22 17:56 UTC (permalink / raw)
  To: martin rudalics; +Cc: Nicolas Richard, 17170

martin rudalics <rudalics@gmx.at> writes:
> so the window must have been the selected window when `debug' was called
> the last time and Emacs should have complained then already.

I didn't check the value of debugger-previous-window right after the
first complaint. I can try to do that, if it happens again, but since it
only happens in case of an error, my first reaction usually is to try
the command again (because I assume I made an error myself) and then
it's too late.

> Anyway.  I checked in a fix for Emacs 24.5 which should avoid this
> problem now.  If you want to try it immediately please apply:

Thanks.

-- 
Nicolas





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-03-22 17:56                       ` Nicolas Richard
@ 2015-12-26 14:08                         ` Lars Ingebrigtsen
  2015-12-26 19:15                           ` Nicolas Richard
  0 siblings, 1 reply; 24+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-26 14:08 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: 17170

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> martin rudalics <rudalics@gmx.at> writes:
>> so the window must have been the selected window when `debug' was called
>> the last time and Emacs should have complained then already.
>
> I didn't check the value of debugger-previous-window right after the
> first complaint. I can try to do that, if it happens again, but since it
> only happens in case of an error, my first reaction usually is to try
> the command again (because I assume I made an error myself) and then
> it's too late.

Are you still seeing this problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it
  2015-12-26 14:08                         ` Lars Ingebrigtsen
@ 2015-12-26 19:15                           ` Nicolas Richard
  0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Richard @ 2015-12-26 19:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 17170-done

Hi,

Lars Ingebrigtsen writes:

> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>> so the window must have been the selected window when `debug' was called
>>> the last time and Emacs should have complained then already.
>>
>> I didn't check the value of debugger-previous-window right after the
>> first complaint. I can try to do that, if it happens again, but since it
>> only happens in case of an error, my first reaction usually is to try
>> the command again (because I assume I made an error myself) and then
>> it's too late.
>
> Are you still seeing this problem?

Probably not, or I got used to it (unlikely). I close the bug for now,
thanks for your mail.

Nicolas.





^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2015-12-26 19:15 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-02 11:03 bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read from it Nicolas Richard
2014-04-02 16:26 ` Eli Zaretskii
2014-04-02 17:57   ` Nicolas Richard
2014-04-02 20:22     ` Eli Zaretskii
2014-04-03  7:16       ` Nicolas Richard
2014-04-06 10:08   ` Nicolas Richard
2014-04-06 16:25     ` Eli Zaretskii
2014-04-06 16:41       ` Nicolas Richard
2014-04-06 17:00         ` Eli Zaretskii
2014-04-06 17:01         ` Eli Zaretskii
2014-05-07 11:07           ` Nicolas Richard
2014-05-07 15:17             ` Eli Zaretskii
2014-05-07 15:26               ` Nicolas Richard
2015-03-20 15:47               ` Nicolas Richard
2015-03-20 16:42                 ` Eli Zaretskii
2015-03-20 16:55                   ` Nicolas Richard
2015-03-20 17:47                     ` Eli Zaretskii
2015-03-20 18:37                       ` Nicolas Richard
2015-03-20 19:54                 ` martin rudalics
2015-03-21 17:46                   ` Nicolas Richard
2015-03-22 12:05                     ` martin rudalics
2015-03-22 17:56                       ` Nicolas Richard
2015-12-26 14:08                         ` Lars Ingebrigtsen
2015-12-26 19:15                           ` Nicolas Richard

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).