The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Unix taste (Re:  terminal - just for fun)
Date: Sat,  2 Aug 2014 12:47:48 -0400 (EDT)	[thread overview]
Message-ID: <20140802164748.6D3BD18C0B2@mercury.lcs.mit.edu> (raw)

    > From: Doug McIlroy <doug at cs.dartmouth.edu>

    > A symptom of why I have always detested emacs and vi. With ^D, ^C, and
    > ^\, Unix has more than enough mystery chords to learn. Emacs and vi
    > raised that number to a high power--an interface at least as arcane and
    > disorganized as the DD card in OS 360--baroque efflorescences totally
    > out of harmony with the spirit of Unix.

I will agree that the Emacs user interface is not simple - although there are
levels, and one can start out e.g. without knowing the commands to move by
word, and get by with the commands to move by character - and of course
nowadays, the arrows, etc, keys on keyboards are bound to the appropriate
commands, for novices.

But it's a subtle debate; yes, it's not for everyone, but i) as an
application, not everyone has to use it (unlike a kernel), and ii) as the
editor is the principal tool which most programmers spend hours a day using,
it is not insensible to have a more complex but powerful tool which takes a
while to fully master. (Like playing a violin...)

Back on V6, we started using one written by someone at BBN (memory fails me as
to exactly who), and it improved my productivity immensely (with 'WYSIWG'
editing - i.e. you always see the current contents of the buffer, multiple
buffers, multiple windows, etc).

I had been using 'ed' (although I had access to Emacs on the ITS machines),
and although I was (and remain) fairly skilled at 'ed', the factors I just
listed are immense, IMO. Being able to see the code as I work on it really,
really helps (for me, at least).

But a lot of that is orthogonal to Emacs command interface; you can have
'WYSIWYG', multiple buffers, etc with a wholly different command interface,
and get much the same benefit. (E.g.  uSoft Word has most of those; real
WYSIWG [i.e. with multiple fonts], multiple files open at once, etc, etc.)

Does something like Word produce the same reaction for you? I don't use it
much, but my wife does (she's an engineer, and uses it to write papers), and
its complexity drives her crazy sometimes.


As for the size of Emacs, everyone needs to distinguish between GNU Emacs, and
Emacs-like editors. Just as GCC is a beast, but other C compilers are and were
much smaller, there are small Emacses out there.

Back on V6 (on a PDP-11, of course), it had to fit into 64KB; the one we used
didn't have the kind of extensibility common in them now, but it was still
a much better tool for me than 'ed'.

As I recall the performance was pretty good (albeit it chewed CPU time, since
it woke up on every character - Multics had an Emacs which tried to avoid
that, and only woke up on non-printing characters, and used system echoing for
the others). I don't know for sure (I don't have the source to hand at the
moment - that's one of the things I hope to recover if/when I can read those
backup tapes), but I suspect that it 'windowed' files (i.e. didn't read the
whole thing in); with the 65KB address space of the 11, that would be almost
inevitable.

I have been using another Emacs, Epsilon, for almost 30 years now; it started
as basically Emacs for MS-DOS, and later became Emacs for Windows, and it is
small and very fast. The Windows executable is about 250KB, and it loads a
'state file' (mostly interpreted 'compiled' intermediate code, written in
something that's 99.2% 'C', in which a lot of the editor is actually written)
of about 200K (for mine, which has a lot of extensions I wrote). It starts
fast, and runs blindingly fast. It also uses the file 'windowing' techniques,
and can handle much larger files than its address space (this dates back to
its MS-DOS days).

So Emacs != big (at least, not necessarily).


    > A modern-day analog of the undisciplined exuberance of emacs and vi:
    > for a good time on linux try

I basically agree with you on this; I want to go away and collect my thoughts
before responding, though.

	Noel



             reply	other threads:[~2014-08-02 16:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-02 16:47 Noel Chiappa [this message]
2014-08-02 18:51 ` Ian King
  -- strict thread matches above, loose matches on Subject: below --
2014-08-06 22:24 Norman Wilson
2014-08-06 22:19 Norman Wilson
2014-08-04 20:21 Norman Wilson
2014-08-04 22:24 ` A. P. Garcia
2014-08-05  2:41   ` Andy Kosela
2014-08-05  3:32     ` Warner Losh
2014-08-04  2:54 Norman Wilson
2014-08-04  3:11 ` Lyndon Nerenberg
2014-08-04  7:04   ` Dave Horsfall
2014-08-04  9:12     ` Steve Nickolas
2014-08-03 16:48 Noel Chiappa
2014-08-03 17:09 ` John Cowan
2014-08-03 11:49 Noel Chiappa
2014-08-03 12:14 ` Steve Nickolas
2014-08-03 16:26 ` John Cowan
2014-08-04 13:59 ` Tim Bradshaw
2014-08-04 14:53   ` A. P. Garcia
2014-08-03  0:48 Noel Chiappa
2014-08-03  8:00 ` A. P. Garcia
2014-08-02 21:18 Noel Chiappa
2014-08-02 23:44 ` A. P. Garcia
2014-08-02 14:28 Doug McIlroy
2014-08-02 14:00 ` Larry McVoy
2014-08-02 15:51   ` Steve Nickolas
2014-08-02 16:07     ` John Cowan
2014-08-02 17:28     ` Benjamin Huntsman
2014-08-02 19:50     ` Dave Horsfall
2014-08-02 16:04 ` Diomidis Spinellis
2014-08-02 16:03   ` Larry McVoy
2014-08-02 19:36 ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140802164748.6D3BD18C0B2@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).