kramer@cs.toronto.edu ("Bryan M. Kramer") (05/31/90)
Is there any movement towards an emacs that makes real use of the capabilities of the X window system? For example, certain sunview textedit features would make editting much more efficient. In general, these are features that have been known in various editors, each of which makes editting more efficient: a) scroll bars b) hilighted selections (region between point and mark); secondary selections c) copy or cut and paste holding down a key and using the mouse to outline the region to be copied/moved (in Interlisp it was called shift-select). I personally like the openwindows style for selections. d) search commands that use the current selection to move e) use of multiple clicks to make smart selections --- in text mode this would be word sentence paragraph; in lisp mode atom s-expr f) draw the cursor between characters where it really is. g) use graphics to draw marks as well. h) use INDEPENT X windows for each window --> this means indepently shapable and moveable; allow them to shrink to icons and in cases where they display things such as direds or buffer menus, they would update themselves when opened. Generally functions such as meta dot, dired, buffer list should open new windows rather than change the contents of the current window. Personally, I think that h) would provide the biggest gain. Of course, in implementing it, implementing scroll bars would be trivial. Does such an editor exist for X? I don't want to go back to Interlisp. -- Bryan M. Kramer Department of Computer Science University of Toronto Toronto, ON
meissner@osf.org (Michael Meissner) (06/01/90)
In article <90May31.100818edt.14538@neat.cs.toronto.edu> kramer@cs.toronto.edu ("Bryan M. Kramer") writes: | Is there any movement towards an emacs that makes real use | of the capabilities of the X window system? For example, certain | sunview textedit features would make editting much more efficient. | In general, these are features that have been known in various | editors, each of which makes editting more efficient: | | a) scroll bars | b) hilighted selections (region between point and mark); secondary selections | c) copy or cut and paste holding down a key and using the mouse | to outline the region to be copied/moved (in Interlisp it was | called shift-select). I personally like the openwindows style for selections. | d) search commands that use the current selection to move | e) use of multiple clicks to make smart selections --- in text mode | this would be word sentence paragraph; in lisp mode atom s-expr | f) draw the cursor between characters where it really is. | g) use graphics to draw marks as well. | | h) use INDEPENT X windows for each window --> this means indepently shapable | and moveable; allow them to shrink to icons and in cases where they | display things such as direds or buffer menus, they would update themselves | when opened. Generally functions such as meta dot, dired, buffer list | should open new windows rather than change the contents of the current | window. | | | Personally, I think that h) would provide the biggest gain. | Of course, in implementing it, implementing scroll bars would be trivial. Epoch certainly has h) though it does it by adding a new abstration called 'screens', to which one or more emacs buffers can be displayed, and they add a bunch of new keystrokes like \C-Z 4 \C-f, find file in other screen. I believe it has hooks for a), b), c), and possibly d) and e). Epoch is based on emacs 18.55, and is available from anonymous FTP on the machine: a.cs.uiuc.edu, possibly via anonous UUCP from tut.cis.ohio-state.edu. There is a mailing list for epoch, though it's been quiet recently (send mail to epoch-request@cs.uiuc.edu to be added). It will be interesting to see what happens when the long rumored GNU version 19 hits the streets. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
defaria@hpclapd.HP.COM (Andy DeFaria) (06/01/90)
>Epoch certainly has h) though it does it by adding a new abstration >called 'screens', to which one or more emacs buffers can be displayed, >and they add a bunch of new keystrokes like \C-Z 4 \C-f, find file in >other screen. I believe it has hooks for a), b), c), and possibly d) >and e). I have Epoch here from HP (I think) and it does no such thing. If I try a \C-Z it beeps. I suppose you meant \C-X 4 \C-f which does execute find-file-in-other-window but this just splits the Epoch window into two and puts the other file in the lower half. Is there an Epoch that works? I tried ftp ov a.cs.uiuc.edu and my system said "Unknown host".
kcollett@urbana.mcd.mot.com (Kendall Collett) (06/02/90)
>>>>> On 31 May 90 19:07:37 GMT, meissner@osf.org (Michael Meissner) said:
meissner> Epoch certainly has h) though it does it by adding a new abstration
meissner> called 'screens', to which one or more emacs buffers can be displayed,
meissner> and they add a bunch of new keystrokes like \C-Z 4 \C-f, find file in
meissner> other screen. I believe it has hooks for a), b), c), and possibly d)
meissner> and e).
I've used epoch for a few months, so I can attest that having (h) is a
big plus. I do, however, have one problem with multiple windows under
emacs (at least as implemented in epoch) -- there is still only one
execution thread for all of the windows. This means that when I start
retrieving 300+ articles from comp.windows.x in one window, I cannot do
anything in parallel in the any of the other windows because emacs/epoch
is busy.
--
Kendall Collett kcollett@urbana.mcd.mot.com uiucuxc!udc!kcollett
Motorola MCD, Urbana Design Center DISCLAIMER: In expressing the above
1101 East University Avenue opinion, I am in no way acting as a
Urbana, IL 61801 representative of Motorola, Inc.
meissner@osf.org (Michael Meissner) (06/06/90)
In article <860008@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes: | >Epoch certainly has h) though it does it by adding a new abstration | >called 'screens', to which one or more emacs buffers can be displayed, | >and they add a bunch of new keystrokes like \C-Z 4 \C-f, find file in | >other screen. I believe it has hooks for a), b), c), and possibly d) | >and e). | | I have Epoch here from HP (I think) and it does no such thing. If I try a | \C-Z it beeps. I suppose you meant \C-X 4 \C-f which does execute | find-file-in-other-window but this just splits the Epoch window into two | and puts the other file in the lower half. Is there an Epoch that works? | I tried ftp ov a.cs.uiuc.edu and my system said "Unknown host". You need to load 3 .el (epoch, smk, and motion) files from the epoch-lisp-files directory. Here is the relavant section from my .emacs file: (defun mrm-epoch-switch-screen nil "Switch screen and then raise it" (interactive) (switch-screen) (raise-current-screen) (raise-minibuf)) (defun mrm-epoch-recenter (prefix) "Recenter under epoch raising the screen as well" (interactive "P") (recenter prefix) (epoch::raise-screen)) (if (not (boundp 'epoch::version)) (progn (load "term/x-win") (autoload 'x-mouse-help "x-mouse-help" nil t) (autoload 'x-mouse-prefix "x-mouse-help" nil t) (x-set-bell t) (x-flip-color)) (progn (setq auto-raise-screen nil) (setq include-system-name nil) (setq terminal-epoch t) (setq load-path (append load-path (list "/usr/sandboxes/meissner/emacs-18.55/epoch-lisp-files"))) (load "epoch") (load "smk-x-mouse") (load "motion") (global-set-key "\C-zo" 'mrm-epoch-switch-screen) (global-set-key "\C-l" 'mrm-epoch-recenter) (setq epoch::screen-properties (append (list (cons 'font "terminal_narrow14") (cons 'geometry "100x54") (cons 'reverse "True")) epoch::screen-properties)) (epoch::move-screen 7 68) (epoch::rebind-key "Prior" 0 "\e[5~") (epoch::rebind-key "Next" 0 "\e[6~") (epoch::rebind-key "KP_1" 0 "\C-v") (epoch::rebind-key "KP_2" 0 "\C-n") (epoch::rebind-key "KP_3" 0 "\e[b~") (epoch::rebind-key "KP_4" 0 "\C-b") (epoch::rebind-key "KP_5" 0 "\C-a") (epoch::rebind-key "KP_6" 0 "\C-f") (epoch::rebind-key "KP_7" 0 "\M-v") (epoch::rebind-key "KP_8" 0 "\C-p") (epoch::rebind-key "KP_9" 0 "\e[t~") (epoch::rebind-key "KP_F1" 0 "\e[p~") (epoch::rebind-key "KP_F2" 0 "\e[q~") (epoch::rebind-key "KP_F3" 0 "\e[r~") (epoch::rebind-key "KP_F4" 0 "\e[s~") (epoch::title "Epoch"))) -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
hastings@walnut.Berkeley.EDU (Mark Hastings) (06/07/90)
> From: kramer@cs.toronto.edu ("Bryan M. Kramer") > Is there any movement towards an emacs that makes real use > of the capabilities of the X window system? For example, certain > sunview textedit features would make editting much more efficient. > In general, these are features that have been known in various > editors, each of which makes editting more efficient: All this discussion of windowing emacs editors has encouraged me to discuss how our Pan editor (a research project here at UC Berkeley) addresses these issues. A rather detailed blurb about Pan written by a colleague appears at the end of this article. But first some preliminaries: Pan started out as a window-system based editor -- in fact it must be run under Sunview or X11. So the original design took advantage of many of the window system features discussed in this thread: > a) scroll bars > h) use INDEPENT X windows for each window --> this means indepently shapable > and moveable; allow them to shrink to icons and in cases where they > display things such as direds or buffer menus, they would update themselves > when opened. Generally functions such as meta dot, dired, buffer list > should open new windows rather than change the contents of the current > window. A Pan buffer may have any number of windows (zero, one, or more than one), and each window contains horizontal and vertical scrollbars for navigating through the entire document. This brings up the interesting issue of how tightly emacs binds navigation and editing operations. With scrollbars, you are free to scroll away from the insertion point. Pan keeps this from being confusing with (a) a policy of forcing the insertion point to be visible when changes occur and (b) providing the user with a command that scrolls to the point. With individual windows for each buffer, you can also experiment with additional status information beyond the normal "mode line" in emacs. > b) hilighted selections (region between point and mark); secondary selections > c) copy or cut and paste holding down a key and using the mouse > to outline the region to be copied/moved (in Interlisp it was > called shift-select). I personally like the openwindows style for selections. Pan indicates selection by underlining the text in the selection. The mouse can be used to make the selection (following the Sunview style of selecting). Note that this is another area where emacs tightly binds the current insertion point with the notion of selection. With mouse based selection, selections can be far removed from the actual insertion point. This makes possible single-step commands like "copy selection to point" in addition to all the usual ones supported by Emacs (and Pan). The following blurb doesn't include a rather lengthy annotated bibliography of Pan reports, but I can forward that to interested parties. Also, we hope to have a source distribution of Pan ready by the end of the summer. Compiling Pan will require users to have their own copy of Franz's Allegro Common Lisp (as most of the system is written in Common Lisp). I will announce more details when we get nearer to completion. And now for the blurb: Pan is an editing and browsing system that supports the development of complex software components having both textual and structural aspects. The primary objects of interest are referred to generically as documents. Documents include both objects with formalized structure, such as formal designs and program components, as well as traditional natural language texts. Pan's most notable features are its support for incremental checking and analysis and its tolerance for errors and anomalies. It has a number of other important properties. + Pan incrementally builds and maintains a collection of information about documents that can be shared with other tools. One kind of information concerns the presence, location, and description of document anomalies (traditionally syntax and static-semantic errors). + Pan users can freely mix text- and structure-oriented manipulations in the same visual editing field; no restrictions are placed on the ability to edit textually. + Pan is a multi-window, multiple-font, mouse-based editing system that is fully customizable and extensible in the spirit of Emacs. + A single Pan session may involve multiple languages. + Adding new languages by writing language descriptions is just one of Pan's extension mechanisms. + Pan is otherwise a full-featured editor. For example it includes a rich text-oriented command set, generalized undo, a file system directory browser, and an integrated online help system. Pan runs under the SunView window system, and has recently been ported to X11. Pan runs on Sun 3 workstations, and is currently being ported to DECstation and Sparcstation architectures. Pan was developed at the University of California, Berkeley as one of the PIPER projects. The current version of Pan, internally called Pan I, is a fully functional prototype; it is in use for ongoing research in language description and processing techniques, user-interface design, advanced program viewing methods, and related areas. Research projects based on Pan are in progress both at UC, Berkeley and at the University of New Mexico. The design of a successor to Pan I is also under way. --Mark Hastings (415) 642-4611 hastings@sequoia.berkeley.edu ..!ucbvax!sequoia!hastings --Mark Hastings (415) 642-4611 hastings@sequoia.berkeley.edu ..!ucbvax!sequoia!hastings