Xref: utzoo gnu.emacs:2909 comp.emacs:8368 Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!think.com From: rlk@think.com (Robert Krawitz) Newsgroups: gnu.emacs,comp.emacs Subject: Re: Call for discussion: Emacs and window systems Keywords: V19, Window Systems, Mouse, Menus, needs, hopes, desires Message-ID: <36857@think.Think.COM> Date: 28 May 90 18:21:22 GMT References: <1990May25.092932.15008@postmaster@turing.ac.uk> Sender: news@Think.COM Reply-To: rlk@think.com (Robert Krawitz) Followup-To: gnu.emacs Organization: Thinking Machines Corp., Cambridge MA Lines: 47 In-reply-to: russell@glencoe.turing.ac.uk (Russell Ritchie) 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 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 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111