dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/02/86)
>When I found out that vi 3.9 understood function keys and had >showmode (puts an I in the lower right corner when in insert >mode, R in Replace, r in replace), I thought "neato!" but after ... >The main problem with VI from a screen editor point of view is that it >is really a line-oriented screen editor: ... > Forward and back word (b & w) go around lines, but forward and > back character don't. Also, forward word gets stuck at the end > of a line if it ends with a space. ... > Vi always wants the cursor to be on top of a character, instead > of between characters, so you can't have a 0-length buffer, and > empty lines look like lines with one space (the only easy way to tell > them apart is to do an "x" on the line and see if it beeps). ... > The newline character is a magic cookie. I can't point the cursor > to it, and I can't treat it like a normal character. Therefore, > because you can't "x" it, vi has another random command: Join. > This is the crux of the problem. >The other problem is that it is NOT a WYSIWYG editor: > You type any change command (c,C,etc) and you get this > funny $ at the end of the changed region and the $ and the > text you changed aren't really there. *Many* times I've had > novices use the C command and hit spaces to the end of the line > because they wanted to get rid of text that they didn't know > was already "gone". Touchy Touchy. You have a very sharp definition of what a WYSIWYG editor is. And even if VI weren't, I doubt it would be a problem. What your basically saying here is that you don't like VI because it isn't a wordprocessor. Well, your right, it isn't. Your also correct in that it is difficult learn vi for the average user. VI was never meant to be a user-friendly editor. What it IS is an editor that allows you to do just about anything short of WYSIWYG-word-processing (another field entirely). It allows the EXPERIENCED user to work extremely fast... faster than even the most experienced user could ever work with a mouse-based editor. (Don't give me any hash about cursor positioning... that's only a very small part of the big picture). Mouse-based 'user friendly' editors are all an well, but completely useless once you get experienced. At the outset, the 'user friendly' mouse-based editor is easier to learn, but you get to a point where you simply cannot go any further (you know everything there is to know, you are typing/ moving the mouse as fast as you can), and when you get to this point, the VI user has the advantage because HIS limits are quite a bit higher than yours, and thus he can get things done faster. Not only that, but user-friendly editors have virtually NO programmability. Programmability implies things that you cannot do with a menu-driven editor. True Programmability allows the experienced user to do almost anything he wants. The ultimate in programmability is EMACS. Theoretically EMACS supercedes even VI. (Here I'm talking about a fully configured EMACS, not micro-EMACS). The only reason that VI is on par with EMACS is that some programmers LIKE the command-insert modes and do not like EMACS control sequences. The EMACS people, of course, have the oposite opinion. Lately, we have seen combination editors on the market... which have Menu and Mouse, but still base the editor on the keyboard. These types of editors are getting more popular as they are both easy to learn, and have extremely high limits once you do get experienced. I think that is where the generic 'EDITOR' will go in the future. Apple's "idiot box" idea just isn't making it en` ToTo. -Matt
c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) (10/03/86)
In article <8610022020.AA28814@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >(Don't give me any hash about cursor positioning... that's only a very small >part of the big picture). > >Mouse-based 'user friendly' editors are all an well, but completely useless >once you get experienced. At the outset, the 'user friendly' mouse-based >editor is easier to learn, but you get to a point where you simply cannot >go any further (you know everything there is to know, you are typing/ >moving the mouse as fast as you can), and when you get to this point, the >VI user has the advantage because HIS limits are quite a bit higher than >yours, and thus he can get things done faster. I disagree when you say that a mouse based editor has a lower limit. When I'm typing a paper, no matter what text processor I'm using, I don't use cursor movement controls. It's when I'm editing that I need to move around a lot. There is no way you can convince me that it is easier or faster to edit a bunch of text in vi than with a mouse based editor. A keyboard based editor is only faster when you have to mix movement and text entering. > >Not only that, but user-friendly editors have virtually NO programmability. >Programmability implies things that you cannot do with a menu-driven editor. >True Programmability allows the experienced user to do almost anything he >wants. The ultimate in programmability is EMACS. ... Ah! Here's the real key issue. The configurability is where most of the gain in speed can come from. But why can't a mouse or menu driven editor have these features? MEDIT for the Mac has some pretty sophisticated macro programmability and implements these in a menu. > >Lately, we have seen combination editors on the market... which have >Menu and Mouse, but still base the editor on the keyboard. These types >of editors are getting more popular as they are both easy to learn, and >have extremely high limits once you do get experienced. I think that is >where the generic 'EDITOR' will go in the future. Apple's "idiot box" >idea just isn't making it en` ToTo. > > -Matt The "idiot box" may not make it for you, but for many people who aren't friendly with computers, it is indispensable. Try to take even MacWrite away from somebody who doesn't like to mess with the details of using a computer. Don't believe that the whole world has the same aptitude for computers as you do! Apple's "idiot box" may just do more for the home computer market than any other innovation previously. (ok, so it's a romanticization, but it has some elements of truth). -Christian
guido@mcvax.uucp (Guido van Rossum) (10/15/86)
Matt Dillon: >Mouse-based 'user friendly' editors are all an well, but completely useless >once you get experienced. At the outset, the 'user friendly' mouse-based >editor is easier to learn, but you get to a point where you simply cannot >go any further (you know everything there is to know, you are typing/ >moving the mouse as fast as you can), and when you get to this point, the >VI user has the advantage because HIS limits are quite a bit higher than >yours, and thus he can get things done faster. > >Not only that, but user-friendly editors have virtually NO programmability. >Programmability implies things that you cannot do with a menu-driven editor. Oh yeah? Wait till mouse-based editors have been around as long and hacked as much as VI... Are we just discussing the merits of existing editors or also the potential of different paradigms? Why would it be impossible to add complete mouse support and standard cut/paste to an Emacs-like editor? ...Guido
rb@cci632.UUCP (Rex Ballard) (10/16/86)
In article <7107@boring.mcvax.UUCP> guido@boring.uucp (Guido van Rossum) writes: >Matt Dillon: >>Mouse-based 'user friendly' editors are all an well, but completely useless >>once you get experienced. Useless for what, layout, paragraph entry, spelling, graphics, ??? >>Not only that, but user-friendly editors have virtually NO programmability. >>Programmability implies things that you cannot do with a menu-driven editor. This is more a problem of immature technology than some constraint on the technology itself. Some of the early visual editors had virtually no programmability. VI for a Version 7 system isn't as programmable as TECO. GNU emacs is more programmable that MacWrite, because the basics behind full-screen systems is better understood. >Oh yeah? Wait till mouse-based editors have been around as long and >hacked as much as VI... Even then, there will be a great deal of work that should be done with a "key oriented" environment. Paragraph entry, spelling, and any other type of text-oriented data entry are excellent examples. When it comes to layout, organization, and presentation planning, the mouse is a definite win. In some cases, such as graphics data entry, it will depend on the nature of the data to be entered. >Are we just discussing the merits of existing >editors or also the potential of different paradigms? A little of both. Existing editors, and indications of evolutionary trends, tend to give a good idea of where things might eventually go. Mac products seem to be suffering from a profound lack of evolution. MacProject is probably one of the more interesting variations, but many products seem to be self-limited by the "Inside Mac Mentality". >Why would it be >impossible to add complete mouse support and standard cut/paste to an >Emacs-like editor? There is already an emacs editor which has some of these features. Microemacs 3.8? for the Atari ST has options for "mice" as well as fully supported function keys. > ...Guido Rex
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/16/86)
>From: guido@mcvax.uucp (Guido van Rossum) >Oh yeah? Wait till mouse-based editors have been around as long and >hacked as much as VI... Are we just discussing the merits of existing >editors or also the potential of different paradigms? Why would it be >impossible to add complete mouse support and standard cut/paste to an >Emacs-like editor? We are discussing the potential of different user interfaces for editors. Specifically, I was talking about word processing / programming, not drawing or paint programs . You said it, I didn't. "add complete". The point is that it would then not be solely based on the mouse, but rely on the keyboard for the more complex commandsd . I believe I covered this in my last posting. The fact is that an editor which allows the user to choose between the keyboard and mouse, or use BOTH the keyboard and the mouse, has the potential to beat out everything else in existance (or at least within the scope of our discussion). Such an editor should allow you to use the mouse and keyboard interchangably (not be dependant on either) for command entry (obviously you need the keyboard for text entry). The editor which uses the mouse exclusively for command entry comes dead last in my list. -Matt
heins@orion.UUCP (Michael T. Heins) (10/17/86)
In article <7107@boring.mcvax.UUCP> guido@boring.uucp (Guido van Rossum) writes: >... Why would it be >impossible to add complete mouse support and standard cut/paste to an >Emacs-like editor? > It wouldn't. I use John Brunner's uw program with GNU all the time. I have installed in GNU the mouse functions posted a while back by Chris Kent / Elgin Lee, and it works great! I find myself using the keyboard for most things, but for cut & paste, the mouse interface can't be beat. -- ...!hplabs!sdcrdcf!trwrb!orion!heins We are a way for the universe to know itself. -- Carl Sagan
julian@riacs.ARPA (Julian E. Gomez) (10/17/86)
Guido van Rossum writes: > Oh yeah? Wait till mouse-based editors have been around as long and > hacked as much as VI... Are we just discussing the merits of existing > editors or also the potential of different paradigms? Why would it be > impossible to add complete mouse support and standard cut/paste to an > Emacs-like editor? It's not. Here at RIACS we use mouse-driven EMACS. Matt Dillon writes: > Mouse-based 'user friendly' editors are all an well, but completely useless > once you get experienced. ... Xerox PARC demonstrates the contrary. A lot of people are judging mouse based operation by the Mac, Amiga, and Atari. The problem with such conclusions is that it assumes they are doing it optimally, which is far from the case. You would do better to study PARC experience with mice and user interfaces before drawing general conclusions. Perhaps someday personal computers will catch up, but right now they are a long way behind. The only things judgements about personal computer mouse driven editors are good for now is about particular products, not that style of user interface. -- "Good Golly Miss Molly" Julian "a tribble took it" Gomez {...decvax!decwrl!}julian@icarus.riacs.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/19/86)
>Matt Dillon writes: >> Mouse-based 'user friendly' editors are all an well, but completely useless >> once you get experienced. ... > >From: julian@riacs.ARPA (Julian E. Gomez) >Xerox PARC demonstrates the contrary. Now I don't know if you've taken my words out of context or not. If what Xerox PARC demonstrates is *solely* a mouse based editor (no command key sequences from the keyboard, only typing and simple edit keys), then it may refute my statement. However, if Xerox PARC's mouse-based editor has complex command sequences from the keyboard, then you've taken my words out of context. I specifically said that that applied only to editors which were *solely* mouse based. I also said in that message that those editors which allow both integrated mouse use and keyboard command sequences (possibly more complex than the mouse would offer) will eventually beat out everything else in existance (within the scope of keyboard+mouse). -Matt