response 16 of 80:

Apr 25 02:14 UTC 2007

 You're not getting the meaning I intended -- perhaps I was unclear.
 What I meant was that (presumably because of their flow control functions)
 emacs doesn't by default bind anything to ^S or ^Q.  But some sites choose
 to override the defaults, especially if they're mostly editing in an 
 environment where serial flow control is not a big issue for users.
 That can, of course, create problems when people are logging in remotely
 over some types of connections.  None of which is RMS's responsibility..

response 18 of 80:

Apr 25 16:50 UTC 2007

 I stand corrected, then.  And yeah, that's a pretty darn stupid thing to do.

response 20 of 80:

Apr 26 18:31 UTC 2007

All of that is vim. (Strict vi doesn't allow arrow keys at all, but most
variants have added that.)

response 22 of 80:

Apr 27 17:53 UTC 2007

Re #20: "Strict" vi has supported arrow keys since the 1980s when 
properly specified in the termcap.  Given the terminals and slow 
connection speeds of those times, they often didn't work very well.

Re #21: In vi, doesn't the "autoindent" option simply consist of 
indenting each line the same amount as the previous line, with special 
keys (^T, ^D) to increase and decrease the indentation level?  Right - 
not smart.

Smart indenting requires teaching the editor something about the grammar 
of the language being edited.  Thanks to emacs' extensibility via its 
embedded lisp interpreter, you can do that in emacs. It has a great C 
mode   that indents and exdents automatically - e.g. "{" increases the 
indentation level, "}" decreases it.  Recent versions also do color 
syntax highlighting.  I find these things very helpful when editing 
source code; they're a major reason I prefer emacs for editing 
structured text.  Standard emacs distributions now come standard with 
editing modes for a number of languages - Perl, PHP, Pythong, Ruby, etc.

response 24 of 80:

Apr 28 17:08 UTC 2007

Right - early arrow key support allowed it only in command mode, not 
insert mode.

You're right, vim has similar features, and is extensible via a scripting 
language.  I haven't looked at it closely enough to know how it compares 
in power to emacs lisp.

One nice feature of emacs is vi-mode, a pretty accurate and complete vi 
emulation.  You can switch in and out of it with a single keystroke (^Z in 
my setup), and it gives me access to a few operations that are easier in 
vi than emacs (e.g. repeated search-and-replace, or filtering text through 
an external command) without leaving emacs.  Best of both worlds.

response 26 of 80:

Apr 30 20:00 UTC 2007

#24: "early arrow key support allowed it only in command mode, not insert
mode." 

There's a reason I kept saying "strict vi" above (beyond that vim offers a "vi
compatibility" mode; I suspect arrow keys would work even in that). Vi is a
modal editor; there's a mode in which you enter commands, a mode in which you
insert text, and (in strict vi, I think, but not in vim) a mode that allows
some commands but allows you to insert text. Movement is a command, so of
*course* you can't use the arrow keys to move in insert mode. In open mode
perhaps (I haven't used a version that supported open mode in years, though I
miss it), and definitely in command mode, but allowing a certain class of
commands in insert mode can only confuse users.

response 28 of 80:

Jun 15 22:39 UTC 2007

I'm surprised that WordPerfect 5.1 for DOS cannot produce RTF.

At any rate, both vi and emacs have macro capabilities.  Given that you are
a frequent pico user, I'd suggest emacs as being philosophically closer.

response 30 of 80:

Jun 16 15:18 UTC 2007

RTF no, but TeX yes.

response 32 of 80:

Jun 21 14:29 UTC 2007

My Lithuanian friend put together a minimal tex package and also recommends
the above pdf guide  (2MB), which is also available in dvi form (1MB) and as
'src.tar.gz' (200K) - tex?  Or 3MB ps.  He included tex, tex.fmt, dvips, and
some fonts.  I suggested also dvilj in case I want to print - not much use
for ps.  He made another pdftex package, and an xdvi package for viewing in
X, but suggested a couple of svgalib viewers (tmview).  I am looking at
dviware programs - dvilj4 dvipng dvivga (?).   dvilj4 is supposed to also work
with LJIIIP and maybe also plain LJ (which should include deskjets that
support PCL3?).  dvivga is a previewer that supports VGA and seems to need
PK fonts (which he included).  THere is also an
'epson' (printer driver?), a laserjet (that needs PXL fonts), tmview (works
in framebuffer, svgalib, or X),xdvi (this is a large one), dvidjc for deskjet
500 series, catdvi to convert to plain text, dvipdf....

response 34 of 80:

Jun 26 21:45 UTC 2007

I use "cat > FILENAME" because I never make mistakes.

response 36 of 80:

Jun 27 05:14 UTC 2007

Regarding #34; Under Plan 9, the window system is responsible for most of
the traditional character handling and so on usually done by the line
discipline in the TTY subsystem in Unix.  Plan 9 has no TTY interface:
you're either on the console, in which case you have a bitmap display,
keyboard, and mouse, or you're on a UART, where you have something else.  In
either case, it is expected that some other piece of code will handle
dealing with your input and any special treatment that it needs.  e.g.,
translating Del into an interrupt note sent to the currently running process
group (similar to ^C generating a SIGINT that is sent to the current session
leading process group for that TTY under Unix).  There is no notion of
POSIX-style sessions, job control, or any of the rest of it (and believe me;
the kernel internals for the TTY subsystem under Unix are incredibly
complex, arguably more so than any other subsystem).

However, one neat feature of this is that the window system ends up getting
the opportunity to handle a lot more than just generating the native
equivalent of signals, and in the current implementation, input to processes
running in a window is entirely managed by the window system.  All text in
such a window is editable, and for each window there is a notion of an
`output point' at which text is inserted by the window system, presumably
after being output by whatever programs are running in that window.  Text
entered by the user (or by pasting) after the output point is sent as input
to the process currently running in the window when a newline is
encountered.  Text entered or modified *before* the output point is not sent
anywhere, but remains visible in the window.  Cutting, pasting, command line
editing, etc, is thus all handled by the window system transparently to
whatever is running in the window.

Furthermore, typing Esc in the window puts that window into `hold mode,' in
which no text will be sent to any processes running in the window until Esc
is typed again (returning the window to normal mode).  Hence, `cat > file'
followed by Esc and whatever text you want, editted as you like, followed by
Esc again and then ^D makes a very effective text editor for short files
under Plan 9 (assuming you're using the window system).

And it's even cooler than that.  The window system (and indeed, the entire
graphics subsystem) exports a filesystem interface using the standard Plan 9
file protocol (9P).  This can be imported and mounted over a network,
providing network transparency for the window system, but without the need
for a special protocol ala X11.  In fact, each window has a little
filesystem that it exports, so you can import only a single window, or the
entire thing, or any combination anywhere else on the network.  You get all
the authentication, encryption, etc of the underlying network protocol built
into the window system for free.

http://plan9.bell-labs.com/plan9dist/

response 38 of 80:

Jun 27 13:03 UTC 2007

Heh.