cone features

Hi, I'm a new list member but a very long term unix/linux person and
have used lots of console/tty mail clients over close to 20 years now.

Since word has it that pine is now being strongly deprecated because of
both its security problems and its nonstandard semi-open license, a lot
of people who have been living with pine are going to be looking around
for an equally powerful and easy to use alternative.  Duke has what
amounts to its own linux distribution set built on top of both Centos
and Fedora Core, and we are going to TRY to drop pine altogether from FC
4, which will be dukified sometime this summer.  I'm testing out
alternatives.

I personally don't much care for mutt or elm, and cannot stand X-GUI
mail clients as they are SO slow.  I read and write a ton of email a day
(100s of messages in, 10s of messages out) and absolutely require a good
keyboard/tty interface mail client.  pine has been adequate in this
regard for many years, but now it's done.

A few days ago I started trying out cone in earnest.  At this point I
think I've mastered all the essential functionality and have sorted out
what I really like and what I really don't like.  None of the latter are
really show-stoppers, but they are irritating and a couple of them are
fairly critical.  Anyway, here is a summary, which can be interpreted as
suggestions for things to either fix or features to functionally alter
as appropriate.

  * Documentation.  I found the online tutorial "book" absolutely
essential to getting going with cone, and looking over the list archives
I can see that a lot of the questions are (unsurprisingly) things that
are clearly answered in this resource.  Unfortunately, this
tutorial/manual has a fairly weak google footprint.  Search strings like
"cone tutorial" come up dry, and "cone manual" only manages to pick up a
page in the middle of the tutorial -- and that only because it refers to
cone's >>manual page<<.  The solution here is simple -- a toplevel page
for cone itself with a goodly amount of suitable metadata to increase
its search engine visibility.  It probably wouldn't hurt to put the
book's URL into the man page as well, as the man page is clearly not
adequate and I, at least, found that having the "online tutorial"
(really just a set of mail folders with a short version of the real
online book in it AFAICT) present interfered at some point with cone's
ability to process the mail cycle.  This may have been because I was
doing something "wrong", but that's the point -- when starting out, it
is fairly important to provide non-transient ways of getting at a
manual.

I'd therefore strongly suggest that you either move the tutorial/manual
to e.g.  /usr/share/doc/cone-*/tutorial (commonly enough done) or write
a complete man page (commonly enough done) or crossreference the
actually very nice web manual in either or both of the above and with a
nice wide google footprint, or you'll have sysadmins pulling out their
hair directing new users to the online manual over and over again as
they move over from pine.  Or do all three -- can't have too much
documentation...;-)  Don't forget the tldp.org, as well.

  * The User Interface.  While it is "usable" and in some cases very
nice, there are some places where it clunks.

    -> In message view, N and P move to the next and previous message
(just like pine).  This is good -- fingers stay on home keys.  BUT...
    -> In list view, N and P do -- nothing.  You HAVE to use cursor keys
to move up and down the list.  This is really nutso maddening,
especially for somebody moving from pine but also in absolute terms.  A
good programming practice is consistency of an interface, and this
isn't.  A second is to make the product ergodic, which means in the case
of a console interface to make it maximally functional from the home
keys WITHOUT using exotica like cursor control or pgup/pgdn, at least
not exclusively.  After all, they are in DIFFERENT LOCATIONS on
different keyboards, e.g. a laptop (where I'm working now) and a desktop
keyboard (where I'll be working later) so it is nearly impossible to
train one's fingers to rapidly type them, and it takes a lot more time
and energy to move one's whole hand over than it does to just type on
the home keys.

This is actually a theme of my other criticisms -- a really good console
interface may well SUPPORT the use of cursor and special function keys
for users that find them intuitive and easy to learn quickly, but it
should ALSO SUPPORT fast and equally intuitive ways of doing things from
the keyboard directly, with e.g. suitable emacsoid control shifts to
increase the range of what can be done.  Usually this is just a matter
of adding a few more cases to a switch -- absolutely trivial to code --
but it GREATLY increases user happiness and the long run efficiency of
the tool.  

Remember, users that REALLY want ONLY stuff like cursor keys to function
and to ALWAYS have to point there way through menus and file browsers
won't be using a console mail tool anyway, as if they want slow and
intuitive there are plenty of mouse driven mail clients that are slow as
can be but that can be mastered by a complete idiot in five minutes, at
least with a sysadmin standing behind their shoulder saying things like
"click in this menu here, see?"  A console mail tool shouldn't really
try to clone the BAD things about a real GUI tool, in other words.

    -> The Copy (Save) command really needs some work.  Or else maybe
I'm just not reading the manual correctly.  

First of all, why "copy" instead of "save"?  Copying I think of as a
file operation that REPLACES a file.  Saving I think of as moving a
message from a mail spool into a file, appending it onto the end.  I had
to literally read the online manual before I could even figure out that
copy really meant save and didn't destroy the target file.  pine goes
ever further and differentiates the two -- save appends to a file in
mailbox format (so it can be read out of a mail client in the future)
while "export" saves to a file file without the mailbox overhead
(headers and so forth).  This is a desireable and extremely useful
differentiation, as one often WANTS to just save a copy of message text
or contents and not all the headers, mailbox and otherwise.

Second, why is there no copy/save operation from the message screen?  I
generally read a message.  Perhaps it is something I want to delete, so
I hit "d" (works fine and does the right thing already in cone).
Perhaps it is something I want to file away in a mail folder, perhaps
one that exists already, perhaps one that I'm going to create anew just
for this message (for example, assuming a reply to this message, I might
want to save it in a new folder called "cone").  Perhaps it is something
I want to write out to a file somewhere on my local disk (NOT in a mail
folder local or remote).  Right now I can do NONE of these from the
message folder, and some of them I cannot do at all, or at least, I
haven't figured out how yet.

What I >>can<< do is to go up a layer to the list view, hit c to copy,
and then spend twenty seconds or more and a dozen hand movements
selecting the remote toplevel mail folder and then scrolling down
through my list of a couple of HUNDRED mail folders to the one I want to
save in.  Except oops -- cone doesn't EXIST yet, and the copy/save
operation provides no way to create it.  So I have to Ctrl-C, back up to
the right view, and add a new folder.  Reenter the list view.  Reselect
inbox.  Rehit C.  Reselect the remote toplevel folder and scroll down to
the newly created folder and I can FINALLY press return and actually
save the message and get back to reading mail with only two more hand
movements to change back to message view and delete or otherwise move on
to the next message.

This is just evil.  What I >>want<< to be able to do is -- in EITHER
message OR list view, hit C(opy) (or better yet, S(save)) and be
prompted for a folder name relative to the current root (probably the
remote IMAP root of the current account, but with setup options that
permit a local root of my home directory or ~/mail or the like).  I then
want to be able to TYPE IT IN without using any sort of file browser,
cursor keys, changed view, keeping my hands squarely on the home keys.
If the file/folder doesn't exist, it would be simply lovely to have a
prompt that says something like "folder XXXX doesn't exist, create?
(y/n):" and then have it be so if I enter y.

Mind you, I'm perfectly happy to HAVE the cursor-driven process as an
alternative way of selecting the file to save into.  I'd also be happy
to have tab-driven completion, so I can only type part of the name and
tab it to done when it is unique.  However, compare the ease of use of
what I describe to what now has to be done, and I think you'll agree
there is no question about which is easier or more intuitive.

I should also point out that even within the file browser mode, there
already exists at least one cone interface where one is presented with
the file list view and CAN scroll down through it the hard way or one
CAN just enter a path directly at the cursor.  So this is again a
consistency issue -- just make this interface the one true standard way
of entering paths for ALL entry points that require a local or remote
path to complete, and you can ensure that any energy expended on the
interface improves it for all of the things that use it.  So adding tab
completion, tell-me-twice and so on becomes pretty easy and immediately
benefits everything.

cone also really really needs a mechanism for "exporting" messages to
regular files.  Sure, these are clones of pine functionality, but one
SHOULD try to clone the GOOD parts of pine's functionality in cone --
some functionality is simply universally desireable!

    -> It's a minor point, but it would be simply lovely to
differentiate read and unread messages in list view. I know that it is
easy to press space and jump to the first unread message, but it is
sometimes nice to SEE what is read and isn't, just as it is nice to be
able to see the reply flag, what messages are marked for deletion, and
so on.

    -> Another critical problem is that -- as far as I can tell -- there
is no way to fork a web browser to display a URL contained in a message.
This is a very serious problem and will really irritate pine migrants as
pine does this very nicely and it is something that one does ALL THE
TIME with modern mail.  I don't care at all about prettifying the
display of html or the like -- if I did I'd use a gui tool -- but I do
want to be able to select url's inside mail messages (a good place to
use the good old cursor keys:-) and cause them to be handed off to my
favorite web browser du jour.  Cutting them with a mouse and pasting
them into a web browser my hand is VERY time consuming, an error prone
process, and when multiplied by tens or hundreds of thousands of users
times several times a day wastes huge amounts of human time.

    -> I don't plan to use leaf (I expect that very few people will).
This is because not only does it not USE emacs key bindings or permit
custom key bindings (as far as I've been able to determine) but BAD
THINGS happen if you are used to emacs bindings and happen to try to use
them instead of *#!@ cursor keys to move around.  However, this is in
the "annoyance" category, not a critical point, as one CAN use a
user-selected editor.

Note well that emacs key bindings are in near universal use on the unix
side and work in shells, a variety of editors, and most web browsers;
they are DESIGNED to keep the fingers on the home keys and hence are
maximally efficient.  For that reason, I personally think that the best
way to proceed is to have at least common navigational emacs bindings
AND cursor keys work (as they do for e.g. web browsers in many cases),
and to make application-specific menu options from INSIDE the default
editor very minimal -- move one out to a separate list of options
controlling sending the message, for example.

I personally would prefer it if the default editor selected in setup
were automatically invoked when starting up a message as was suggested a
few messages ago in the archives.  This would surely be something that
would be very easy to implement given that it is ALREADY a setup option
(the hard part) -- just add a conditional that invokes the code
currently executed by Ctrl-U when one moves across the header boundary,
just like pine does it.

Note that this isn't a serious criticism of cone per se.  I don't use
pico in pine either -- the little editors that are "built in" to tools
like pine or cone tend to be inadequate for serious work but are fine
for newbies or people who write three very simple mail messages a day.



If just the things above were resolved, I think that cone would move
from being usable to VERY usable -- to the point where it could attract
pine users not because they were being forced to move but because cone
does some things (e.g. handle digital signatures, manage grouped
operations) better than pine and only needs not to do anything critical
worse to become a better and more desireable tool.  Might even make cone
a "pine killer".

However, there are a few more things that would be worth addressing in
future releases -- adding a default lpr line to the setup screen, so a
particular printer can be selected without always having to retype the
lpr command, adding some way to be able to edit/view TWO messages at
once (a feature that is NOT in pine and that I and many other pine users
have really longed for, as one really DOES want to be able to read
message 33 and cut out part of it when replying to message 54 at various
points in time, which currently requires in BOTH tools something like
reply to 54, realize in the middle that you need to look at 33, pause
postpone editing 54, go back to 33, save 33 in a file (temporary or
otherwise) or read it and cut out a chunk with a mouse, reenter the
postponed message 54, and either mouse-paste in the chunk or open the
save 33 in a split screen (if one has made a real editor like jove or
emacs the default) and cut and past to one's heart's content.  VERY
clunky.

I don't have any good suggestions for a better way to do this offhand,
but clearly cone is written by some good coders -- it's just something
to think about for a future "pine-killer" release.

In the meantime, I'm pretty much committed to using cone for the
foreseeable future, as it meets my personal criteria for adequate
functionality and has some stuff I actively like relative to pine (which
I'm not detailing, but is most definitely there).

Hope the above isn't viewed as being hostile or flames -- it was all
intended to be very constructive criticism that can be used to fairly
easily improve the tool.

BTW, I >>can<< code.  I don't know how the developers view stuff like
the above, whether they'd rather make decisions and changes or want
patches.  If they are easy fixes and you agree, I personally would
prefer that you do them;-) as it takes a while to learn a piece of code
well enough to work on it.  If you want/need help, though, I can
certainly try to pitch in.

  rgb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCsW09UfPgIH3s/SIRAuHNAJsEEy0e4iAMq7FV1OJafE4/ZVSWFwCguZNA
V5u47XleAM1zoyUtb3kSTTE=
=GoA7
-----END PGP SIGNATURE-----