Re: [9fans] text editor

Re: [9fans] text editor

[bwc]

I'm just annoyed at having a keyboard at all.  Any commercial products
like Englebarts cording one handed keyboard out there?

Re: [9fans] text editor

[mcguire]

ObNearMiss, reference-wise:

http://www.handykey.com/

(Looks like they got rid of the weird intertial/mercury switch/very
marginal mouse thingy from the first version.)

bwc@borf.com wrote:
 >I'm just annoyed at having a keyboard at all.  Any commercial products
 >like Englebarts cording one handed keyboard out there?

Tommy "You got your mouse on my keyboard!  No, you got your keyboard on
my mouse!" McGuire

Re: [9fans] text editor

[chad]

bwc@borf.com wrote:
>I'm just annoyed at having a keyboard at all.  Any commercial products
>like Englebarts cording one handed keyboard out there?

I've always thought that http://www.halfkeyboard.com/ was a very
interesting near-miss.  For any sort of complicated keyboard use (I had
in mind `programming'), the omission of a number row, with associated
non-alphanumerics, is too painful to bear.

chad

Re: [9fans] text editor

[Douglas A. Gwyn]

Andrew Stitt wrote:
> since i doubt I will ever see the great benefit in the mouse at least in
> the forseable future, can someone point me to some descent sam
> documentation? I cant seem to find much info on the keycommands you can
> give it.

If you can't even read the table of contents of Vol. 2 of the manual,
why should we listen to your rants about man-machine interfaces?

Re: [9fans] text editor

[Douglas A. Gwyn]

Dan Cross wrote:
> I've often wondered what blind Plan 9 users do, ...

I doubt there are any.

At Geotronics we had a blind programmer who used a VersaBraille
terminal (20- or 40-character linear Braille-bump strip, chorded
keyboard) very effectively under 6th Ed. Unix in its monocase mode
(X = x, \X = X).  To work with CRTs she had to employ a tactile
scanning device, very slow compared to sight.  We tried a speaking
terminal as an experiment, but it asn't very good.

Re: [9fans] text editor

[Douglas A. Gwyn]

Russ Cox wrote:
> i advise you, and anyone else in your situation, not to try acme.
> once you get used to it you'll curse vi and never be able to get
> anything done on unix.

Unless you have a Blit-family terminal well supported on that Unix.
I missed mine so much I started collecting 5620s and 630s to
refurbish for use instead of the horrible X11-based interfaces.

[9fans] text editor

[Andrew Simmons]

>if i wanted to move the cursor, i would have clicked somewhere
>with the mouse like god, rob, and tog intended.

Hmmm. god, rob, and tog. Three people, each of whom has a name consisting of
three letters. in lower case. Each of whom is mistaken about the correct
behaviour of arrow keys, and probably about the role of the cross-product of
two vectors in modern society. Coincidence? I think not.

Re: [9fans] text editor

[Andrew Stitt]

> left/right.  This is a design decision.  Plan 9 use the mouse as it's
> main form of interaction.
im quickly saddening, i somehow believed that plan 9 took the good ideas
of unix and advanced once more on them, silly of me, now plan 9 looks
startlingly like a mac...using primarily the mouse :'(

> The keyboard, you might say, is an
> necessary evil for the entry of characters, but not much else.

isnt that how apple sees things? how is this better? how can this vastly
improve my efficiency? it seems like its going backwards. maybe some
numbers would help...

> Everything in acme is done using the mouse apart for text entry (and
> acme does everything).

i can traverse a directory tree so much faster if you give me a keyboard
then if you have me continously button2 click my way around in acme, wasnt
one of the strongest points of *nix the idea that you can string command
lines together freely? it seems like we are taking a step backwards. How
is the mouse faster then a command line?

>
> To recap the logic (it has been repeated many times in the archives),
> once you switch to mouse centric operation, you become faster, not
> slower.

so what you are trying to tell me is that the overhead of removing my
right (or left) hand from the keyboard, placing it on my mouse and
fondling with it until i point in just the right spot, then click, then
place my hand on the keyboard again and resume typing is somehow faster
then say the vi sequence 'esc kbbbhhi'. Im somehow missing the point,
using the mouse is a needless interrupt, you waste time (brain cycles if
you will) waiting for your arm to reposition your hand over the mouse, all
the while having to locate that silly pointer, why not just move the silly
cursor without moving your hand and just your fingers?.

Ever since the industrial revolution we've known that if you stay in one
place doing one thing you are much more efficient then having to move back
and forth.  Henry Ford noticed that if you have a guy digging a hole and
he has to move from the hole, take 4 steps to the wheelbarrow and come
back again, its much MUCH slower then if he was standing in one place and
just rotating between the hole and wheelbarrow.

>It may be counterintuitive, but I believe it has been shown
> by research, not that I can quote anything.

please do! I would like to see those facts. My facts are the obvious
lessons of the industrial revolution and that out of 30 years of unix
history and all the improvements that have been made, networking, memory
management etc, none have been made to the user interface (substantially),
vi and ed are still useful fast editors, just like they were when they
first came out...

> You have to move your
> hands to get to the cursor keys
much less then a whole foot to the mouse, but i use hjkl which are right
underneath my right hand, you can move your fingers faster then your whole
hand. Thats why most great guitarists have long fingers, its just easier.

>, so it's a whole bunch better if your
> default position is holding the mouse as it does lots of things
> besides positioning the cursor.

so i type with _just_ my left hand, got it!

>
> We've all been keyboard centric at one time in our lives, and I think
> I speak for the vast majority of the list when I say that we don't
> miss cursor keys.  At all.  In fact, quite a few people buy keyboards
> without cursor keys, function keys, windows keys, number pads and
> reclaim a good square foot of their desk.

such as the happy hacking keyboard. Of course you have to look at the
market, most of the users are probably vi users and are perfectly happy
using hjkl as their arrow keys when editing. If you look at many of the
early computer arcade style games, most of them use hjkl for direction. I
play some emulated nintendo games with my gf on her computer and I remap
my side of the keyboard to hjkl and let her have the cursor keys...

> So, stick with it, persevere, and you'll hopefully feel the benefit.

since i doubt I will ever see the great benefit in the mouse at least in
the forseable future, can someone point me to some descent sam
documentation? I cant seem to find much info on the keycommands you can
give it.

  thanks
  Andrew

Re: [9fans] text editor

[Micah Stetson]

> When I log into my Xenix system with my 110 baud teletype, both vi *and*
> Emacs are just too damn slow.  They print useless messages like, 'C-h for
> help' and '"foo" File is read only'.  So I use the editor that doesn't
> waste my VALUABLE time.
>
> Ed, man!  !man ed

This actually isn't much of a joke, even in today's world.
I sometimes have to fix a problem on some remote Unix
system that's only accessible through an ISDN line (or
some such) that's already heavily used by a bunch of
people in the office looking at web pages.  Ed is about
the only editor that doesn't slow to a crawl.  Of course,
sam -r works great in this situation, too.

Micah

Re: [9fans] text editor

[Dan Cross]

I've often wondered what blind Plan 9 users do, if there are any Plan 9
users who are blind.  I know at least one well-respected computer
scientist who is blind who lives inside a talking version of emacs he
wrote.  Perhaps that's the most suitable environment for his particular
disability....

	- Dan C.

Re: [9fans] text editor

[Russ Cox]

the part that is painful is, as rog said, the differences
and inconsistencies.  every time you try to do something
and wily doesn't quite behave the same way, it hurts.

the most notable one is the different handling of
Put when the file has been changed underneath you.
i realize this was a design decision, but it's just
weird when you're used to the acme behavior.
and if you don't know how to use the wilybak
directory (which i don't, really) then it's hard
to get the file back.

another difference is the behavior of arrow keys.
in acme, if i type an up or down arrow, the screen
scrolls up or down half a page.  in wily, if i type one
of the arrow keys, the cursor moves!  if i wanted
to move the cursor, i would have clicked somewhere
with the mouse like god, rob, and tog intended.

of course, plan 9 didn't have arrow keys when wily
started, and so wily and acme have separately defined
meaning for them.  but it's unfortunate that wily caved
to the keystrokes-for-positioning factions.

it also bothers me that wily is so much less dense
than acme as far as fitting things on the screen.
there's far too much white space above and below the
text in the tag lines.

it's the little things.  wily is still my choice
of editor for unix.  it just annoys me when i use it.

Re: [9fans] text editor

[peter huang]

Can you elaborate on the differences?  What part is real painful?  I used
wily a lot so I like to know.

-peter
<anothy@cosym.net> wrote in message
news:20020426145434.68DA319A2D@mail.cse.psu.edu...
> i've used Wily for quite a bit (although not for a good while now)
> and found the differences and inconsistancies to be really painful.
> i imagine it'd still be a good step up for someone not already
> familiar with acme. the acme-in-inferno-on-unix solution is one
> i use occasionally now (since i'm only occasionally at a unix box)
> and really like.
>
> since my unix boxes are generally remote, i edit files on them most
> of the time by 9fs'ing (using u9fs on the unix box) and running
> acme. occasionally i have to edit files on a box i don't admin (and
> thus can't put u9fs on), and sam -r works well for that. even that's
> somewhat awkward (to be polite) now... i _really_ miss acme's
> mouse chording.
> ?

Re: [9fans] text editor

[Ronald G Minnich]

On Fri, 26 Apr 2002, Boyd Roberts wrote:

> I don't think it printed 'huh?'.  I used it too but can't remember
> the differences either.  I have some dim memory of it printing terse
> error messages rather than '?'.

ca. 1980, HP had a "friendly" port of an ed-like tool  that printed
something like
"bad command, armadillo-brain"
instead of
?

It was fun at first but got old for people.

ron

Re: [9fans] text editor

[anothy]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

i've used Wily for quite a bit (although not for a good while now)
and found the differences and inconsistancies to be really painful.
i imagine it'd still be a good step up for someone not already
familiar with acme. the acme-in-inferno-on-unix solution is one
i use occasionally now (since i'm only occasionally at a unix box)
and really like.

since my unix boxes are generally remote, i edit files on them most
of the time by 9fs'ing (using u9fs on the unix box) and running
acme. occasionally i have to edit files on a box i don't admin (and
thus can't put u9fs on), and sam -r works well for that. even that's
somewhat awkward (to be polite) now... i _really_ miss acme's
mouse chording.
ア


[-- Attachment #2: Type: message/rfc822, Size: 1422 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] text editor
Date: Fri, 26 Apr 2002 10:10:00 -0400
Message-ID: <7982c19b270270becaf0164e247d55f8@plan9.bell-labs.com>

> To each his own.  As I've said, I'm comfortable with vi on Unix boxen
> and with sam on Plan 9.  Your mileage may vary.  There are situations

i advise you, and anyone else in your situation, not to try acme.
once you get used to it you'll curse vi and never be able to get
anything done on unix.

Re: [9fans] text editor

[Russ Cox]

> To each his own.  As I've said, I'm comfortable with vi on Unix boxen
> and with sam on Plan 9.  Your mileage may vary.  There are situations

i advise you, and anyone else in your situation, not to try acme.
once you get used to it you'll curse vi and never be able to get
anything done on unix.

Re: [9fans] text editor

[forsyth]

>>I've been sitting here thinking at my computer for the last hour
>>and so far no input.  I'll keep the list abreast of my progress.

	``Eventually, I decided that thinking was not getting me very far
	and it was time to try building.''
			--Rob Pike, ``The Text Editor sam''

Re: [9fans] text editor

[presotto]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

I've been sitting here thinking at my computer for the last hour
and so far no input.  I'll keep the list abreast of my progress.

[-- Attachment #2: Type: message/rfc822, Size: 1285 bytes --]

From: bwc@borf.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] text editor
Date: Fri, 26 Apr 2002 08:46:07 -0400
Message-ID: <20020426124339.30D4519A0D@mail.cse.psu.edu>

I'm just annoyed at having a keyboard at all.  Any commercial products
like Englebarts cording one handed keyboard out there?

Re: [9fans] text editor

[nigel]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

>> it was Tognazzi, in an article reprinted in ``Tog on Interfaces'', who noted
>> that in experiments done by Apple people repeatedly would stoutly maintain
>> they had completed set tasks much faster using commands and keys even though they
>> had just been timed to be significantly faster using the mouse.


[-- Attachment #2: Type: message/rfc822, Size: 2942 bytes --]

From: forsyth@caldo.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] text editor
Date: Fri, 26 Apr 2002 12:41:38 +0100
Message-ID: <20020426114711.BE58F19A29@mail.cse.psu.edu>

normally i try to keep out of these discussions.
i've had my fill for three generations, but this
remark caught my attention:

>>pretty much requires visual feedback.  I.e. you need to watch the
>>screen while you are using it.  Which is bloody inconvenient in a lot

now i'm confused: what are you watching when using ijkl (or whatever it is)?
don't you watch the screen for the position of the text cursor, to
decide where to move next, and to see the effect of your changes?

> slower.  It may be counterintuitive, but I believe it has been shown
> by research, not that I can quote anything.  You have to move your
> hands to get to the cursor keys

it was Tognazzi, in an article reprinted in ``Tog on Interfaces'', who noted
that in experiments done by Apple people repeatedly would stoutly maintain
they had completed set tasks much faster using commands and keys even though they
had just been timed to be significantly faster using the mouse.

the interesting bit was the suspected cause.  it wasn't the
hand movements (you might need to do that for both interfaces).
i haven't got the book to hand so i'll give a bad summary.
(To see the correct explanation, buy the book and support ageing interface designers.)
it was something like this: the use of keys+commands
required a higher level of mental planning to organise the interaction,
which apparently obscures the perception of the passage of time--think
of being deeply engaged in something and being surprised when you look at a clock--
whereas the use of the mouse was done at a lower, mechanical level that
left the mind free for higher things, such as complaining about the mouse.
(Tog's article is more interesting and less flippant.)

Re: [9fans] text editor

[Boyd Roberts]

rog@vitanuova.com wrote:
> i think sam -d is great.  it's an excellent complement to acme for
> those times when you want to make global changes to many files at once
> without seeing all of them.  i never use normal "downloaded" sam these
> days.

Oh, I meant interactively.  Obviously, sam is perfect for what you describe.

I think acme has some neat ideas -- I just can't use it [mindset problem].

ob sam -d:

# construct reply
(
        EDITOR='sam -d' rep -i > /dev/null 2>&1 <<'!'
/^To:.*\n(    .*\n)+/
x/\n    /c/ /
/^To:.*\n/
...t.
x/[\-a-zA-Z0-9._&]+@/c/postmaster@/
/^To:.*\n/
/^To:.*\n/
s/^To:/Cc:/
,x/^Cc: \n/d
,x/^Bcc: \n/d
,x/^Subject: \n/d
1,/^\n/
a
die, worthless spammer.

postmaster: check out the Mail Abuse Protection System (MAPS)
            http://maps.vix.com

...
1,/^$/p
w
q
!
) || exit 1

Re: [9fans] text editor

[forsyth]

normally i try to keep out of these discussions.
i've had my fill for three generations, but this
remark caught my attention:

>>pretty much requires visual feedback.  I.e. you need to watch the
>>screen while you are using it.  Which is bloody inconvenient in a lot

now i'm confused: what are you watching when using ijkl (or whatever it is)?
don't you watch the screen for the position of the text cursor, to
decide where to move next, and to see the effect of your changes?

> slower.  It may be counterintuitive, but I believe it has been shown
> by research, not that I can quote anything.  You have to move your
> hands to get to the cursor keys

it was Tognazzi, in an article reprinted in ``Tog on Interfaces'', who noted
that in experiments done by Apple people repeatedly would stoutly maintain
they had completed set tasks much faster using commands and keys even though they
had just been timed to be significantly faster using the mouse.

the interesting bit was the suspected cause.  it wasn't the
hand movements (you might need to do that for both interfaces).
i haven't got the book to hand so i'll give a bad summary.
(To see the correct explanation, buy the book and support ageing interface designers.)
it was something like this: the use of keys+commands
required a higher level of mental planning to organise the interaction,
which apparently obscures the perception of the passage of time--think
of being deeply engaged in something and being surprised when you look at a clock--
whereas the use of the mouse was done at a lower, mechanical level that
left the mind free for higher things, such as complaining about the mouse.
(Tog's article is more interesting and less flippant.)

Re: [9fans] text editor

[rog]

> Good thing Plan 9 has ed 'cos sam -d is just a bit too 'special'; slightly
> reminiscent of teco, except sam's 'dot' is some arbitrary size.

i think sam -d is great.  it's an excellent complement to acme for
those times when you want to make global changes to many files at once
without seeing all of them.  i never use normal "downloaded" sam these
days.

sam -d *.c
X/./,x/^(  )+/x/  /c/\t/
X/'/w
q

Re: [9fans] text editor

[Michael Grunditz]

I am a rather new plan9 user and the first time I installed it I was
very confused , I was like you , used to cmd line unix editors.

In my second try I actualy tried to learn acme, and after hacking the
imap upas/fs a couple of hours with it I began to like it , acme.

Now I dont have any cisc pc , but I have a RiscPC :), except a 68040 ql
compatible , so no plan9 for me :(

/Michael Grunditz

In message <Pine.GSO.4.21.0204260613271.20558-100000@weyl.math.psu.edu> you wrote:

>
>
> On Fri, 26 Apr 2002 nigel@9fs.org wrote:
>
> > To recap the logic (it has been repeated many times in the archives),
> > once you switch to mouse centric operation, you become faster, not
> > slower.  It may be counterintuitive, but I believe it has been shown
> > by research, not that I can quote anything.  You have to move your
> > hands to get to the cursor keys
>
> ... unless you have sensible mappings for them - hjkl works fine, as
> far as I'm concerned.  Not to (re)start religious wars, but... mouse
> pretty much requires visual feedback.  I.e. you need to watch the
> screen while you are using it.  Which is bloody inconvenient in a lot
> of situations.  FWIW, I still prefer vi, but using sam as extended ed
> works for me...
>

Re: [9fans] text editor

[Boyd Roberts]

Boyd Roberts wrote:
> So you have to ignore the keytops and think 'qwerty'.

Then there are those marvellous HP 9000 series keyboards
that don't have / and | marked on the keytops -- that's
a world of pain.  IIRC they are even in 'weird' places.

Re: [9fans] text editor

[Boyd Roberts]

nigel@9fs.org wrote:
> In my ignorant youth, I once used em(1), so called Ed for Mortals.  I
> can't now remember what the differences were.  Perhaps it printed
> 'huh?'  rather than '?'  to be more 'helpful'.

I don't think it printed 'huh?'.  I used it too but can't remember
the differences either.  I have some dim memory of it printing terse
error messages rather than '?'.

> Anyhow, I only had to transpose 'e' to 'r' once when invoking it
> (easily done, even on boyd's keyboard) to decide never to use it again.

Another point in ed's favour is that I'm yet to see 'e' and 'd' not
where they 'should' be.  'm' however is next to 'l' on azerty.

Good thing Plan 9 has ed 'cos sam -d is just a bit too 'special'; slightly
reminiscent of teco, except sam's 'dot' is some arbitrary size.  As well
as the fact that the 'a' and '-' keytops can be in 'weird' places too:

    azerty:

        'a' = 'q'
        '-' = unshifted 6

    swedish qwerty:

        '-' = '/'

So you have to ignore the keytops and think 'qwerty'.

Re: [9fans] text editor

[Alexander Viro]

On Fri, 26 Apr 2002 nigel@9fs.org wrote:

> As rog points out, if you don't want to watch the screen, you're not
> using a visual editor.

.... or at that moment you are looking at the other part of text. Or at
the graph in another window.  Or at the book on your table.

> hjkl does solve the hand motion issue, but a strong reason for that

Sorry.  All other reasons aside, there is an issue with bandwidth of
channels we can't change - eyes and fingers.  And in quite a few
situations that can become a scarce resource.  So much that having half
of output and large part of input bandwidth tied up whenever you need
to change the location where you are editing text gets rather annoying.

_Having_ the text on-screen in real-time is nice and often very useful.
Being forced to follow the cursor, OTOH...

To each his own.  As I've said, I'm comfortable with vi on Unix boxen
and with sam on Plan 9.  Your mileage may vary.  There are situations
when mouse-intensive interface becomes a problem; if you don't have to
deal with any of them - more power to you, but that doesn't make your
preferences One True Way(tm).

Re: [9fans] text editor

[nigel]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

As rog points out, if you don't want to watch the screen, you're not
using a visual editor.

hjkl does solve the hand motion issue, but a strong reason for that
mapping was ambiguity between tty escape sequences, and vi(1)
commands. Basically it couldn't tell the difference between the
user pressing escape then A, and a cursor key generating the very
same sequence.

It tried timing out after escape waiting for another character, but
at 9600 baud, users often generated ambiguous sequences within
the timeout. It would never work.

As a result, all users learnt hjkl for their own sanity, and configured
their termcaps not to tell vi(1) about cursor sequences just in case
it was stupid enough to try to tell the difference.


[-- Attachment #2: Type: message/rfc822, Size: 2400 bytes --]

From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] text editor
Date: Fri, 26 Apr 2002 06:21:24 -0400 (EDT)
Message-ID: <Pine.GSO.4.21.0204260613271.20558-100000@weyl.math.psu.edu>



On Fri, 26 Apr 2002 nigel@9fs.org wrote:

> To recap the logic (it has been repeated many times in the archives),
> once you switch to mouse centric operation, you become faster, not
> slower.  It may be counterintuitive, but I believe it has been shown
> by research, not that I can quote anything.  You have to move your
> hands to get to the cursor keys

..... unless you have sensible mappings for them - hjkl works fine, as
far as I'm concerned.  Not to (re)start religious wars, but... mouse
pretty much requires visual feedback.  I.e. you need to watch the
screen while you are using it.  Which is bloody inconvenient in a lot
of situations.  FWIW, I still prefer vi, but using sam as extended ed
works for me...

Re: [9fans] text editor

[Sam Hopkins]

..... unless you get hosted inferno up and running and do all your editing
with its acme.  It's not as integrated as it is on Plan9, but at least it's
a solution.

There's also always Wily ...

Sam

On Friday 26 April 2002 10:10, you wrote:
> > To each his own.  As I've said, I'm comfortable with vi on Unix boxen
> > and with sam on Plan 9.  Your mileage may vary.  There are situations
>
> i advise you, and anyone else in your situation, not to try acme.
> once you get used to it you'll curse vi and never be able to get
> anything done on unix.

Re: [9fans] text editor

[nigel]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

In my ignorant youth, I once used em(1), so called Ed for Mortals.  I
can't now remember what the differences were.  Perhaps it printed
'huh?'  rather than '?'  to be more 'helpful'.  Anyhow, I only had to
transpose 'e' to 'r' once when invoking it (easily done, even on
boyd's keyboard) to decide never to use it again.


[-- Attachment #2: Type: message/rfc822, Size: 4519 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 226 bytes --]

> Im in desperate need of a text editor that can deal with a keyboard
> intensive user

/bin/ed (or sam -d): as keyboard-intensive as you could wish for!

see attachment (god know where it came from, but it amused me)


[-- Attachment #2.1.2: ed --]
[-- Type: text/plain, Size: 2745 bytes --]

When I log into my Xenix system with my 110 baud teletype, both vi *and*
Emacs are just too damn slow.  They print useless messages like, 'C-h for
help' and '"foo" File is read only'.  So I use the editor that doesn't
waste my VALUABLE time.

Ed, man!  !man ed

ED(1)               UNIX Programmer's Manual                ED(1)

NAME
     ed - text editor

SYNOPSIS
     ed [ - ] [ -x ] [ name ]
DESCRIPTION
     Ed is the standard text editor.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard.  Everyone else
loves ed because it's ED!

"Ed is the standard text editor."

And ed doesn't waste space on my Timex Sinclair.  Just look:

- - -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
- - -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
- - -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!

"Ed is the standard text editor."

Let's look at a typical novice's session with the mighty ed:

golem> ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Note the consistent user interface and error reportage.  Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.

"Ed is the standard text editor."

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code!  I just want an EDitor!!
Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
you jest.  They chose the most karmic editor of all.  The standard.

Ed is for those who can *remember* what they are working on.  If you
are an idiot, you should use Emacs.  If you are an Emacs, you should
not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!

Re: [9fans] text editor

[Alexander Viro]

On Fri, 26 Apr 2002 nigel@9fs.org wrote:

> To recap the logic (it has been repeated many times in the archives),
> once you switch to mouse centric operation, you become faster, not
> slower.  It may be counterintuitive, but I believe it has been shown
> by research, not that I can quote anything.  You have to move your
> hands to get to the cursor keys

..... unless you have sensible mappings for them - hjkl works fine, as
far as I'm concerned.  Not to (re)start religious wars, but... mouse
pretty much requires visual feedback.  I.e. you need to watch the
screen while you are using it.  Which is bloody inconvenient in a lot
of situations.  FWIW, I still prefer vi, but using sam as extended ed
works for me...

Re: [9fans] text editor

[rog]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

> Im in desperate need of a text editor that can deal with a keyboard
> intensive user

/bin/ed (or sam -d): as keyboard-intensive as you could wish for!

see attachment (god know where it came from, but it amused me)


[-- Attachment #2: ed --]
[-- Type: text/plain, Size: 2745 bytes --]

When I log into my Xenix system with my 110 baud teletype, both vi *and*
Emacs are just too damn slow.  They print useless messages like, 'C-h for
help' and '"foo" File is read only'.  So I use the editor that doesn't
waste my VALUABLE time.

Ed, man!  !man ed

ED(1)               UNIX Programmer's Manual                ED(1)

NAME
     ed - text editor

SYNOPSIS
     ed [ - ] [ -x ] [ name ]
DESCRIPTION
     Ed is the standard text editor.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard.  Everyone else
loves ed because it's ED!

"Ed is the standard text editor."

And ed doesn't waste space on my Timex Sinclair.  Just look:

- - -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
- - -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
- - -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!

"Ed is the standard text editor."

Let's look at a typical novice's session with the mighty ed:

golem> ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Note the consistent user interface and error reportage.  Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.

"Ed is the standard text editor."

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code!  I just want an EDitor!!
Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
you jest.  They chose the most karmic editor of all.  The standard.

Ed is for those who can *remember* what they are working on.  If you
are an idiot, you should use Emacs.  If you are an Emacs, you should
not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!

Re: [9fans] text editor

[nigel]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Sorry, Plan 9 does not use cursor keys in editing, not even for
left/right.  This is a design decision.  Plan 9 use the mouse as it's
main form of interaction.  The keyboard, you might say, is an
necessary evil for the entry of characters, but not much else.
Everything in acme is done using the mouse apart for text entry (and
acme does everything).

To recap the logic (it has been repeated many times in the archives),
once you switch to mouse centric operation, you become faster, not
slower.  It may be counterintuitive, but I believe it has been shown
by research, not that I can quote anything.  You have to move your
hands to get to the cursor keys, so it's a whole bunch better if your
default position is holding the mouse as it does lots of things
besides positioning the cursor.

We've all been keyboard centric at one time in our lives, and I think
I speak for the vast majority of the list when I say that we don't
miss cursor keys.  At all.  In fact, quite a few people buy keyboards
without cursor keys, function keys, windows keys, number pads and
reclaim a good square foot of their desk.

So, stick with it, persevere, and you'll hopefully feel the benefit.

Nigel


[-- Attachment #2: Type: message/rfc822, Size: 2022 bytes --]

From: Andrew Stitt <astitt@cats.ucsc.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] text editor
Date: Fri, 26 Apr 2002 08:47:09 GMT
Message-ID: <Pine.SOL.3.96.1020425205816.12869A-100000@teach.ic.ucsc.edu>

hey, Im just getting into plan 9, and Im in desperate need of a text
editor that can deal with a keyboard intensive user, I dont like having to
reach over and touch my mouse everytime i want to move the cursor, it
seems as if any keyboard arrow keys just effect the overall window, not
the cursor address. Ive tried to read up on acme and sam and I dont see
anything that really addresses this. Are there keyboard commands to move
the cursor around or am i stuck having to fondle my mouse everytime i want
to move my cursor back two characters? thanks
     Andrew/A Frayed Knot

[9fans] text editor

[Andrew Stitt]

hey, Im just getting into plan 9, and Im in desperate need of a text
editor that can deal with a keyboard intensive user, I dont like having to
reach over and touch my mouse everytime i want to move the cursor, it
seems as if any keyboard arrow keys just effect the overall window, not
the cursor address. Ive tried to read up on acme and sam and I dont see
anything that really addresses this. Are there keyboard commands to move
the cursor around or am i stuck having to fondle my mouse everytime i want
to move my cursor back two characters? thanks
     Andrew/A Frayed Knot