Xref: utzoo gnu.emacs:2902 comp.emacs:8363
Path: utzoo!utgpu!watserv1!watmath!uunet!mcsun!ukc!strath-cs!turing.ac.uk!news
From: russell@glencoe.turing.ac.uk (Russell Ritchie)
Newsgroups: gnu.emacs,comp.emacs
Subject: Call for discussion: Emacs and window systems
Keywords: V19, Window Systems, Mouse, Menus, needs, hopes, desires
Message-ID: <1990May25.092932.15008@postmaster@turing.ac.uk>
Date: 25 May 90 09:29:32 GMT
Sender: news@postmaster@turing.ac.uk
Reply-To: russell@uk.ac.strath.hci
Organization: Scottish HCI Centre, University of Strathclyde, Glasgow, Scotland.
Lines: 58

While the Emacs community awaits the announcement of Version 19, which
is rumoured to have extensive support for the X Window System, Russell
Ritchie and John Robinson offer the following discussion in the hope
that open debate may raise or solve issues pertaining to the
integration of window system and mouse support into Emacs.

	  What does Emacs want or need from a window system?
				  or
	 What should be in /etc/mousecap and /etc/windowcap?

With the current terminal-dependent Emacs code if you haven't got a
particular type of terminal (and don't read the Lisp source code) you
don't find out what other terminals can do. Fortunately this isn't
that much of a problem because most terminals are pretty similar in
the functionality they offer (at least as far as Emacs is concerned).

Unfortunately this isn't the case with window systems (yet): the
functionality offered to Emacs differs greatly. The issue is further
complicated by the fact that, typically, changing your window system
is a lot easier than changing your terminal type.

Currently Emacs supports a variety of window systems with a mix of C
and Lisp code (including X, SunView and NeWS). The facilities offered
by the support varies greatly and what documentation exists of the
differing facilities offered is scant. Further, the documentation is
usually couched in terminology specific to the particular window
system being supported, which can lead to inconsistencies for users
who are trying to use more than one system and expect window systems
to be integrated as transparently as other aspects of Emacs.

We suggest that there should be a base set of functionality offered in
all supported window systems, and that the documentation for that set
of functionality should reflect the fact that it is not window system
specific.

So what should this base set of functionality be? That's the $64,000
question. What do you want, what features are lacking in the mouse and
window system interface you use at present? To get the ball rolling
here are a couple of suggestions:

 + A Mouse interface that doesn't preclude keyboard input while the
   mouse is in use. This would allow the help key to be used during
   mouse events, enabling users to push down a mouse button, hit help,
   and find out what was happening, and find out if anything different
   would happen if the mouse was moved before the button was released. 

 + A similar facility for a Menu interface; allowing the mouse to talk
   to Emacs while you've got a menu up and are mousing around over the
   selections. This would enable allow a mouse button (or help key) to
   provide descriptive information about what various menu items do
   *before* they are selected (perhaps in the modeline, or a *Help*
   window, or a V19/Epoch *Help* Screen), another button would
   typically be bound to "doit", which could synonymous with RET.

Lisp Machine users will probably be experiencing a deep sensation of
deja vu, if you're one of them and there's a particular Zmacs facility
you miss a lot, or think the UNIX Emacs community might benefit from
hearing about, why not throw in your 2c.