[Gllug] ed vs emacs/vi, was: ed vs emacs, was: OpenMoko Neo Freerunner

Nix nix at esperi.org.uk
Sun May 17 14:18:56 UTC 2009


On 15 May 2009, general spake thusly:
> Nix wrote:
>> If those chunks are entirely random selections of text, you may be
>> right.  But in the more common case when you're trying to select, say, a
>> paragraph or an expression or fourteen words or something like that,
>
> Pish, I quite commonly need to pull chunks out of the middle of a line
> and other seemingly random places. What I pretty much _never_need to do
> is select exactly 14 words, and if I do need the text between column 27
> and 65 on the line 13 lines above the cursor it's a lot faster for me to
> use the mouse than the keyboard if only because it spares me the
> counting!

Your use of text editors is weird verging on unique then, or you tend to
edit very unstructured text (as in, not even structured as much as
English, in which 'yank the next sentence or two' is much more common
than 'yank this hunk of text starting in the middle of the word 'more'
and ending on the fifth letter of the word 'ending').

Of course you *can* select hunks of text with the mouse but I do it very
rarely. Context-sensitive cursor motion (for my major use case 'go to
this function', 'go to the next bracket', 'go to the next block in') is
much more useful.

(Obviously, since counting to more than about three requires conscious
effort, one usually just holds the appropriate move-by-larger-blocks key
down until one gets close: but on a slow link the *ability* to move
'fifteen lines on' or something like that is very useful indeed.)

> Don't get me wrong, I do use the keyboard to do most of my
> selecting but there are times (in practice many times during an average
> day) where the mouse is the correct tool for the job.

I can't think of many. I use it to set up X selections and that's about
all, and I wish there was a way to keyboardize that.

> It seems we are talking at cross purposes then. I was wondering why
> people would choose to use an terminal based editor over a GUI based one.

Several reasons spring to mind, many relating to using Emacs on remote
systems and displaying it on a local one.
 - the local system can't handle X (ancient hardware only but I still
   have to use such hardware sometimes)
 - the link between the remote and local systems can't handle X traffic
   volumes because the latency is too high or the bandwidth is too low.
   Narrowband modems suffer from both these problems in spades. This is
   the primary reason I use XEmacs in a terminal.
 - the remote machine can't handle X (no X library, in maintenance mode
   so things that high-end aren't available, simply has not enough memory:
   the latter is mostly relevant to vi as emacs uses more memory than the
   X libraries: ancient hardware only)

Many of these also apply when the editor is running locally,
particularly the maintenance mode thing. X and especially modern X
desktops rely on a *lot* of infrastructure and tend to go wrong if it's
not there: if /usr isn't mounted or you want to keep the number of
things running right down, TTYs are the only way.

> It seems that the big two old school terminal editors also exist in GUI
> form these days,

gvim is a product of the late 90s, X-capable Emacs/XEmacs a product of
the early 90s.

> Indeed I get the impression that most people here use the GUI versions
> whenever they're practical so people _aren't_ generally choosing

Yes.

> terminal based editors over GUI ones except for practical purposes. That
> makes sense to me now (but please feel free to correct me if any of you
> do _actually_ prefer the terminal version!).

As David has pointed out, the 'practical purposes' are *not* generally
that the menus are available: indeed I've turned them off in my .emacs;
it is rather that you get tiny fonts and colours and extra keys and
multiple windows on the same editor (using X terminology: these are what
emacs calls 'frames'; what emacs calls 'windows' everyone else knows as
'panes') and the window manager knows that this is an emacs rather than
an xterm and so on.

> The other point I was trying to make is that, for the day to day stuff
> most people need an editor for there's nothing wrong with nano

Does it even have rebindable keys? Personally I find isearch and a
keybinding to scroll the window contents without moving the cursor to be
near-essentials (though I know other people may differ here).

> shift-select wouldn't hurt). Before this year the last time I used Unix
> with any regularity was on HP-UX workstations in 1994 and I remember
> pico as being far easier than anything else for my modest needs.

pico's frankly demented function-key-based keybinding confuses the hell
out of me. I keep on quitting when I mean to save and vice versa.

> As desktop linux grows and more people switch from shared web hosting to
> cheap VPS hosting the predominant uses of a terminal based editor become
> fire fighting GUI boot problems and editing the odd config file via SSH.

Basically, yes. (With the TRAMP Emacs extension, you don't need to kick
up a remote editor just to edit a remote file, so that use case vanishes
too.)

> seeing as how everyone here seem to have nothing bad to say about them
> and consensus that they are veritable force magnifiers. Having duly

I have something bad to say about Emacs and vi: they are not the right
choice if you don't spend a lot of time editing text, because they *do*
take time to learn.

They are not so much user-friendly as expert-friendly, and they're
expert-friendly to such a degree that I sometimes wonder if anyone has
married their Emacs. They are somewhat newbie-confusing (although Emacs
at least tries to avoid being newbie-hostile, it's different enough from
the norm that this may be a lost cause).

> Emacs clearly kicks Vim's ass! ;D

I started using Emacs in 1992 and flipped to XEmacs in 1995. I haven't
done major text editing work in *anything* else since, and other editors
feel clunky and painful in comparison. So I have to agree ;)
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list