From xemacs-m  Mon May 12 14:48:50 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA26409
	for <xemacs-beta@xemacs.org>; Mon, 12 May 1997 14:48:48 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcpgh14001; Mon, 12 May 1997 15:48:49 -0400 (EDT)
Date: Mon, 12 May 1997 15:48:49 -0400 (EDT)
Message-Id: <QQcpgh14001.199705121948@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Cursor on different frames, different devices
In-Reply-To: <kigsoztypr2.fsf@jagor.srce.hr>
References: <kigsoztypr2.fsf@jagor.srce.hr>
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid (beta6)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Hrvoje Niksic writes:
 > Start `xemacs -nw', and use `M-x make-frame-on-display' to create an X
 > frame.  Try to move point on any of those frames, and you'll notice
 > that cursor movement is "locked" among the frames; any cursor
 > movements in the X frame results in the cursor movement on the TTY
 > frame, and vice versa.  This doesn't happen with multiple X frames.
 > 
 > Inspecting the matter shows that the cursor information is
 > console-local.  This is, of course, wrong, as it should be frame-local
 > (or window-local, or whatever).  The FORCE_CURSOR_UPDATE macro in
 > redisplay-tty.c takes a console argument.  Maybe I should update it to
 > take a frame arguments?

This is not a correct diagnosis.  redisplay-tty.c contains the
output routines used to make the display look like the computed
internal representation.  What you're seeing is actual window
point motion, not just a misplaced cursor, so changing an oputput
routine won't help.

I thought about this problem a few weeks ago and came to the
conclusion that the cause is due the concept of a selected input
device not being fully extended to consoles.

If point is changed in a buffer while the selected window is
displaying that buffer, then the window point (what you see as
the cursor) moves also.  Otherwise the window point does not move.
This window point motion is (wrongly) being extended across all
consoles that have a selected window displaying the buffer.

I don't know how hard it will be to fix as I spun this theory
without bothering to look at the code.

