On Sat, 30 Aug 2003, Peter Sergeant wrote:
If you want to use vi instead of pico always, select the option labeled
enable-alternate-editor-implicitly -- this kind of screws up the display
of message header info though, so personally I didn't care for this
setting.
How so? Dropping into it from mutt, the headers are nicely highlighted
(where appropriate), and I've added a bit of magic to put me directly
into input mode a line down from the headers... Does pine treat this so
differently?
I like Pine a lot, but this is an area where I'll concede that Mutt does a
better job -- but that's mainly because Pine Pico are pretty tightly
integrated.
long-winded explanation, because I'm having a hard time succinctly
describing in plain text how this plain text application works... :-(
In Pine, my default message composition interface -- at least for the
first screenful of information, is something like this:
From: Chris Devers [EMAIL PROTECTED]
Reply-To: Chris Devers [EMAIL PROTECTED]
To : [EMAIL PROTECTED]
Attchmnt:
Subject : Re: pine editor derby, was Re: London.pm identity cards
- Message Text -
On Sat, 30 Aug 2003, Peter Sergeant wrote:
If you want to use vi instead of pico always, select the option
[ a screenful of editable fields ... ]
^G Get Help ^X Send^R Read File ^Y Prev Pg ^K Cut Text ^O Postpone
^C Cancel ^J Justify ^_ Alt Edit ^V Next Pg ^U UnJustify ^T To Spell
The lines up to /^- Message Text -$/ line are configurable, but
they are distinct from the editable area itself. Also, the command help
lines at the bottom display one set of commands when the cursor is in the
header lines, and another set when in the message composition section. The
example above is from message composition mode.
If the message is long enough, you scroll away from the headers and then
Pico gets the whole display area (minus the bottom command rows), but
there's always a strong division between headers, message, and footers.
The best description I can think of is to imagine these applications as if
Pine Mutt were GUI applications or web pages.
In Pine, the header rows are treated like labeled text fields, message
body composition is a separate multi-row text area, and the footer command
row is like a set of labeled buttons. This means that it is not possible,
for example, to move the cursor onto any area other than the labeled
areas in the header or the message composition section.
From what I've used of Mutt, on the other hand, it seems like the whole
screen is editable, so if it were a GUI then the whole area would be a
text field, and you can (I think?) move the cursor anywhere within that
region that you choose. In the background, Magic[tm] happens to make sure
that special parts of that editable area are handled in special ways. (If
I misunderstand that, feel free to correct me -- I'm not a Mutt user :)
This is why handling of external editors works so non-smoothly in Pine.
When you invoke an external editor, you go into a different full screen
mode.
Functionally, after you fill in the header lines and hit down or enter
to leave the header lines, the screen is redrawn with Vim or Emacs or what
have you, and the entire screen real estate is given to that editor to
work on your message body.
To get back to your header lines, you have to quit out of the editor, at
which point you're dropped back to a screen like what you see above.
The transition is hardly seamless.
In GUI/browser terms, it's like filling in the header fields, then opening
up a fully external application to edit the message body and only the
message body. After you save your changes in that external application and
quit out of it, you're dropped back into the original.
Mutt, by contrast, seems to allow the external editor to control
everything, so there isn't that sense of going through a tunnel to get to
the editor -- Mutt itself is almost more like a proxy between $EDITOR and
the mail system.
I suspect that if the transition were to get any better in Pine, a way
would have to be found to embed $EDITOR into the display area such that it
can share that portion of the screen below the header lines (maybe)
above the command lines -- like an applet $EDITOR, or something.
Does this make sense? It's pretty straightforward, but I'm not sure if I'm
describing it clearly, hence the rambling... :-/
--
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/
throwaway, adj.
(Of a program) sold below cost for public debugging. See also PROTOTYPING.
-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995
