MROBINSON@wash-vax.bbn.com (08/14/89)
isearch-regexp and its cousins work great in the GNU Emacs I've used on Sun
workstations. My only complaint about Emacs is that its too slow, but its not
as slow as some editors that do a lot less. I have two gripes with vi: one,
its not easy to extend like Emacs, and two, its too difficult to find out what
a command does; a help command of some sort would be very nice.
When I programmed in Prolog for a couple years, I used GNU Emacs nearly all the
time, and vi only once in a while, when I had something I knew exactly how to
do real fast in vi, that I would have to think about in Emacs. Since I've
changed jobs, I've been programming in C and using vi almost exclusively. The
feature of vi that helps me more than anything for C programming is finding the
matching (){}'s with by typing % in command mode. If this was as easy in
Emacs, I might still be using Emacs, even though it is slower. Of course, GNU
Emacs has a very good vi emulation mode, in case I would get homesick...:)
Most of you will probably think I'm sick, but one of the things I like about
vi (actually, ex) is the line-specification syntax. Like,
. current line
$ last line in the file
/<pattern>/ first line forward containing the given pattern
?<pattern>? first line backward containing the given pattern
<line>+<line> (<line>+<line>)th line in the file
<line>-<line> obvious from above
And ranges of lines are <line>,<line> or just <line>. These really help one
move around and specify what should change. Anybody else like these? The
reason I ask is that I've given some thought to the idea of having this kind of
position specification model at the *character* level, rather than the line
level as in vi, and building a (freely redistributable, of course) editor
around this idea. The position specification model is complete, and I have a
fairly good idea about what I want the editor to do, and how I want to
structure the code, and all, but is it worth the doing? Is DME really the
be-all and end-all of editors, or would someone actually be interested in this?
I'm likely to do it one way or another, the question is when.
Also, I've never written an editor before, and I was wondering if anyone has
opinions about how an editor should handle memory, especially on the Amiga.
Should the editor work on blocks of text, or just shove everything into one
big buffer? And what special interface concerns have people noticed with
editors? Keymaps, raw keyboard input, color of the text, color of the cursor,
clicking on text, multi-buffer windows versus multi-windowed editor, online
help, mapping keys to commands, macros?
Thanks for any input,
Maxshadow@pawl.rpi.edu (Deven T. Corzine) (08/15/89)
[this doesn't belong here!]
On 14 Aug 89 14:54:14 GMT, MROBINSON@wash-vax.bbn.com said:
Robinson> Since I've changed jobs, I've been programming in C and
Robinson> using vi almost exclusively. The feature of vi that helps
Robinson> me more than anything for C programming is finding the
Robinson> matching (){}'s with by typing % in command mode. If this
Robinson> was as easy in Emacs, I might still be using Emacs, even
Robinson> though it is slower. Of course, GNU Emacs has a very good
Robinson> vi emulation mode, in case I would get homesick...:)
I find GNU Emacs to be *much* more useful than vi for editing C code!
It matches open parens for (), {} and [] pairs, and if you type a key
while the cursor has jumped back to show the opening match, it will
jump the cursor back to the point and continue entering data. Vi, on
the other hand, makes you wait. [if it's not matching for you, try
M-Esc [Esc-Esc] to evaluate (setq blink-matching-paren t), or put it
in your .emacs...]
Better yet, I have GNU Emacs configured to indent C code in the style
I prefer. It is very convenient; press tab, and it indents the proper
amount, context-sensitive. (C-mode understands indententation styles
pretty well.) [to customize C indentation, study the C-mode docs
carefully. M-x describe-mode [or C-h m] M-x c-mode will enter the C
major mode... if it doesn't automatically when you edit a .c file.]
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (08/15/89)
In article <21646@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >reason I ask is that I've given some thought to the idea of having this kind of >position specification model at the *character* level, rather than the line >level as in vi, and building a (freely redistributable, of course) editor >around this idea. The position specification model is complete, and I have a >fairly good idea about what I want the editor to do, and how I want to >structure the code, and all, but is it worth the doing? Is DME really the >be-all and end-all of editors, or would someone actually be interested in this? I'm interested, for one. I have been toying with the idea of writing an editor, for a variety of reasons. I use DME exclusively ( thanx Matt! ) but there are some things I dislike about it ( sorry Matt! :-) The big things I am in the process of adding to it, since I don't have the time to write an editor. In case anyone cares, the two things I'm adding are multiple (semi-infinite level along the lines of the way Emacs does it, within the bounds of the way DME handles input and line changes) undoing and regular expression searching/replacing. I've got the undo almost working, the regexp stuff will follow quickly ( can you say _trivial_ boys and girls? Gooood ... of course, undo was supposed to be quick, since I've written in before in another editor on Unix :-) >Also, I've never written an editor before, and I was wondering if anyone has >opinions about how an editor should handle memory, especially on the Amiga. >Should the editor work on blocks of text, or just shove everything into one >big buffer? Ok, there are two basic models that I can see: - an editor buffer (file) as a big "string" of text - " " " " " a collection of lines of text I like the former way ( the way Emacs does it, the way the editor I worked on did it ) but the latter is easier on a micro ( the way vi and DME do it ). Of course, if you keep everything modular, it doesn't matter which way you do it ( also makes some features _very_ easy to implement ) I have lots of ideas on this, if anyone is interested ... >And what special interface concerns have people noticed with >editors? Keymaps, raw keyboard input, color of the text, color of the cursor, >clicking on text, multi-buffer windows versus multi-windowed editor, online >help, mapping keys to commands, macros? I like the DME interface and I like the Emacs interface. I think that the best combo would allow you to have multiple windows, but would behave like Emacs in that any buffer could be displayed in any window interchangably. Maximum generality is important in this case ... never say "no one would use that feature" Do not do raw keyboard input, use the keymaps. Again, generality. Things like colour should be up to the user. On-line help is very important, look at Emacs for a good implementation ... Of course, everything should be user customizable, ala Emacs and DME. This is very important. But, there should be reasonable defaults UNLIKE Emacs (that's one thing I dislike about Emacs - not only is user customization allowed, it is almost required! ) >Thanks for any input, > Max Hey, no problem! -- = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} // = = now appearing at the Computer Graphics Lab, U of Waterloo! \X/ = = "There's nothing the matter with BR that a shot gun blast wouldn't fix" cge = = "It's not my fault, fatboy!" - Felder, pilot of TL Student Driver On Board =