response 39 of 80:

Jun 27 17:13 UTC 2007

 The bit about putting the window in "hold mode" reminds me of the
 windowing environment in Domain/OS, Apollo's Unix-like (but not
 *sufficiently* Unix-like) OS offering from the mid-to-late 1980s.

 The windows that shells ran in were split into two panes -- the 
 majority of the window, and a one-line input pane at the bottom.
 Input that you typed in the input pane at the bottom wasn't handed
 over to the shell until you hit a carriage return, at which point
 it was handed over to whatever program you were running.  This was
 really nice because at the time unix shells mostly didn't have
 command-line editing, but under this scheme you could do all your
 editing in the input pad in the windowing system and then send it
 to the program.  If you needed to edit multiple lines, the keyboard
 had a "hold" key which would act as you describe "hold" above --
 it would stop the processing of input until you hit "hold" again,
 in the meantime giving you an expanded edit area in the windowing
 system where you could use the cursor keys, mouse pointer, cut and
 paste, etc, to work on editing your text.

 Programs that used character-by-character input modes (e.g. cbreak)
 wouldn't work with this system (the separate edit line would disappear
 into the main window, if I recall properly, while you were running
 such a program) but for things that used a line-by-line input mode
 it was great.

 I still maintain that Domain/OS was *WAY* ahead of its time. 
 In 1987 (wow!  20 years ago!) it had a really nicely-integrated
 windowing system with a very cool facility called "edit pads"
 which were extremely well integrated with special dedicated keys
 on the expanded keyboard, transparent distributed network file system,
 unified object and user registry, full-featured filesystem acls, 
 and other nifty features I'm almost certainly forgetting..

response 41 of 80:

Jun 28 07:56 UTC 2007

 Another feature of Domain/OS that I think should've become more
 widespread was the ability to create variable symlinks -- that is,
 you could create mylink -> //server/usr/local/$platform/bin and
 the $platform part would be interpreted at runtime by the filesystem
 calls, based on the user's environment variables.  This made possible
 some very flexible ways of supporting different platforms and
 alternative environments that could be easily selected by altering
 environment variables.

response 43 of 80:

Jul 9 14:24 UTC 2007

I think DragonFlyBSD aims to do this.

response 45 of 80:

Aug 22 17:11 UTC 2007

Right, Emacs' syntax highlighting and automatic indenting really are
better, which is one big reason why I still favor it for programming.

response 47 of 80:

Aug 22 23:22 UTC 2007

How about auto-indenting?

response 49 of 80:

Aug 22 23:43 UTC 2007

I just put these two lines in my .vimrc, and the autoindenting works
the way I want it when I want it, and not when I don't:

autocmd BufRead *.c set cindent
autocmd BufRead *.y set cindent

I think there may be other indents besides cindent for other languages.

response 51 of 80:

Aug 23 13:30 UTC 2007

Regarding #50; Like I said, it's a matter of personal preference.

response 53 of 80:

Aug 23 15:55 UTC 2007

I am trying to read a text in Cyrillic, iso 8859-5.  I loaded the console
font.  Character 155 (e) displays as a blank.  The other Cyrillic fonts also
display 155 as a blank.  pico vi or 'less -r'.  Is there some way around this
other than using X fonts?  Opera displays the text properly with its built-in
Cyrillic font.  I am told 155 is a control character.  cp1251 uses it for half
of an integral sign, and cp866 for a box character, but 8859-5 and koi8-r have
vowels at 155.  So I designed cp1251 font.

Also will nano or vi or joe let you type up something that wraps at 80
columns, and then unwrap it before you import it into a wordprocessor?

response 55 of 80:

Aug 23 22:48 UTC 2007

Regarding #52; Inevitably, it does something that I don't like and then I have
to fiddle with it to get things the way that I want them.

response 57 of 80:

Aug 26 01:00 UTC 2007

I believe it has to do with the size of the indent.  In addition to
the two lines mentioned, I also have "set shiftwidth=4" in my .vimrc,
which makes my autoindent work four spaces at a time.  An eight space
indent will still be done by inserting a tab.  My indents typically
go:

    1st indent          4 spaces
    2nd indent          1 tab
    3rd indent          1 tab + 4 spaces
    4th indent          2 tabs
    5th indent          2 tabs + 4 spaces
    etc.

You can easily shift a line or group of lines in or out to a different
indent level using << and >>.  I haven't tried to see if spaces could
be substituted for tabs in all cases or not.  The above has been
acceptable to me for now.

response 59 of 80:

Aug 26 03:19 UTC 2007

#59:
  > Autoindent in vi doesn't care what your shiftwidth is set to,
  > it cares where the first non-whitespace character on the line
  > above it is.  Not sure if that's true about vim in one of its
  > special syntax modes.

I'd have to experiment to find out what it does in all cases, but I
know that vim does as you describe, but recognizes when it should
indent another level or end a level and go back to the previous
level.  When indenting a level it uses my shiftwidth, although it
doesn't use my shiftwidth when breaking up a long line into two
shorter lines, an which case, if I remember correctly, it uses
tabs, and I sometimes have to adjust them to suit my preferences,
but I'd have to do that anyway.  Sometimes, I want to align things
in a certain way, and I don't think you can automate something
like that for all cases.

  > The problem I have with tab-substitution on auto-indenting
  > doesn't require any single indent to be 8 characters from the
  > previous one, it happens on any line where the first non-whitespace
  > character is in the 8th or greater column.

As I said, indents of more than eight spaces will use tabs as much
as possible, and then spaces when an additional tab would go too far
to the right.  I don't know offhand if that can be overridden to use
only spaces or not.  Does emacs not use tabs for autoindent?  It's
been awhile since I tried playing around with emacs, but I thought it
did.

response 61 of 80:

Aug 26 22:58 UTC 2007

In vim, see :he expandtab to get spaces when you indent.