Sept 11th Meeting, What happened?

[Christopher Browne]

On 9/12/07, Michael Kennedy <michael-FlpYSvOe4ac6W4JZGn+SJw at public.gmane.org> wrote:
> It branched out in a few directions, but the main thrust of the
> argument is that modern editors change the way we view the facilities
> at our fingertips, and the nature of each editor lends itself to
> different followers.  There was a heated camp of Emacs which I
> interpreted as 'I can call up anything I could possibly want in Emacs,
> so it is the best compromise between shell and editor.', then there
> was sparse 'vi' contingent which basically conceded that the only
> positive features of 'vi' came with the introduction of 'vim' and that
> the requirement for termcap basically amde it a blight on the history
> of UNIX.  And finally there was the 'silverback' contingent which
> debated the value of either of the preceding options when it was
> perfectly clear that all roads forked from 'ed', and by extention,
> 'qed'.  Of course this is my interpretation of the session, and is
> entirely up for debate as I'm sure others perceived it differently.

The "forked from ed" matter is more interesting than it looks...

The argument that fell out of that wasn't so much about what was
specifically better, but rather pointing out that the move from line
editors <http://en.wikipedia.org/wiki/Line_editor> to "visual" editors
led to a loss of programmer understanding.

In the "good old days" of ed, qed, and TECO, the very action of
editing a program required understanding at least a bit about what the
editor was doing to manipulate the data, with the result that going on
to automate the editor to do what you wanted was entirely natural.

In the "bad old days," shortly after that, visual editors allowed you
to edit things via what a curmudgeon might term "point and drool;" you
move arrow keys to get the cursor to where you think it ought to be,
and then do simple manipulations from there, perhaps as little as:
 - I can add a character in here...
 - I can delete a character here...
 - I can delete a line...

The need to understand a bit of what went on under the covers
disappeared, and this has allowed programmers to have a much shallower
understanding of what their tools are capable of.

Sasha Chua pointed out that Emacs allows those who are interested to
dip in at the Elisp level, and pretty deeply do any operation they
wish to.  The same is, of course, not true for vi; it was never
designed with the intent to expose all of its facilities to scripts as
was the case with Emacs.

That doesn't contradict the "curmudgeonly" opinion - Emacs can expose
such things, but only if you take interest.

There are then two further criticisms that become relevant:
- Emacs is decidedly NOT a "Unix style" tool (a fact with which I, as
a fan of Emacs, agree); it tries to be an overarching environment, as
opposed to encouraging "shelling out" to run Unix commands to do work
- vi *without* ex mode has the same issue, except without any "overarching" ;-)

For a qed fan, there's another contrast to be had, namely that it,
like Emacs, and unlike vi, supports multiple text buffers...
-- 
http://linuxfinances.info/info/linuxdistributions.html
"...  memory leaks  are  quite acceptable  in  many applications  ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists