Xref: utzoo gnu.emacs:2987 comp.emacs:8444 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stc!root44!hrc63!mrcu!paj From: paj@mrcu (Paul Johnson) Newsgroups: gnu.emacs,comp.emacs Subject: Re: Call for discussion: Emacs and window systems Message-ID: <525@argus.mrcu> Date: 5 Jun 90 10:49:40 GMT References: <1990May25.092932.15008@postmaster@turing.ac.uk> Reply-To: paj@uk.co.gec-mrc (Paul Johnson) Organization: GEC-Marconi Research Centre, Great Baddow, UK Lines: 110 Summary: Expires: Sender: Followup-To: Summary: Expires: Sender: Followup-To: >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? > >..... [discussion of window systems & problems with generic interfaces] > > [here are some 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... As a dedicated Emacs user/programmer and X user, I would like to present my notions: First, we need to decide the sort of things the WIMPS interface will be used for. Emacs does not support graphics (perhaps in V20? :-) ) so I see it being used for: 1) Application control (mouse based editing commands). For this we want popup menus and buttons kept in a separate window (Emacs or WIMPS). Menus are needed for window-specific commands such as "delete region" and buttons in a separate window for more generic commands such as "help" or "find-file". I am dubious about binding commands (except perhaps cursor motion) to specific mouse keys. 2) Edit control. For this we want to be able to mark areas of text (ie the Emacs region) using the mouse, and have these areas highlighted. On the one hand, the X style of hilighting (point and drag) is easy to use, but on the other hand it cannot mark a region larger than the screen. Perhaps we need two methods of marking text, one involving a single operation (point & drag), and the other involving two operations (point start & point end). We also need to be able to drag text up and down with the mouse. 3) Hypertext. It should be possible to make certain areas of text (as opposed to screen) sensitive to mouse operations. In this way cross-references can be followed simply by clicking the mouse on them. It would be useful if a range of hilight styles were available (eg bold text, underline, box, reverse-case) along with guidelines about use (eg reverse-case for selection, box for command buttons, bold for clickable cross references). This suggests a set of facilities for Elisp programmers: 1) Mouse events: basically we need a subset of the usual mouse events: buttons, window entry/exit and motion (for dragging text up and down). Motion events should not be buffered (otherwise we will get Emacs lagging behind). Expose and geometry events should be handled by Emacs. 2) Scroll bars (one per Emacs window, may be disabled for certain special buffers). This is something that Emacs lacks. 3) WIMPS window primitives: create, destroy, expose, hide. On the other hand, how are we going to integrate Emacs character windows (which we have now) with multiple WIMPS windows? I think that the Elisp abstraction should just be "window", allowing existing applications to use WIMPS windows and decreasing the amount of work for new applications. Emacs should maintain either a set of character windows or a set of WIMPS windows, not combinations of both. This leads to a problem with the selection of the active window: in character windows, this is done by Emacs, but in a WIMPS system it is done by the user. 4) Sensitive areas (a primitive for buttons). I imagine something a little like the Hypercard button system: an area which calls an Elisp function for certain events. Areas should be attatched either to a chunk of text or to a chunk of screen. In this way (for example) the main area of the screen would have mouse button and move events bound to cursor and scroll functions, while certain words might be hilighted as cross references and have smaller areas defined for them. 5) Text hilighting functions. See above. 6) Higher level facilities which use these primitives: region control using the mouse, dragging text and cursors. Button creation. Menu tree creation. Some link between WIMPS menus and keystrokes (so application programmers specify the user interface for both WIMPS and character terminals in one structure). A button panel mode which provides a list of buttons that can be activated by clicking the mouse or by using the cursor keys. I think that is about the end of my wish-list for Emacs 19. My best wishes to all those working on it, and thankyou for listening. Paul. -- Paul Johnson UUCP: !mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244