cs00jec@unccvax.uncc.edu (Jim Cain) (01/11/91)
Over the next few weeks, I will be putting the finishing touches on the beta version of my screen editor. It will have a non-modal interface with facilities for defining function keys and writing complete macros. It will have a full-feature stack-based scripting language (similar to PostScript) which will facilitate user-programmable functions. As it stands now, the editor has about 160 built-in functions. This is for my senior project, so it must be complete (user manual and all) by the end of this semester. Time constraints may force me to postpone implementation of some features, like facilitating automatic formatting based on the programming language being used (like emacs). What I would like to know is: Are there any useful features missing in the more popular editors? Any opinions on a good user interface? I would appreciate any suggestions as I go down the final stretch, molding the personality of this editor. Please send e-mail or post if there is adequate interest. Jim Cain Department of Computer Science College of Engineering The University of North Carolina at Charlotte cs00jec@unccvax.uncc.edu
staff@cadlab.sublink.ORG (Alex Martelli) (01/12/91)
My opinion: please do include enough programming power that a modal editor can be emulated; i.e. a good test for a modal editor is, can I do FULL vi in it. Full use of funny keys (sending escape sequences) optional popup help menus (with some timeout, e.g. on ^Y the menu will appear iff other keys are not ready 'at once', any keypress during painting of the menu may be obeyed while menu-painting is stopped or undone). Escape to other programming languages (i've got this nice italian-hyphenation routine in C, how do I integrate it seamlessly). Just a few thoughts off the top of my head. Please do summarize to the net in a while. -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
joshi@cs.uiuc.edu (Anil Joshi) (01/17/91)
cs00jec@unccvax.uncc.edu (Jim Cain) writes: > Are there any useful features missing in the more popular editors? > Any opinions on a good user interface? The followin things come to my mind. 1. Column based editing. 2. Try not to force the user to give counts for everything. This is a real problem wih vi (like I wanna delete next some words, so I have to count the number of words or think up a complicated Reg.Expr. Deletion of lines poses the same problem). 3. Can you make i possible to hide lines such that I can view the entire file on one screen and then selectively un-hide lines? Believe me, this will make your editor one of the most popular editors. >Jim Cain Anil Joshi -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
bgg@pta.oz.au (Ben Golding) (01/18/91)
In article <1991Jan16.230527.3200@cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >2. Try not to force the user to give counts for everything. This is a >real problem wih vi (like I wanna delete next some words, so I have to >count the number of words or think up a complicated Reg.Expr. Deletion >of lines poses the same problem). I disagree entirely. Vi has exactly this capability by using the various positioning commands, for example: d) delete to end of sentence d} delete to end of paragraph d$ delete to end of line d% delete to matching parenthesis dfx delete up to and including first character x dtx delete up to first character x By using these commands which work on natural textual objects, I find I rarely need to resort counting words; when I do, I tend to delete one object and then use "." to delete as many as I want rather than counting. The only gripe I have is that the definitions of what constitutes a paragraph or a sentence are hard coded in. However, the defaults are sensible and rarely give unexpected results. Ben.
jfr@locus.com (Jon Rosen) (01/19/91)
In article <3879@pta.oz.au> bgg@pta.oz.au (Ben Golding) writes: >In article <1991Jan16.230527.3200@cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >>2. Try not to force the user to give counts for everything. This is a >>real problem wih vi (like I wanna delete next some words, so I have to >>count the number of words or think up a complicated Reg.Expr. Deletion >>of lines poses the same problem). > >I disagree entirely. Vi has exactly this capability by using the >various positioning commands, for example: > > d) delete to end of sentence > d} delete to end of paragraph > d$ delete to end of line > d% delete to matching parenthesis > dfx delete up to and including first character x > dtx delete up to first character x > As a novice vi user (and a very experienced Xedit/Kedit/Ispf user on both mainframes and PCs), this is an example of what I consider vi's biggest defects: the lack of intuitive command names... To indulge in a bit of "If I were the king of the forest", I would probably have chosen the following initials: > ds delete to end of sentence > dp delete to end of paragraph > de delete to end of line > d) delete to matching parenthesis > dix delete up to and including first character x > dfx delete up to first character x In general, this is the most annoying aspect of vi (and of Unix as well IMHO)... The editor itself is not bad although I object to the modal operation (the constant switching between command mode and text entry mode)... This is handled in most PC editors much better... Of course, it does preclude the use of letters as commands, requiring instead that you start all commands with some kind of function/ctl/command/alt key or special character (like a :)... vi does some of that as well so it is not that big a deal... More importantly it allows you to just type stuff into your document or program without worrying whether you are in the "right mode"... Anyway, enough said... I started out hating vi, now I tolerate it and I am finding out about its interesting quirks... It is certainly very powerful... As always in computing (whether it is editors, operating systems or languages), what you know tends to be what you like... Changing is a painful process (sometimes) but once you get used to the change, it is not as bad as you thought it would be.... Jon Rosen
joshi@cs.uiuc.edu (Anil Joshi) (01/19/91)
bgg@pta.oz.au (Ben Golding) writes: .................................... > d$ delete to end of line > d% delete to matching parenthesis .................................... >By using these commands which work on natural textual objects, I find I >rarely need to resort counting words; when I do, I tend to delete one >object and then use "." to delete as many as I want rather than counting. This is the very thing that bugs me. You have to closely look to see what you are deleting and think (I do that sometimes :-). >The only gripe I have is that the definitions of what constitutes a >paragraph or a sentence are hard coded in. However, the defaults are >sensible and rarely give unexpected results. I don't think the defaults are good at all in vi. I have agree though that emacs defaults are worse. I tried using fmt to do formatting of cursor to end of paragraph. It formatted the whole document. > Ben. Anil -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
funkstr@ucscb.UCSC.EDU (Larry Hastings) (01/19/91)
+-In article <1991Jan19.035637.10236@cs.uiuc.edu>, | joshi@cs.uiuc.edu (Anil Joshi) wrote: | | I tried using fmt to do formatting of | cursor to end of paragraph. It formatted the whole document. | +---------- Well, I'm not sure how you called "fmt", but it works great for me... as I have the following line in my .exrc: map F mz{!}fmt -79^M'z (Note that the ^M is actually a control-m, entered in vi by control-v followed by control-m. You'll have to fix that by hand on your end.) This moves the cursor to the beginning of the current paragraph, and causes vi to call "fmt -79" on the following paragraph. This macro also makes a futile attempt to save and restore the cursor position (which just about never works). It's mapped to "F", which is normally used to search backwards on the line for a character, but I never use it (if I need that I use T anyway). Makes my life much better... Just make sure that the two paragraphs are separated by whitespace lines, and it'll work great. -- larry hastings, the galactic funkster, funkstr@ucscb.ucsc.edu I don't speak for Knowledge Dynamics or UC Santa Cruz, nor do they speak for me
gast@maui.cs.ucla.edu (David Gast) (01/20/91)
In article <21335@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes: >In article <3879@pta.oz.au> bgg@pta.oz.au (Ben Golding) writes: >>I disagree entirely. Vi has exactly this capability by using the >>various positioning commands, for example: >> d) delete to end of sentence >> d} delete to end of paragraph >> d$ delete to end of line >> d% delete to matching parenthesis >> dfx delete up to and including first character x >> dtx delete up to first character x >As a novice vi user ... this is an example of what I consider vi's >biggest defects: the lack of intuitive command names... >To indulge in a bit of "If I were the king of the forest", I would >probably have chosen the following initials: >> ds delete to end of sentence >> dp delete to end of paragraph >> de delete to end of line >> d) delete to matching parenthesis >> dix delete up to and including first character x >> dfx delete up to first character x The trouble with your suggestion is that you have missed the concept of <action><object>. Thus, ) represents end of sentence, ( represents beginning of sentence, } is end of paragraph. Unless you want s to take you to the end of the sentence, and p to take you to the end of the paragraph, you do not want to use the initials you suggested. (You might also want to get rid of the <action><object> model, but that would be a major calamity). Given your choices: 1. How do you go to the delete to the beginning of something? Or is that unimportant to you? 2. More importantly, if p means end of paragraph, what would you use "put after" and "put before"? 3. If e means end of line, how would indicate the end of word? 4. $ to mean end of line is also present in a number of other commands like grep. Would you suggest that grep change as well? After you have learned how to use vi, you will understand that it is laid out pretty well. I have my gripes as well, and I am particularly frustrated by too dangerous to map that, but it really does work well after you learn all of the objects. And it works fine until you learn all the objects. David Gast
zaphod@madnix.UUCP (Ron Bean) (01/24/91)
In Article <1991Jan20.023645.12341@cs.ucla.edu>, gast@maui.cs.ucla.edu (David Gast) writes: >The trouble with your suggestion is that you have missed the concept of ><action><object>. Thus, ) represents end of sentence, ( represents >beginning of sentence, } is end of paragraph. [...] >After you have learned how to use vi, you will understand that it is laid >out pretty well. I would guess that most editors seem that way after you've used them long enough. But why should this revelation be reserved until after you've crawled up the learning curve? It might really help people who are still at the bottom. Perhaps an explanation of this should be added to the vi reference sheet that is posted to the net periodically by maart@cs.vu.nl, since it's not in the FM [that is, the vi(1) man page, which is probably what most people turn to when they're told to RTFM]. >...And it works fine until you learn all the objects. Well, for some people it does. Much of the traffic in this newsgroup comes from people whose experiences with vi didn't work so well. ================== zaphod@madnix.UUCP (Ron Bean) {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!zaphod