Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!vis!greg@nosc.ARPA
From: greg@nosc.ARPA
Newsgroups: net.emacs
Subject: Re: emacs mouse support
Message-ID: <914@mit-eddie.UUCP>
Date: Fri, 10-Jan-86 03:50:45 EST
Article-I.D.: mit-eddi.914
Posted: Fri Jan 10 03:50:45 1986
Date-Received: Sat, 11-Jan-86 07:14:50 EST
Sender: bcn@mit-eddi.UUCP
Organization: MIT, Cambridge, MA
Lines: 48

From: vis!greg@nosc.ARPA
I think its a mistake to have emacs subdivide a single window on a
workstation, therefore we don't want an emacs tool of the kind that
Ian Horswill suggests.  What we want are windowtools to manage the
keyboard, mouse and display, and interface to a single emacs job
through a standard protocol.

If we do it right, I claim this organization will allow (1) multiple
display units per user, (2) N mouse buttons with single or multiple
clicking, (3) keyboards with or without function keys, (4) proportional
fonts, and much more, with a smaller and simpler emacs.

A related need is for a process server protocol, so we can combine
remote processes with local processes connected to the same emacs job.
I only want one emacs job, regardless of how many processes I've got
or where they're running.  And I want to talk to processes (and
manipulate their windows) without regard to where they live.

On my display right now I have one huge shelltool containing an emacs
job where I'm handling my mail.  In a second shelltool I'm tip'ed over
to another machine where, underneath another emacs job, I'm doing an
ftp and monitoring its performance.  I have a third shelltool for
scratch work and some additional closed tools (showing as icons) are
available when needed.

It sounds nice, but is in fact very cumbersome.  With one local emacs
job in charge, I'd have a more integrated and consistent environment.
I'd also get rid of the expense of multiple layers of display management,
and windows trapped within windows.  Pointing and clicking, cutting and
pasting, etc., would be applicable with all objects and done in a
consistent manner.

Well, I trust that these suggestions will be provocative.  I'm willing
to start work right away on building such tools, but first we need to
have a consensus on how it should be done.  What functionality should
be pulled out of emacs and put in separate tools, and what protocols
shall we use to tie them all together?


_Greg


J. Greg Davidson			  Virtual Infinity Systems
(619) 452-8059               6231 Branting St; San Diego, CA 92122 
 
greg@vis.uucp				ucbvax--| telesoft--|
davidson@sdcsvax.uucp			decvax--+--sdcsvax--+--vis
davidson@ucsd.arpa			 ihnp4--|  noscvax--|