Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!hplabs!tektronix!uw-beaver!cornell!jqj
From: jqj@cornell.UUCP (J Q Johnson)
Newsgroups: net.emacs
Subject: Re: emacs mouse support
Message-ID: <49@cornell.UUCP>
Date: Sun, 12-Jan-86 04:50:27 EST
Article-I.D.: cornell.49
Posted: Sun Jan 12 04:50:27 1986
Date-Received: Tue, 14-Jan-86 05:06:43 EST
References: <912@mit-eddie.UUCP>
Reply-To: jqj@cornell.UUCP (J Q Johnson)
Organization: Cornell Univ. CS Dept.
Lines: 56

jr@bbnccv.uucp (he has an arpa addr too, but I've lost it) did a very nice
package for the Bitgraph mouse based on the same premise -- an ASCII mouse.
I used his protocol and implemented support for the mouse in an Interlisp-D
terminal emulation window on a Dandelion.  Some comments:

1/ there are 2 separate issues, the design of the mouse protocol, and the
assignment of functions to mouse buttons.  When implementing the support
code in emacs the 2 should be kept very separate so that a user may
independently replace either the mouse protocol (when s/he moves to a
different workstation that supports different protocols) or the functions
(when s/he decides that chording LRM while holding down META should do
something different on all terminals s/he uses).

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.

3/ there is no standard for mouse protocols.  Each of the ascii mouse makers
(for attachement to your PC) uses a different protocol.  I very much like the
bitgraph protocol; I think it is well thought out and very general.  One
problem with it for Emacs use is that it transmits the mousecursor position
in pixels, which requires that the program (Emacs) know the size of the
font in the window.  Whatever protocol you use, it should be fairly
general; it should be able to handle arbitrarily large windows (hence the
mac protocol published in a previous message is bad), a fairly large number
of logical buttons, chording, button-down and button-up events, window
entry- and exit- events, etc.  For emacs purposes I don't think it's necessary
for the program to be able to track the mouse, but in general that's a nice
feature (allowing dragged highlighting, etc.), and so the protocol should
also support as an option periodic mouse position-report events.  Explicitly
unsupported, I think, should be local popup menus (pulldown might be ok).

4/ the function-bindings should be designed to degrade gracefully to
mice with different characteristics, notably different numbers of buttons.
Many mice, e.g. on the Mac, are 1-botton; others, e.g. on the Dandelion,
are 2-button.  So the command set should be arranged in a hierarchy.
On the other hand, you can use active regions very effectively to increase
the number of commands:  in jr's mouse support, the mouse-clicks mean different
things depending on whether you are in (1) the text of a window (2) a mode
line, (3) the minibuffer, (4) a scroll bar which he implements as the rightmost
(unused in gnuemacs except as a separator) column of a window.  Pointing and
scrolling seem to be the most important mouse functions to implement, with
deleting and undeleting a marked region immediately following.

Note also that the command set needs to make provision for local mouse 
functions, e.g. window-world control.  The usual way to handle this is that
the workstation's mouse support is modified so that mouseclicks in the
window's title or border are interpreted as window-world manipulation
commands, while clicks in the body of the window are sent to the host.
However, this gives up the ability to cut from one window and stuff into
a different terminal emulation window (which may perhaps be on a different
system).