Re: Selection Problem and Multi Frame

[Adam Sulmicki]

[please cc me on reply, if possible]

does anyone else has this problem? I'm using 'x2x' (you can find it on 
freshmeat) to span two displays into one.

and i have identical problem. emacs 20.7.1 both from redhat rpm's for 
7.1 as well as the one I compiled myself from 20.7 sources.

GNU Emacs 20.7.1 (i686-pc-linux-gnu, X toolkit) of Sun Jun 24 2001 on  pepsi

I use command "Open New Display.." and enter name of the adjecent monitor.
like "styx:0.0"

one of the features of x2x is that i can copy and paste between those two 
displays and it works fine with programs like xterm.

however emacs will just hang for several minutes at time if I try to mark
text at one display and copy it to emacs window at another display.

I did some debugging starting emacs from gdb, attaching emacs to pid, 
ltrace,strace and 'ps -eo fname,wchan'

and conclusion is that emacs does not not hang on any specific library or 
system call, it is just as if the graphic front end was not updated, mabye
the Xsync or XFlush is needed (hmm that makes me think to recompile emacs 
with X asynchronous events disabled -- what's easiest way to do it ???)

in general, emacs spends most of it time in 
        emacs-20.7/src/xterm.c:XTflash()
and while externally (visually) it appears as if it had hung and does not
respond to any commands, i can see it going around that piece of code.

Robert Inder (inder@etl.go.jp) wrote:
: This bug report will be sent to the Free Software Foundation,
: not to your local site managers!!
: Please write in English, because the Emacs maintainers do not have
: translators to read other languages for them.

: In GNU Emacs 20.2.1 (sparc-sun-solaris2.6, X toolkit)
:  of Fri Jun 12 1998 on etlisdb.taiwa

: I have observed a problem involving the selection when emacs is
: operating on more than one X-windows display.

: When emacs has frames on two displays, using the mouse to select
: text on display A causes Emacs on display B to lock up.  Emacs on B remains
: locked while the selection on A remains highlighted.  When it is
: "un-hilighted" (because Emacs loses the selection to another program on
: Display A, or by typing Ctrl-G), display B comes back to life and responds
: to all the key strokes made while it was frozen.

: This problem occurs when emacs is started "-q".

: I have also observed a second problem, I cannot characterise it well,
: but maybe a general pointer will trigger an "aha!".  Roughly, Emacs gets
: into a race condition when it is asked for the selection on Display A while
: it is itself waiting for the value of the selection on Display B.  For
: example: suppose Emacs holds the selection on display A: the users does a
: "yank" on display B.  This causes Emacs to ask for the selection on display
: B, and wait until it times out.  If, during this interval, a process asks
: emacs to provide the value of the selection for Display A, Something Bad
: SOMETIMES Happens: Emacs spins its wheels, using 100% of the CPU but
: remaining completely unresponsive on both displays (^G does nothing)
: until one of the selection requests (I'm not sure which) times out, at
: which point things return to normal.

: ((BACKGROUND:

:   The reason I have found these problems is that I have written some
:   software that allows one X display to drive another (so one
:   keyboard/mouse can drive two machines).  I have two machines side-by-side
:   on my desk, doubling my screen space just by not junking my old machine.
:   So I have been using Emacs on multiple displays for many hours a day for
:   several months!
:   
:   For the most part, it goes just fine!  Contratulations to all!!
:   
:   I can see the first bug without my software being involved.  The second
:   bug is a problem because my software arranges for the two displays to
:   "share" a single selection: if emacs on one display asks for the
:   selection while it is itself holding it on the other machine, it ends up
:   (indirectly) asking itself for the selection....

:   Incidentally, I'd be happy to contribute the bridge/slave software for
:   distribution under the GPL, if anyone is interested....
: ))

: Robert.

: --------------------------------------------------------------------------
: Robert Inder,                               
(http://www.hcrc.ed.ac.uk/~robert/)
: NEDO Visiting Fellow, Electrotechnical Laboratory (ETL) 
(http://www.etl.go.jp/)
:                       Umezono 1-1-4, Tsukuba, Ibaraki 305, JAPAN
:      Research Fellow, HCRC, Edinburgh University    
(http://www.hcrc.ed.ac.uk/)
:                     2, Buccleuch Place, Edinburgh EH8 9LW SCOTLAND
: --------------------------------------------------------------------------

--

-- 
Adam
http://www.eax.com      The Supreme Headquarters of the 32 bit registers