russell@glencoe.turing.ac.uk (Russell Ritchie) (05/25/90)
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.
rlk@think.com (Robert Krawitz) (05/29/90)
I implemented two variants of menus under X10/Emacs18 (the popup menus, which were released, and "menu buffers", which were ordinary emacs buffers using a special major mode that interpreted the mouse position at the time of a click in user-definable ways, as well as handling things automatically like layout). Off the top of my head, I can see quite a few useful things that could be hashed out on such a newsgroup: 1) Real mouse support, as opposed to layering on top of an 8-bit character stream (and thus requiring a higher-level, somewhat unreliable protocol). 2) Context-sensitive mouse. This need not mean all-out hypertext, which could be done after a fashion (and isn't) with a standard terminal, but rather something as coarse-grained as per-buffer mouse behavior. With a facility like this, it would be possible to layer higher-level things on top of it, such as the menu buffers I described above (which totaled no more than 200 lines of emacs lisp code, including a simple demo). Unfortunately, the menu buffers never really worked too well, because certain mouse clicks would try to do things to the buffer before I could intercept them conveniently. 3) Multiple windows. Not exactly controversial in concept, but some of the applications could be interesting. 4) Extended text attributes. This obviously means things such as fonts (and colored text, on the appropriate display). The challenge here is to devise something that is usable on a terminal display that has, at most, one highlighting mode (such as the VT100), and that doesn't make such a hash of the file that it can't be edited by anything but emacs (such as what the Lisp Machines do, with embedded escape sequences). 5) An "emacs widget" of some kind. This was suggested to me by Mark Eichin <eichin@athena.mit.edu> in a recent conversation, on the grounds that it would be really useful and not much bigger than any of the other widgets floating around. While that may be an exaggeration on a number of counts, the idea seems useful, if somewhat X-specific. My own opinion is that some kind of authenticated client-server model would be most useful here, but it's a very interesting idea. I'm sure I could think of more ideas, and discussion of all of this would be a big win. -- ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111
davidm@uunet.UU.NET (David S. Masterson) (05/29/90)
In article <1990May25.092932.15008@postmaster@turing.ac.uk> russell@glencoe.turing.ac.uk (Russell Ritchie) writes: > > What does Emacs want or need from a window system? Might I suggest expanding this into "How can Emacs best make use of the multi-tasking environment of a windowing system?" I think a layering of the mechanisms by which Emacs takes advantage of a windowing system into multiple tasks will lead to greater flexibility in meeting new environments and the possibility of better shuffling of the resources that Emacs makes use of in the environment of the overall system. > 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. By layering the interface into multiple tasks, the ability to move to different windowing environments (and perhaps other environments) might be eased. Also, new tasks might be created for very different communication mechanisms (like a light pen or a bar-code reader). Obviously, though, this will require an Inter-Task Communication standard for Emacs (possibly TCL?). Also, with multiple tasks, Emacs resource utilization might be spread across systems to achieve better resource utilization. At the very least, Emacs may not have to be treated as one huge process requiring lots of resources by the operating system. The operating system (or beleagured system manager) might achieve better load balancing. > 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. > > + 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. Don't forget: + A facility to allow creation of new *true* windows on the screen. This should be useable to allow creation of both pop-up windows for information gathering (file-requesters, mode-setters, etc.) and windows for information display (did someone say graphics? :-) -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (05/29/90)
>>>>> In article <CIMSHOP!DAVIDM.90May28184707@uunet.UU.NET>, >>>>> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> By layering the interface into multiple tasks, the ability to David> move to different windowing environments (and perhaps other David> environments) might be eased. Also, new tasks might be created David> for very different communication mechanisms (like a light pen David> or a bar-code reader). Obviously, though, this will require an David> Inter-Task Communication standard for Emacs (possibly TCL?). How about Linda? -- -------------------------------------------------------------------- himacdonald@watdragon.uwaterloo.ca watmath!watdragon!himacdonald "Guns seldom solve any problems; they merely decide whose will shall prevail for the time being." - Brian Jarvis
barmar@think.com (Barry Margolin) (05/29/90)
In article <CIMSHOP!DAVIDM.90May28184707@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Might I suggest expanding this into "How can Emacs best make use of the >multi-tasking environment of a windowing system?" I think this is a completely separate (and much more difficult) issue, and it would not be wise to hold up releasing windowing features for this. I'm not sure what you mean by "multi-tasking environment of a windowing system" (the only system I know of where the window system provides the multi-tasking is MS/Windows). The systems that GNU Emacs runs on (mostly Unix-based) are multi-tasking even when they don't have a window system. And the kinds of things I'd want to do with a multi-tasking Emacs are independent of its windowing. Just as we have the ability to run programs in the background in a non-windowed Unix shell it would be nice to be able to run editor commands in the background in a non-windows Emacs; for instance, it would be nice to be able to start up a long-running keyboard macro and then edit another buffer while it is still running. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
davidm@uunet.UU.NET (David S. Masterson) (06/04/90)
In article <1990May29.152417.11800@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >>>>> In article <CIMSHOP!DAVIDM.90May28184707@uunet.UU.NET>, >>>>> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> By layering the interface into multiple tasks, the ability to David> move to different windowing environments (and perhaps other David> environments) might be eased. Also, new tasks might be created David> for very different communication mechanisms (like a light pen David> or a bar-code reader). Obviously, though, this will require an David> Inter-Task Communication standard for Emacs (possibly TCL?). How about Linda? How about it? (What is it?) -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
paj@mrcu (Paul Johnson) (06/05/90)
>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: <world>!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
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (06/05/90)
>>>>> In article <CIMSHOP!DAVIDM.90Jun4095608@uunet.UU.NET>, >>>>> David S. Masterson writes: David> In article <1990May29.152417.11800@maytag.waterloo.edu> David> Hamish Macdonald writes: David> How about Linda? David> How about it? (What is it?) A paradigm for interprocess communication. It is based on a global tuple space. Processes can enter/retrieve tuples to/from the tuple space. When retrieving a tuple, a template for the desired tuple is used to indicate the tuple which should be retrieved. It is not quite that simple, but I don't have a reference handy. One nifty feature is that it can be implemented such that tuple element evaluation can be done after a tuple is entered into the tuple space, to increase parallelism. I think that the tuple concept would fit in nicely with ELisp lists. -- -------------------------------------------------------------------- himacdonald@watdragon.uwaterloo.ca watmath!watdragon!himacdonald "Guns seldom solve any problems; they merely decide whose will shall prevail for the time being." - Brian Jarvis
wsd@cs.brown.edu (Wm. Scott `Spot' Draves) (06/07/90)
In article <525@argus.mrcu> paj@mrcu (Paul Johnson) writes:
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. [...]
This isn't true. The Mac gives us two solutions: 1) shift-click to
extend the selected region (this is a bit more general then
click-begin, click-end). 2) When click-dragging, if the mouse leaves
the text window, it scrolls.
2) Scroll bars (one per Emacs window, may be disabled for certain
special buffers). This is something that Emacs lacks.
horizontal ones too!!
--
Scott Draves Space... The Final Frontier
wsd@cs.brown.edu
uunet!brunix!wsd