Complete.Org: Mailing Lists: Archives: discussion: November 2000:
[aclug-L] Re: [announce] ACLUG Meeting: Monday, Nov 20: Emacs & Vi
Home

[aclug-L] Re: [announce] ACLUG Meeting: Monday, Nov 20: Emacs & Vi

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: discussion@xxxxxxxxx
Subject: [aclug-L] Re: [announce] ACLUG Meeting: Monday, Nov 20: Emacs & Vi
From: Tom Hull <thull@xxxxxxxxxxx>
Date: Mon, 20 Nov 2000 13:46:02 -0600
Reply-to: discussion@xxxxxxxxx

Info wrote:

> Aclug Meeting: Monday, Nov 20, 2000 - Emacs & Vi
> ------------------------------------------------
> 
> Tonight's meeting will cover Emacs and Vi, the most widely installed text
> editors in the Unix world.  We will overview the navigation and command 
> syntax,
> then demonstrate the actual use of both editors.
> 
> Tom Wallis will tonight's speaker.

Aah, a good old fashioned religious war topic. Finseth (below) defines religion
as "a technical term that refers to the usually irrational and extreme 
preference
of one program, style, or method to another." I'm on the emacs side, but I'd 
like
to think that's an eminently rational decision. I can, for instance, point back
to my formative years when with emacs I could keep multiple windows into 
multiple
buffers, including all my program files, and run make under the editor, then 
have
the editor step through the compiler error messages and track down the files and
offending lines; vi simply could not do anything like that.

OTOH, I recall vi users of that vintage complaining about emacs' start-up time
(much less of an issue now), and the pinky pain of having to stretch so often
for the control and ESC keys.

One good resource on emacs is Craig Finseth's book, "The Craft of Text Editing:
Emacs for the Modern World". This was published by Springer in 1991. It is out 
of
print, but available on the web:

  http://www.finseth.com/~fin/craft/

The main things in this book are historical survey of emacs editors and a lot
of technical detail on how to implement text editors.

FWIW, there are several classic design arguments between emacs and vi:

 1) In vi, you start out in a command mode, and have to enter commands to get
    into insert mode, then ESC to get out. This modal behavior means that keys
    have different meanings at different times. In emacs, the text keys always
    insert text; the commands are moved to extended keycodes (control, meta,
    control-x).

 2) In emacs, the point (cursor) is always logically between the character that
    the screen cursor rests on and the preceding character, so that insertions
    always happen in the cursor cell. Vi seems to be confused about where the
    cursor is and what it means -- there are separate commands for inserting
    before the cursor and after the cursor.

 3) Vi is line-oriented; i.e., almost all commands only work within a line.
    In emacs, line separators are just text, so you don't need special commands
    to delete, insert, or traverse them. (This also makes it easier to view
    binary data in emacs, albeit not easy enough.)

The effect of these two points is to make emacs easier and more intuitive to
learn (e.g., you just start typing; neophytes can generally get by with the
cursor and backspace/delete keys for editing, then learn more commands as
needed). OTOH, emacs tends to demand more typing agility, since the control
and meta keys are harder for most people to use.

However, one rarely talks about emacs nowadays as being modeless, because
nowadays emacs has modes up the yazoo: major modes and minor modes, which
automagically switch in according to filename extensions to bind special
behaviors to ordinary text and commands to help you edit source files (c,
c++, lisp, etc.), HTML, SGML, mail, what have you.

> Aclug Meeting: Monday Dec 18 - Intro to Programming
> ---------------------------------------------------
> 
> The topic for this meeting is tentatively scheduled to cover an introduction 
> to
> programming.

I can do this, if you'd like. I suggest that it should just be C programming.
I can give some rationale for "why C?" and where C is or is not a good choice,
but wouldn't want to go down any other language ratholes (e.g., java).

-- 
/*
 *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
 */

-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi


[Prev in Thread] Current Thread [Next in Thread]