Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site emacs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!cca!emacs!pz From: pz@emacs.UUCP (Paul Czarnecki) Newsgroups: net.emacs Subject: Re: emacs mouse support Message-ID: <4@emacs.UUCP> Date: Thu, 16-Jan-86 08:09:32 EST Article-I.D.: emacs.4 Posted: Thu Jan 16 08:09:32 1986 Date-Received: Sat, 18-Jan-86 01:15:03 EST References: <912@mit-eddie.UUCP> Organization: Uniworks Inc., Wellesley, MA Lines: 180 Mouse Protocol First off, I am an employee of Uniworks Inc. At Uniworks I have written a mouse interface to Emacs. A lot of the design issues discussed in these articles (and probably future ones) are issues that I also had to handle. These issues are not specific to our product, they could apply to ANY ascii window manager with a mouse. See the disclaimer at the bottom. In <912@mit-eddie.UUCP> Ian Horswill writes: H> In <914@mit-eddie.UUCP> J. Greg Davidson writes: D> H> A few months ago I wrote a quick kludge for the Sun workstation which H> I called "emacstool". It was simply a copy of the tty window driver H> which I had modified to send escape sequences when mouse events H> occurred. ... H> A second reason why I like the notion of an "ascii mouse" protocol is H> that it allows me to perform mouse operations even when emacs is not H> running on a machine with a mouse. For example, I can run emacstool H> on a sun, login on a vax from emacstool, and then run emacs with the H> mouse support code loaded, and do all of the things which I can do on H> a sun on the vax. For many of the same reasons I also wrote an "emacstool" that talks to Emacs via a pipe. Dumb terminals don't have to use it , system dependent code is also isolated. (The bit about remote usage is cute, I never thought of that!) A disadvantage is that the emacstool process does not know about emacsy things. Since the emacstool process knows about SunWindows it is the emacstool process that draws graphic icons. Doing things like throwing up an hourglass during a file IO are cute but not possible under this implementation. H> My questions for the group are thus: H> - What work, if any, has already been done? Almost completed here. (Uniworks, Inc.) Several pre-release versions are already out and being used. H> - What do we do about commies who don't have three buttons? 3 buttons? Is that all? The Sun software makes allowances to 10 button mice! Alas, I did not encode for this (see the protocol below). Really though, I don't know what to do. A user with less buttons on his mouse will have to give up some functionality, the protocol should be able to handle it. (mine doesn't) H> - What should the actual protocol look like? and, I send: xxxxyyyy where Bound to Mouse Autoargument. This tells Emacs to start collecting numbers. This is just like or C-U . xxxx The x coords of the mouse in PIXELS! not characters. This gives a finer resolution to certain positioning jobs. I also found it much easier to work with since the size of the characters should be hidden from emacstool. (emacstool is NOT a text editor, it is only a mouse io handler) yyyy This is the y coords of the mouse in PIXELS. is bound to Prefix Mouse which says that a mouse command is occurring and to read the next character which has that event encoded in it. The event. It is bit encoded like: r m1 m2 n1 n2 l m r where: r is reserved m1,m2 is the two bit encoding for the MEOW value. These are zero in the transmission over the pipe. They are set by the Emacs process upon receipt. n1,n2 Is the two bit encoding for the number of clicks. The only exception to this is that a Still event is encoded as 1 click (even though none occurred) l,m,r These bits are set if that button took part in the event. The encoding of 0 0 0 1 1 0 0 0 is reserved for an error condition. This is sent if an illegal mouse event occurs. Of course MA, and PM are user settable to any single keystroke that you want. (never tried it but I guess you could make them multiple keystrokes) This protocol is fat. I will probably be encoding the xxxxyyyy stuff down into 4 characters. (pack them) I should also warn that this protocol lacks a lot. You cannot do shift, meta, and contol mouse events, nor can you give a mouse event a numeric argument. See my other article on what kind of events this generates. H> - What sorts of standard hooks should be incorporated into H> emacs? I really don't see the need for them. Since Emacs is keystroke driven and the mouse sends keystroke sequences, only the fact that certain commands are bound to mouse events are what signify mouse events. After the emacs process gets them they are no longer special. How can we have hooks for single character events? If someone makes a good case for Mouse Hooks I will add them. D> I think its a mistake to have emacs subdivide a single window on a D> workstation, therefore we don't want an emacs tool of the kind that D> Ian Horswill suggests. What we want are windowtools to manage the D> keyboard, mouse and display, and interface to a single emacs job D> through a standard protocol. I guess I would have to agree that this is the best theoretical approach but I think the tool process way is superior for implementation reasons. Doing separate processes is MUCH faster to do. (I mean in development time, not execution speed). I'll grant that your approach could (should) be the next generation in text editing engines but adding mice to CCA EMACS and Gnuemacs are both retrofits to existing technology. Under the multi process scheme a lot of Emacs features fall into place automatically. The dynamic help feature does not have to be touched. The keystroke recovery feature does not have to be touched. D> If we do it right, I claim this organization will allow (1) multiple D> display units per user, (2) N mouse buttons with single or multiple D> clicking, (3) keyboards with or without function keys, (4) D> proportional fonts, and much more, with a smaller and simpler emacs. ok, so your emacs gets smaller. But remember TANSTAAFL! Your `windowtools' would get larger. I must admit that the above with process server control would be really good. But it would not be TODAY. The idea of one, just one, emacs job is grand. (particularly since, as you mentioned, it would eliminate several layers of display management) Now how portable is this all going to be? With a separate process architecture, all you must do to port is rewrite the tool. This involves learning only a rudimentary knowledge of the window system. What you are proposing requires an in-depth knowledge of the window system. pZ Disclaimer: I am an employee of Uniworks Inc. What I have said here could be considered to be of a commercial nature. I don't think that this is the case. I tried to stick to technical issues related to mouse support of a generic Emacs. The facts represented in this article are the current official statement of Uniworks regarding mouse support for CCA EMACS. These are subject to change without notice. The opinions expressed in this article are my own and are not necessarily shared by anybody else at Uniworks. Anybody is free is use the ideas expressed in this article. (I would be immensely flattered it this happened.) You cannot suppress ideas. The code, however, you will have to pay for. -- -- My wife ran off with my best friend, and I miss him. Paul Czarnecki Uniworks, Inc. decvax!{cca,wanginst!infinet}!emacs!pz 20 William Street emacs!pz@cca-unix.ARPA Wellesley, MA 02181 (617) 235-2600