Subject: vi-style key bindings

From: Edan Idzerda <[email-masked]>
Date: Fri, 5 Jun 1998 00:36:39 -0400 (EDT)

Call me evil, call me what you will, but I wrote a patch a while
back to use vi-style key bindings, primarily just so that j/k
would duplicate n/p.

I wrote it as a new 'feature' called enable-vi-keys and it seems
to work quite well.  I wanted to actually change the behavior of
the global key input function, but it didn't have access to the
"state" variable so I just hacked it in all the different modules
I wanted it to work in.

I was a long time Elm user, and I've used this feature to convert
a number of others... what are the chances that something like this
could be worked into the production tree?

I'm willing to rewrite my patches in a way that changes fewer
files, but again it seemed to require too great a change to
read_char() in ttyin.c.

Instead, I chose to add sections of code like:

    if(F_ON(F_ENABLE_VI_KEYS,state)) {
        if (command == 'j')
            command = 'n';
        else if (command == 'k')
            command = 'p';
    }

To places where I wanted to circumvent Pine's regular
keystrokes with vi-style ones.  Surprisingly, the main menu
is the only place with significant conflicts (that I could tell).
Sure, the index has "j" for jump by default, but if you're
an Elm user you'll just want to type the number anyway.

Did I miss an address for patches?  Or does the development
team like to keep code changes to within their castle?  In
any event, my patches are just a trivial but nice addition to 
a fine program.

- edan

-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Edan Idzerda <[email-masked]>
Date: Fri, 5 Jun 1998 01:37:44 -0400 (EDT)

> back to use vi-style key bindings, primarily just so that j/k

Call me silly, replying to my own email.

Shortly after I sent this message, I went back to the source
to examine it again.  If I had been more patient I wouldn't
have sent the message.

My original patchset modified 
	addrbook.c
	folder.c
	init.c
	mailcmd.c
	mailindx.c
	other.c
	pine.h

Now I only modify
	init.c		(one line added)
	ttyin.c		(six lines added)
	pine.h		(one line added, one line changed)

The only difference is that the original patchset allowed 
j/k to be used at any time, except in the folder index where
it would check the state.  Now the only problem is that
j/k are now always replaced with n/p, even when inputing
text.  Bummer :)

If anyone is interested in this sort of thing, let me know.
These sort of vi-key bindings really get user-interface messy
on the "MAIN MENU" screen where you have J)ournal and K)eyboard
lock.  But everywhere else, it's no problem.

The last time I worked on it, I just didn't let vi keys work
on the main menu, since I always pick the letter away.

Blah.  That's enough out of me for tonight.

- edan

---

From: "Colin J. Raven" <[email-masked]>
Date: Fri, 5 Jun 1998 07:16:39 -0700 (PDT)

> back to use vi-style key bindings, primarily just so that j/k
Yes, you are evil if you bring *anything* from that accursed pox-ridden
son of Beelzebub called vi

> to work quite well.  
Now I am definitely in awe. Anyone who can write "features" just acquired
God-like status in my eyes, but please go on....sorry to interrupt.

>I wanted to actually change the behavior of
Er, OK I guess. Hacking *anything* in a mail program is an accomplishment.
You have just become elevated to "Deity" status. I am not only in awe, now
I'm afraid, very afraid.

> I was a long time Elm user, 
At the risk of seeming somewhat small minded here (I am, I like Pine a
helluva lot) you are a long time...what now??? "Elm User"??? Did I hear
you correctly?

> and I've used this feature to convert a number of others... 
"Convert others"?? To what Edan, Devil Worship???

> what are the chances that something like
> this  could be worked into the production tree?
I cannot speak for my superhero Stefan, and his band of caped crusaders
coding a new Pine long into the night, BUT.........No! There is no chance
that any arcane vi attribute will *ever* find it's way into the king of
all mail programs.

> my patches are just a trivial but nice addition to 
> a fine program.
Edan, lest you think I'm just lashing out in a fit of blind bigotry, I'm
*not*
The fact that you know enough to write patches to a mail program is
awesome in my mind (and I'm *not* kidding, believe me) but here's the
point as I see it.
Pine represents a step forward, from it's first iteration onwards to this
version which is "about as good as it gets". It's intuitive, it just
"knows" what users want to do (or it's development team do anyway). Elm is
about the most infuriating mail program you could ever find. It 'aint
intuitive, it's kludgy, and it's learning curve sucks.
vi blows dead monkeys period. You couldn't ask for a more obscure editor
than vi. It's quirky, and requires a thought process that could best be
described as "lateral" in order to use it properly. Why would you want to
import features from packages like that I wonder?
Pine and pico have on-screen help that allows some real new folks to get
up and running in a heartbeat, and is sufficiently powerful to allow
sophisticated users to process huge amounts of mail rapidly and
efficiently.
When you think "obscure" most people think of emacs...nosir, vi takes the
first prize. Emacs is at least a gift from the gods in that it has "power"
to do amazing things. (ask Robin)
Nononono, if you want a text editor that the average person can use,
quickly and effectively, Pico is the way to go. If you want real power,
learn emacs.
Gawd, why do I always rise to the bait?
Edan, I salute you for the try...really. Spend those awesome talents on
worthwhile projects.
I'm going to lubricate my Pelican now, he looks kinda hungry.
-Colin.
----------------------------------------------
Colin J. Raven
Network & Systems Administrator, HDS Lab, Inc.
Costa Mesa, CA  |  Harrison, NY
"Communications at the Speed of Life"

---

From: "Robin S. Socha" <[email-masked]>
Date: 05 Jun 1998 22:04:12 +0200

> Colin J Raven <[email-masked]> writes:

>> back to use vi-style key bindings, primarily just so that j/k would
>> duplicate n/p.
> Yes, you are evil if you bring *anything* from that accursed
> pox-ridden son of Beelzebub called vi

"Conversations devolve to 'vi' for much the same reason that small
children eventually start discussing excrement.  As disgusting as it
is, there is a horrid fascination with it." (Joseph M. Newcomer)

[stuff]
>> what are the chances that something like this could be worked into
>> the production tree?
> I cannot speak for my superhero Stefan, and his band of caped
> crusaders coding a new Pine long into the night, BUT.........No!
> There is no chance that any arcane vi attribute will *ever* find
> it's way into the king of all mail programs.

I don't quite agree. There is much elegance in vi's movement
keymapping. tin has nice movement keybindings, too. Pine does
not. YMMV.

>> my patches are just a trivial but nice addition to a fine program.
> [blabla] Pine represents a step forward, from it's first iteration
> onwards to this version which is "about as good as it gets". It's
> intuitive, it just "knows" what users want to do (or it's
> development team do anyway). 

Not in my opinion. There are some minor but quite annoying quirks in
pine's initial behaviour, e.g. the signature thing and pico's utterly
braindead yanking behaviour.

[elm bashing]
> vi blows dead monkeys period. You couldn't ask for a more obscure
> editor than vi. It's quirky, and requires a thought process that
> could best be described as "lateral" in order to use it
> properly. 

That is not entirely correct. vi (and vim in particular) is a very,
very good editor. It's certainly not "user friendly", but which good
program is?

> Why would you want to import features from packages like that I
> wonder?  

Because it's fast and efficient.

> Pine and pico have on-screen help that allows some real new folks to
> get up and running in a heartbeat, and is sufficiently powerful to
> allow sophisticated users to process huge amounts of mail rapidly
> and efficiently.  

Not. High volume mailing lists soon bring pine to a grinding halt and
pico is an abomination.[1] Unless you throw in procmail and vi or jed,
pine is quite unusable for larger amounts of mail. I get about 500
mails a day, and without Gnus, I would spend half my time writing
weighted score rules for procmail. Before I switched to Gnus, I had
about 900k of procmail code.

> When you think "obscure" most people think of emacs...nosir, vi
> takes the first prize.

Good boy.

> Emacs is at least a gift from the gods in that it has "power" to do
> amazing things. (ask Robin) 

Ummm... nope. You always have to take into account that XEmacs is a
monster when it comes to sucking up resources.

robin@sushi:/usr/local/lib > du xemacs
58217   xemacs
robin@sushi:/usr/local/lib > du xemacs-21.0-b42/
16715   xemacs-21.0-b42

And that's without MULE and my personal elisp dir. Nope, you cannot
quite compare that. And there's this, too:

USER       PID %CPU %MEM  NI   VSZ   RSS  SHRD  TT STAT   TIME COMMAND
robin      278  5.4 23.1   0 20356 14672  2332   9 S    330:59 xemacs
robin    12075  0.0  1.2   0  1468   784   620  p0 S      0:00 vi 
robin    12116  0.0  1.5   0  2900  1012   784  p0 S      0:00 pine 

> quickly and effectively, Pico is the way to go. 

mcedit, fte, joe (jmacs, jstar), jed... There are many that are about
as big and much more powerful. I find mcedit (Midnight Commander's
editor) a very interesting alternative in that it much behaves like
the editor in Norton Commander. Nice tool.

local/lib > for i in pico vim jove xemacs-21.0-b42 jed ;\
	    do ll `which $i` ; done
-rwxr-xr-x   1 root root 3907308 May 31 11:09 /usr/bin/xemacs-21.0-b42
-rwxr-xr-x   1 root root  442531 May  9 05:02 /usr/bin/pico
-rwxr-xr-x   1 root root  321064 Nov 14  1997 /usr/bin/vim
-rwxr-xr-x   1 root root  175187 Nov 15  1997 /usr/bin/jove
-rwxr-xr-x   1 root root  187512 Jun 13  1995 /usr/bin/jed

So... pine and jed would make a wonderful pair, especially since jed
comes with a WordStar mode... *sigh*

> If you want real power, learn emacs.  Gawd, why do I always rise to
> the bait?  

Editor envy? "Mine is bigger than anyone else's", y'know?

> Edan, I salute you for the try...really. Spend those awesome talents
> on worthwhile projects.  I'm going to lubricate my Pelican now, he
> looks kinda hungry.

Is that, like, something you'd rather not talk about in public?

Robin

Footnotes: 
[1]  Whoever wrote it: don't take it personally.

-- 
Robin S. Socha     Join the Fight: <http://www.enemy.org/>
Turn your Pentium into a gameboy...Type "WIN" at the prompt

---

From: "Adam H. Kerman" <[email-masked]>
Date: Sat, 6 Jun 1998 19:14:19 -0500 (CDT)

>From: "Robin S. Socha" <[email-masked]>
>Date: 05 Jun 1998 22:04:12 +0200

>>>Call me evil, call me what you will, but I wrote a patch a while back to use
>>>vi-style key bindings, primarily just so that j/k would duplicate n/p.

>>Yes, you are evil if you bring *anything* from that accursed pox-ridden son of
>>Beelzebub called vi

Colin, you don't understand. "j and k" are used because of the arcane nature of
the keyboard we use, left to us from the original machine put together from
gears and levers attached to individual pieces of type. The gears and levers
didn't retract quickly enough in the original model, so a keyboard was designed
partly out of a desire to slow down users and partly to fit the type in.

Subsequent generations of typewriters solved that problem, actually within a
year or two. But, they reused the same key order. (There were other keyboards in
use, such as on a Monotype machine, operated entirely with the left hand! while
the right hand threw the levers that cast the type. Another keyboard, invented
by an Army technician during the WWII who claimed that a different arrangement
of the keys could speed up typing. After all, wars cannot be fought without
properly processing the paperwork. But, historians have proven that Mr. Dvorak
falsifyed his studies. QWERTY order will always be on keyboards.)

vi uses "j" and "k" because they are next to each other on the keyboard! Which
is a damn good reason to use them. Terminals are still in use today that don't
have arrows, or with arrow keys with different key codes.

And, most keyboards stick the arrows in uncomfortable locations.

"n" and "p" have only a vague advantage over arrows on some keyboards. But, "j"
and "k" have a clear advantage.

pine really doesn't use neumonics for key bindings. Yes, "j" stands for "jump",
but that's a silly thing to call a command.

"k" isn't used in the index or the message pager. In the composer, it stands for
"kut" so ^c could be used for "cancel".

>I don't quite agree. There is much elegance in vi's movement keymapping. tin
>has nice movement keybindings, too. Pine does not. YMMV.

You start using vi (well, vim really these days) and your fingers learn the
commands. It does follow a design which becomes clear AFTER you get used to it.
It really doesn't take that long.

>braindead yanking behaviour.

That's leftover from slow modem days. It's a helpful feature at 1200 or 2400.

>High volume mailing lists soon bring pine to a grinding halt . . .

Robin, who would want to use pine for use with large lists?

>I get about 500 mails a day, and without Gnus, I would spend half my time
>writing weighted score rules for procmail. Before I switched to Gnus, I had

How on earth do people receive that much mail? If I'm on a talky list that I
don't keep up with, I trash it.

>comes with a WordStar mode... *sigh*

Heh. On DOS, I still use PC-Write, written by an ex-WordStar encoder.

---

From: Edan Idzerda <[email-masked]>
Date: Mon, 8 Jun 1998 03:02:52 -0400 (EDT)

On Sat, 6 Jun 1998, Adam H. Kerman wrote:

> "n" and "p" have only a vague advantage over arrows on some keyboards.
> But, "j" and "k" have a clear advantage.

I agree wholeheartedly.  I prefer j/k over n/p because it allows my
fingers to remain on the home row and doesn't feel like it will lead to
a repetitive motion injury.  There's that, and the fact that I'm using
vi right now.

In fact, it was Pine's enable-alt-editor-implicity feature that 
helped cement my transition to it from Elm.  With Pine, in most 
cases I could now go from folder index to message editor just by hitting 'r'
and you have to love that.

I'm a Pine Evangelist around here.  My vi-keys patch is part of how I
lure hardened Elm users away.  Frankly, I find Pine without j/k
kind of lame now.  Did I mention I was using vi right now?

I've got my patch down to three files, so that 

	'j' -> 'n'
	'k' -> 'p'		
	'/' -> 'w'

The only conflict I'm aware of is the main menu.  I haven't
decided how to resolve it.  You end up losing (J)ournal which I think
is a useful function occassionally.  You also lose (K)eyboard lock,
but I don't really care :)
 
I also presume that if you want vi keys, you don't use the builtin pico.

A full-blown vi mode, where you can hit Esc and use vi editing 
commands in parts of pine where you edit text... is definitely not
planned.   >:)

I'm not going to get into a editor religious war, suffice to say
that I use vi because it's powerful and nasty and isn't a 20MB
binary.  My pine patch is fairly inocuous and obvious is nature;
I just wondered if anyone in the Pine community would be interested.

- edan

p.s.  Patching read_command instead of read_char was much smarter. :)

---

From: "Colin J. Raven" <[email-masked]>
Date: Mon, 8 Jun 1998 07:24:53 -0700 (PDT)

OK Adam, Edan, here it is....
I'm basically stupid, lazy (or maybe too damn busy) to learn that beast
called vi. In the light of what Edan wrote, I fired up vi on Saturday
night, and actually read the book while playing with the thing.
Yeah, OK I see what you and he are saying.
Y'see, one of the effects of being so stupid is that it makes a person
very self-righteous in support of the "easy solution".
However.....somewhere along the way I thought things were supposed to be
as simple as possible.
You, Edan, Robin and many others are so far ahead of me it's ridiculous. I
guess editors that are more powerful are more appropriate when you're
doing advanced stuff. (ask Robin I guess)
*But* I *do* believe that an editor that you can use in any condition (and
that certainly applies to me) with immediate and predictable reults is the
one you stick with until you (or the editor) run outta steam. Same goes
for Elm I s'pose.
Believe it or not Adam, *that's* what I was getting at.
I'm just plain in awe of Edan and folks like him who can write C (to start
with) and can modify a mail programs' feature-set.
Well, that's my .02 worth for today...maybe.
-Colin.

---

From: "Colin J. Raven" <[email-masked]>
Date: Mon, 8 Jun 1998 07:37:21 -0700 (PDT)

Edan,
Read my post to Adam on this (it's really to you also)
> kind of lame now.  

AAAAAAARRRGGGHHHHHH! (You *had to* didn't you?) :-)
> Did I mention I was using vi right now?

Well, *now* you're talking...yup, that's true, no question. vi is lean 'an
mean. 
> binary.  

I say again (already said on the post to Adam) that I'm in awe of anyone
who can;
	a) write C
	b) write (or modify) feature-sets for a mail program
Yes, the patches *are* innocuous..absolutely.
> My pine patch is fairly inocuous and obvious is nature;
I wonder what Stefan thinks?
This list got real quiet suddenly :-) It's almost as though the spectators
became hushed, awaiting the spectacle of combat in the arena below :)
hahahaha!
I wasn't flaming you, I hope you realize that.
Later oh guru of C
-Colin

---

From: "Adam H. Kerman" <[email-masked]>
Date: Mon, 8 Jun 1998 11:50:54 -0500 (CDT)

>From: Edan Idzerda <[email-masked]>
>Date: Mon, 8 Jun 1998 03:02:52 -0400 (EDT)

>	'/' -> 'w'

The "/" drives me nuts. That's such a common way to invoke searches in pagers
and editors. I always hit it first; the error message reminds me of "w".

I wish pine would implicitly enable alternate pagers, which would solve some of
the problems. I'd use less.

---

From: "Robin S. Socha" <[email-masked]>
Date: 08 Jun 1998 22:20:55 +0200

* Colin J Raven <[email-masked]> writes:

> OK Adam, Edan, here it is....  I'm basically stupid, lazy (or maybe
> too damn busy) to learn that beast called vi. In the light of what
> Edan wrote, I fired up vi on Saturday night, and actually read the
> book while playing with the thing.  Yeah, OK I see what you and he
> are saying.  

It's about as addictive as Emacs. Wait till you get to the syntax
higlighting stuff... ;-)

> Y'see, one of the effects of being so stupid is that it makes a
> person very self-righteous in support of the "easy solution".

pico is not easy. You'll lose much more time adjusting paragraphs and
lines than you'd spend on reading the vi or jed FM.

[...]
> I guess editors that are more powerful are more appropriate when
> you're doing advanced stuff. (ask Robin I guess) 

What's "advanced"? I use XEmacs and that's not really an editor but a
programming environment. vi or jed, however, are really easy to learn
(once you find out how to start with the help menu on) and simple
things like yanking in complex quotes or quickly requoting reginons is
a pretty cool thing if you do a lot of mail/news.

> *But* I *do* believe that an editor that you can use in any condition
> (and that certainly applies to me) with immediate and predictable
> results is the one you stick with until you (or the editor) run outta
> steam. 

Happened with pico after 20 minutes ]:-> Ever tried justifying
super-cite quotes (RSS> )? Icky.

> Same goes for Elm I s'pose.  Believe it or not Adam, *that's* what I
> was getting at.  I'm just plain in awe of Edan and folks like him
> who can write C (to start with) and can modify a mail programs'
> feature-set.  Well, that's my .02 worth for today...maybe.

Ever tried mutt with vi? Cool stuff - threaded, coloured, killing,
PGP, blablabla. Ummm... and there's Gnus. Heheee...

Robin

-- 
Robin S. Socha     Join the Fight: <http://www.enemy.org/>
Micro$oft Windows 98, n. - a belated upgrade to a 32 bit hack of a
16-bit shell for an 8-bit operating system designed for a 4-bit
processor by a 2-bit company that's not worth one bit of attention.