* bug#11993: Emacs frames on other display hang during recursive edit on a different display
@ 2012-07-19 3:34 mail
2020-12-07 17:10 ` Lars Ingebrigtsen
0 siblings, 1 reply; 3+ messages in thread
From: mail @ 2012-07-19 3:34 UTC (permalink / raw)
To: 11993
[-- Attachment #1: Type: text/plain, Size: 6266 bytes --]
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgement at that address.
Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.
Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':
emacs -Q
...opens a frame (X Window)
...select that window, use it a bit to see that all works
ESC-X make-frame-on-display
... type in display name
... note: in may case, the display is a different VNC session
... switch to the just opened emacs frame in that display, use it a
bit
to see that all works
... switch back, again, just to see that all works.
... in eother of the frames, type
ESC-X recursive-edit
... I am still able to work in the frame that initiated the
recursive
edit.
... However, in the other frames of the emacs, while I can select
the
frame (X Window), and the cursor changes from outline to filled, I
cannot do anything useful. The other frame(s) are hung: typing is
not
accepted, mouse clicks do not move the cursor.
... but the frame in which you typed recursive-edit still works
... switch back to that frame, type
ESC-X exit-recursive-edit
... everything now works, in all frames.
Further investigation shows that this hang occurs whenever the
minibuffer is open in another frame. I also find
http://www.mail-archive.com/emacs-pretest-bug@gnu.org/msg08103.html
to which Stallman responded:
Re: Emacs hangs on current display when the minibuffer is
active on another
display
Richard Stallman
Wed, 27 Sep 2006 19:15:16 -0700
If I leave the emacs on one
display with the minibuffer active, emacs on the other display
does
not respond to anything until the minibuffer input is resolved
(input
entered, or quit).
It is nearly impossible to fix this without making Emacs
multi-threaded. I hope that will be done some day, but I
don't know if anyone is working on it.
I suppose that I could give up and not report this bug.
However, (a) reporting that this occurs with recursive-edit as well as
minibuffer open may help the next person who encounters this bug, and
(b) while I can imagine ways that the minibuffrer problem may be
difficult to fix without multithreading (or good non-blocking
asynchronous I/O), I must admit that I cannot imagine why recursive-edit
would be like that.
Also (c) I could swear that I *have* been able to use recursive-edit
with multiple frames in the past, on older versions of emacs. However,
I
cannot reproduce this at the moment - all of the different versions of
emacs I have access to have this problem.
(By the way, my apologies for mailing this bug report from Microsoft
Outlook or Gmail, although it was prepared in EMACS.)
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/glew/import/emacs/emacs-24.1/install-dir-personal/share/emacs/24.1/etc/DEBUG.
In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
of 2012-07-13 on mipscs587
Windowing system distributor `The XFree86 Project, Inc', version
11.0.40300000
Configured using:
`configure '--with-gif=no'
'--prefix=/home/glew/import/emacs/emacs-24.1/install-dir-personal''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: C
value of $XMODIFIERS: nil
locale-coding-system: nil
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<help-echo> <down-mouse-1> <mouse-1> <escape> x m a
k e - f r a m e <tab> - o n <tab> <return> l o c a
l h o s t L : 1 <backspace> <backspace> <backspace>
: 1 2 <return> <switch-frame> <help-echo> <down-mouse-1>
<mouse-1> <escape> x r e c u r s i v e - e d u <backspace>
i t <return> <down-mouse-1> <mouse-1> <escape> x e
x i t - r e c u r s i v e - e d i t <return> <switch-frame>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1>
<mouse-1> q q q <down-mouse-1> <mouse-1> <backspace>
<backspace> <backspace> <escape> x r e p o r t - e
m a c s - b u g <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-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 loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)
[-- Attachment #2: Type: text/html, Size: 8698 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#11993: Emacs frames on other display hang during recursive edit on a different display
2012-07-19 3:34 bug#11993: Emacs frames on other display hang during recursive edit on a different display mail
@ 2020-12-07 17:10 ` Lars Ingebrigtsen
2021-01-20 17:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 3+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-07 17:10 UTC (permalink / raw)
To: mail; +Cc: 11993
mail@andy.glew.ca writes:
> Please describe exactly what actions triggered the bug, and
> the precise symptoms of the bug. If you can, give a recipe
> starting from `emacs -Q':
>
> emacs -Q
>
> ...opens a frame (X Window)
>
> ...select that window, use it a bit to see that all works
>
> ESC-X make-frame-on-display
>
> ... type in display name
> ... note: in may case, the display is a different VNC session
>
> ... switch to the just opened emacs frame in that display, use it a bit
> to see that all works
>
> ... switch back, again, just to see that all works.
>
> ... in eother of the frames, type
>
> ESC-X recursive-edit
>
> ... I am still able to work in the frame that initiated the recursive
> edit.
>
> ... However, in the other frames of the emacs, while I can select the
> frame (X Window), and the cursor changes from outline to filled, I
> cannot do anything useful. The other frame(s) are hung: typing is not
> accepted, mouse clicks do not move the cursor.
(This bug report unfortunately got no response at the time.)
I wasn't able to follow the recipe (because I don't use VNC), but I
can't talk about similar bugs in the recent past. Are you still seeing
this issue in more recent versions of Emacs?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#11993: Emacs frames on other display hang during recursive edit on a different display
2020-12-07 17:10 ` Lars Ingebrigtsen
@ 2021-01-20 17:07 ` Lars Ingebrigtsen
0 siblings, 0 replies; 3+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-20 17:07 UTC (permalink / raw)
To: mail; +Cc: 11993
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I wasn't able to follow the recipe (because I don't use VNC), but I
> haven't seen talk about similar bugs in the recent past. Are you still seeing
> this issue in more recent versions of Emacs?
More information was requested, but no response was given within a
month, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-01-20 17:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-19 3:34 bug#11993: Emacs frames on other display hang during recursive edit on a different display mail
2020-12-07 17:10 ` Lars Ingebrigtsen
2021-01-20 17:07 ` Lars Ingebrigtsen
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).