Editing As Opposed To Typing

A lot of people use Emacs because it is good for typing. Further, they use Lisp programming to enhance its editing capabilities, spending what seems like days, perfecting never to be repeated editing support. I can only repeatedly suggest to these people that they should really learn vi. I have converted 10s of people from emacs to vi by showing them how to really use it for EditingAsOpposedToTyping. This may just be a hopeless holy war, but I have converted some pretty avid emacs fans, and I am convinced there are more things to be gained from more people using vi then more people using emacs... -- GreggWonderly

Hmmn - I've been using both Emacs and vi on a daily basis for more than a decade. I prefer Emacs for mail and news and certain kinds of editing/composition. I prefer vi when I'm doing lots of regular expression search and replace over limited regions of the code instead of the whole buffer (doing a "narrow-region" is a pain). But I use Emacs when I need to do a case-insensitive search with a case-sensitive replace. I try to keep my Emacs "macros" and customizations to a minimum because I need to stay familiar with the basic command-set and not the ones I rolled-my-own for (I have to go to other peoples' terminals and troubleshoot quite a bit so I need to be able to deal with either vi or emacs as their default editor or command-history mode). --BradAppleton

I'm still not clear on what EditingAsOpposedToTyping really means. Seems like it's defined recursively in GreggWonderly(s) opening paragraph. I see that you're saying that vi is better than emacs for doing such, but I'm still not sure what makes the distinction. Is it simply regular expression search and replace? For the record, I'm a vi person, but I want to find the time to learn emacs at some point.

You kids with your new-fangled bleeding-edge toys! I'm typing this on my good old Smith-Corona! --RonJeffries

Every time I need to edit a file I open a browser, connect to Wiki, edit a random page so that I can get an edit box, copy my text into it, edit it there, copy it, cut, and paste it into my IDE or mail message. I do this because it feels comfortable and the features of real editors confuse me. Also, the increased hits may help Ward bring in venture capital. With venture capital he could launch an advertising campaign to sell Wiki to the masses as a web distributed editor. -- MichaelFeathers

I don't really want to start an emacs vs vi flamefest but having been a religious vi user and now being a religious emacs user I just can't see what would make me revert back to vi. I would be very interested in what features vi has that would make it better for editing as opposed to typing (what ever that means). My mind just boggles. The number of things that I rely on in emacs that vi can't do (or couldn't a few years ago anyway) is phenomenal. However, in the spirit of Wiki, I will try to have an open mind on the issue. --JamesCrawford

I believe there is literally nothing, these days, that VIM ( http://www.vim.org ) can't do that emacs can, except run an embedded lisp engine. OTOH it can run embedded perl and python interpreters and I never liked lisp anyway. Still there are far too many things that the RefactoringBrowser can do that neither vim nor emacs can do, and that they really ought to be able to do. Why is that? --PeterMerel.

It's because there's a difference of kind, not quantity, between a big blob of text and the structured text represented by the Smalltalk method structure, and supported by its browsers, refactoring and otherwise.

You explain to a text-editor person about senders and references and implementors, and they say "oh I can do all that with EMACS". Fact is, they can't, and don't. The Smalltalk language is compact, and that helps, but the environment that comes with it, and with some LISPen, is a whole different animal. Smalltalk and Lisp systems know the language. EMACS and its brethren know the characters. --RonJeffries

Something to note is that for many Lisp environments, Emacs is the browser. I'm thinking specifically of Allegro CommonLisp's environment here, but you can do senders and references and implementors and the like, and for all these Emacs talks to the Lisp and gets the information back from it.

Sadly, vendor specific Lisp modes and to a much lesser extent JDE are the only ways Emacs works quite like this; for the rest, Ron's distinction is correct. -- GrahamHughes

What counts as "vendor specific"? My understanding is that ILISP can do much the same as Allegro's "eli" can. Is that wrong? --GarethMcCaughan

ILISP does it by talking to the Lisp just as eli does, using implementation-specific code for each supported implementation. Emacs doesn't know itself that the thing under the mouse is a symbol, or a class or an instance or whatever, it's still dealing with blobs of text. (Does this make a practical difference? If a tree falls in the forest, etc etc) -DanBarlow

Well, you said "Sadly". It's hard to feel terribly sad about the fact that emacs has to talk to the implementation in vendor-specific ways; after all, with an integrated Smalltalk environment the system is probably talking to itself in vendor-specific ways too :-). (Yeah, I know, that's not entirely fair...) If emacs is able to do a good job that way, I think that's cause for gladness rather than sadness, because it offers some hope that other unenlightened languages might be able to benefit from this sort of clever stuff. --GarethMcCaughan

Note that GnuSmalltalk comes with an Emacs mode which does things exactly as described above for ILISP, i.e. it asks the underlying Smalltalk process to get the senders and implementors and displays the information to the user. Also ObjectiveCaml as an Emacs mode which does such things and also tells you the type of your variables.

Finally, for C and the like, there is ctags. Now people keep on telling me that Smalltalk find senders and find implementors is not the same as ctags, but it sure looks like it. To quote the Vim docs:

  The ":tag" command works very well for C programs.  If you see a call to a
  function and wonder what that function does, position the cursor inside of the
  function name and hit CTRL-].  This will bring you to the function definition.
  An easy way back is with the CTRL-T command.  Also read about the tag stack

below.

So this is just "find implementors" in C, AFAIK. -- StephanHouben

It can do more, but that's what most use it for.

The cool thing is that we've been using ctags with vi since 1978. -- DougMerritt

Emacs vs. Vi(m) - it's really a matter of how you structure your thoughts. Emacs works by performing a complex set of commands on text, and giving you many ways to do them, as well as ways to change the many ways to do them, and ways to write your own. Vi, on the other hand is oriented round a very simple set of editing commands, and another set of other commands that have to do with the environment. The environment commands are more emacslike in nature, so we'll ignore them. The editing commands can be broken down into 3 parts: repetition, verb, and subject. Each verb is a character long, each subject is a character long if at all, and each repetition is an optional integer. 3dw, for example, means: "d", that is delete, the verb. The thing that is being delted, the subject is "w", a word, and how many times this is being executed is the prefix "3". (repetitions are actually arguments, tsk tsk). If you prefer mixing and matching a limited vocabulary (verbs and nouns), use Vi(m). If you prefer complex commands that are either more complex or more specially tailored, and can remember them all, use Emacs.