Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!ittatc!dcdwest!sdcsvax!davidson
From: davidson@sdcsvax.UUCP (J. Greg Davidson)
Newsgroups: net.emacs
Subject: Re: emacs mouse support
Message-ID: <1306@sdcsvax.UUCP>
Date: Tue, 14-Jan-86 10:37:32 EST
Article-I.D.: sdcsvax.1306
Posted: Tue Jan 14 10:37:32 1986
Date-Received: Fri, 17-Jan-86 00:55:50 EST
Reply-To: davidson@sdcsvax.UUCP (J. Greg Davidson)
Distribution: net
Organization: EECS Dept. U.C. San Diego
Lines: 43


	From: jqj@cornell.UUCP (J Q Johnson)
	Subject: Re: emacs mouse support
	Date: 12 Jan 86 09:50:27 GMT
	Organization: Cornell Univ. CS Dept.

	1/ there are 2 separate issues, the design of the mouse protocol,
	and the assignment of functions to mouse buttons. 

I agree.  In fact, I'm not certain that the issue of buttons can be or
need be separated from the issue of keyboard function keys or keystrokes
in general.  On my SUN, some tools uses SHIFT with mouse buttons (despite
having 3 buttons), and I know the Mac really goes in for this.  Between
the number of ways of stroking different mice, and modulation with bucky
bits and prefixes, we have a pretty open universe.  What if we let mouse
buttons cause arbitrary keystrokes to be emitted, but followed by a
location sequence in a standard form?  Users can bind standard functions
to the former which read and interpret the latter.  Is this sufficient?

	2/ the issue of whether such a protocol is a good idea at all
	is a canard.  It is.  There will always be cases where I want
	to log in to a remote system (or to several remote systems in
	different windows) from my multi- window workstation, and run
	gnuemacs in a terminal emulation window.  In such an
	environment I definitely don't WANT gnuemacs to take over
	complete control of my display (I want to see my local desk
	accessories), but I do want my mouse.

Oh dear, I hope that this is not a comment on my recent windowtool proposal.
Its redundant for EMACS to be doing window management on a system which has
a custom window manager already.  Its equally mistaken for EMACS to take
over the display as it is for it to make crude windows inside of a terminal
emulation window.

I propose that when EMACS wants a window, it ask the window manager for one.
On a non-workstation, a default window manager would be used, running the
same code EMACS runs now, but through communications channels.  On a
workstation, a simpler window manager would pass the requests to the
workstation's window system, e.g., suntools.  Of course, there's no
requirement that all windows on the screen connect to EMACS, thought I
think that this would be natural for windows containing text.

_Greg