Subject: Re: Suggestions

From: "A. Hilborne" <[email-masked]>
Date: Thu, 3 Feb 1994 18:07:48 +0000 (GMT)

On Thu, 27 Jan 1994, Gregory J. Atchity wrote:

>    I just joined this group a week ago, and I see a lot of suggestions,
> so I guess they are welcomed by the designers.  I'll put my two cents
> in, let me know if you want any more of my money.
> 
>    First, I'd rather see the number of lines in a message in the index
> instead of the number of characters it has.  I don't receive that much
> mime, and so lines is a bit more useful to me.  Perhaps that should be an
> option.
> 
>    Second, why does the 'To:' line require commas between members of a
> list? I don't know much about mail programs, but I thought all addresses
> had to be one word, and so I'd like to see Pine parse each word regardless
> of whether it has a comma after it or not, and insert the commas for me if
> I forget.  This sounds do-able to me, even if aliases can be multi-word.

This message is a good example of how Pine has moved far away from it's
principle original design goal--KISS or, "Keep it simple, stupid."

The kinds of things Gregory would like to see are options in Mush, VM (almost
certainly) and probably several other mailers designed for power users.

I started using Pine because it was a solid mailer which did 70 percent of what
I wanted to do and did much of it well.  Yes, only 70 percent.  I always wanted
a score or so "enhancements."  However I knew that the sum total of all the
different enhancements which Pine users the world over wanted numbered a few
hundred.

I was happy to stick with a simple mailer because it could be used adequately
not only by me, but by all users of many different levels of understanding and
ability.  For the same reason our Computing Service here was happy to offer
Pine as our standard UNIX mailer.  We wanted to have something that was simple
to use, required no user configuration and which (one of early Pine's proud
boasts) didn't need paper documentation because it was so small.  Use of IMAP
and MIME were additional advantages which could simplify and enhance our mail
setup here but they were secondary.

Now creeping featurism threatens to swallow Pine whole.  The present
configuration file is a nightmare in some areas, and it continually grows.  One
may see some of the problems by the number of exchanges on this list which go:

    Q.	Why doesn't pine do "this?"

    A (several times.)  Just put "option77=blah" in your .pinerc file.

Pine is now complicated.

Don't misunderstand me.  There are some wonderful parts of Pine.  Pico is
pretty good and so are the supplied IMAP daemon and the c-client.  Indeed it is
because of these, Pine's solid base, that there is such a demand for Pine to do
even more.  I don't like this idea (although all my wished-for extra features
still aren't implemented :-)  Equally to the point I know that there are a lot
of people who are unhappy at Pine's current development.

I'm afraid that I don't have a definitive solution, but I will offer one
suggestion:

    Pine should be frozen at it's current state of development, or preferably a
    couple of states back, where the config file was simpler and there were no
    stubs for "coming" features visible to the user.

    This version of Pine can either retain the name, or become, say, "Pinelet."
    Perhaps someone out there can think of a suitable diminutive name.  The
    version we have now can then move on until it suits all us power users out
    here.  Only bug fixes would be back-grafted onto Pinelet.

What do you think?

--
Andrew M. Hilborne                        [email-masked]
Computing Service                    Tel: +44 91 222 8226 (direct)
University of Newcastle upon Tyne, UK.    +44 91 222 8039 (Comp Service office)

---

From: Barry Landy <[email-masked]>
Date: Thu, 3 Feb 1994 20:43:05 +0000 (GMT)

(I have edited the commented original as it is getting v long).

I agree strongly with the KISS aim, though I dont arrive at the same 
conclusion  as Andrew, probably because my simple users still find it 
simple. 
My replies thus reflect that principle.

 On Thu, 3 Feb 1994, A. Hilborne wrote:

> > instead of the number of characters it has.
> > 
KISS says "please give the users information they understand; a 'random' 
large number tells them nothing (and since the count includes data in 
headers, it really *is* random). I personally see no reason for any data 
of this type, but if there has to be, line count sounds sensible to me 
(if well defined).

> > I forget.  This sounds do-able to me, even if aliases can be multi-word.
This one I cannot agree with; permitting implied separators causes chaos. 
Separation by commas is well understood even in plain English (apples, 
oranges, and pears).

> principle original design goal--KISS or, "Keep it simple, stupid."
Lots omitted here............

>     here.  Only bug fixes would be back-grafted onto Pinelet.
Knowing that a lot of the coming features have been asked for by our 
users, especially features to make asynch use much more efficient (eg 
phone use) I cannot support this. I think the critical thing is to keep 
the simple subset clear (and simple!).

=======================================================================
Barry Landy, Head of Systems and Development,
University of Cambridge Computing Service
[email-masked]      0223-334713   +44-223-334713

---

From: Jack Churchill <[email-masked]>
Date: Fri, 4 Feb 1994 07:15:41 +1100 (EST)

> different enhancements which Pine users the world over wanted numbered a few

Same here.

> setup here but they were secondary.

Same here.

>     stubs for "coming" features visible to the user.

How about a menu-driven configuration built into pine with documentation
to explain what the various options mean.  To add spice have special
options in the global config file to stop users modifying their own
configs.  More work I know but it would make pine configuration much
simpler for the users. 

  Jack N. Churchill                         | [email-masked]
  CSIRO  Division of Exploration and Mining | [email-masked]
  PO Box 136  North Ryde  NSW  2113         | Phone:  +61 2 887 8884
  Australia                                 | Fax:    +61 2 887 8921

---

From: Michael Wolf <[email-masked]>
Date: Thu, 3 Feb 1994 22:14:54 +0100 (MET)

On Thu, 3 Feb 1994, A. Hilborne wrote:

> 
> Pine is now complicated.
> 
> Don't misunderstand me.There are some wonderful parts of Pine.  Pico is
> pretty good and so are the supplied IMAP daemon and the c-client.Indeed it is
> even more.I don't like this idea (although all my wished-for extra features
> still aren't implemented :-)Equally to the point I know that there are a lot

I am new to this list, I use pine now instead of elm since several weeks
and I like it. In order to satisfy both "normal" users and power users I
would prefer to have a "User Level" command with options "beginner" and
"advanced" and in addition, to have the possibility to generate .pinerc
through a dialog. 

 Michael Wolf                                  | email:
 Dept of Mechanical and Automotive Engineering | [email-masked]
 Fachhochschule Muenchen University            |

---

From: John Stumbles <[email-masked]>
Date: Thu, 3 Feb 1994 21:16:30 GMT

[...in reply to a suggested enhancement...]

> I wanted to do and did much of it well. 
[...]
> configuration file is a nightmare in some areas, and it continually grows. 
[...]
> What do you think?

Firstly pardon the severe edits - I'd done a more thorough job on this
reply and just got to the end, reformatted the last paragraph, and ... got
an error message about failing to allocate 144 bytes or something. Pine
could have snipped 144 chars from my message, I wouldn't have cared so
much - instead it just hung there 'till I gave the PC the 3-finger salute
and then I lost the lot :-(

Anyway, I quite agree with you about the config file - it is a nightmare!
- but I'd like to separate it from the other sort of enhancement request
you were actually replying to which was about "when a user does
<such-and-such action which users do> can Pine be made to treat it as a
correct thing to do instead of spitting it out as an error".  The example
was separating mail aliases by commas or spaces - other examples are
showing end-of-file messages when the end has been displayed instead of
when the user tries to page down, and the action of various PC cursor
keys. These sorts of enhancements do not require extra menu options or
setting in the config file, and can make Pine more instinctively natural
to use - user friendly - which I believe is the pine philosophy and A Good
Thing! 

Anyway the *%œ"@#! config file - I suggest:

(1) most straightforward options should be settable by the (promised) 
Setup/Options screen, so the casual user should never have to edit their 
.pinerc or (PC) PINERC file

(2) Pine should come 'out of the box' with a simple config file that can 
be set by the Options function, and this file can either be expanded by 
the user adding options manually, or by the user setting an 
'intermediate' or 'advanced' user setting - in some way that the casual 
user cannot do accidentally. Maybe by running pine from the command line 
with some flag like:
	PINE user_options=intermediate [or advanced]
whereupon it would read the current config file and write out a new one 
with extra bells and whistles.

(3) documentation! At present there is nothing between the 2-page Readme
file and the 180K tech notes (in some wierd MAN-page type of format) which
has to be FTPed over separateley. I suggest pine should come with some
intermediate level documentation which should explain what you can
configure, and give examples in more detail than in the config file
(indeed why have any in the config file - particularly in the PC version
where RAM is precious - if you can have decent documentation with it?) The
point is if you've got documentation you don't have to read it - and the
casual user won't - but if you haven't got it you can't! 

(?) actually I think there could be a case for having two config files -
particularly in PC-PINE - one for the user's name, login id etc (which
the user could muck about with) and another for system-type settings (like
inbox-path={imaphost.domain}inbox etc which are easier to screw up and
the casual user unlikely to need to deal with).

John Stumbles                                       [email-masked]
University of Reading                                              0734 318435
Whiteknights, Reading, UK
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Mike Roch <[email-masked]>
Date: Thu, 3 Feb 1994 21:32:03 +0000 (GMT)

> configuration file is a nightmare in some areas, and it continually grows.  

I'm very conscious that Pine is Washington's property - they made it -
they pay for it and so they're entitled to do what they like with it -
the rest of us are just free-loading.

However, I have to say that I agree wholeheartedly with Andrew on this. 
(Boring over here aren't we?) We chose Pine because it did most of the
things that most people wanted - painlessly. User support gets harder as
more arcane features/options are added. Instead of having 20 advisors who
know all about Pine 3.0x, we're unlikely to have more than 5 who'll get to
grips with all of Pine 3.8x. 

I do think that you should be conservative about adding features unless
they are geared to making life easier for Pine's original constituency. By
definition this list is for the people who setup/fix Pine, not its users -
contributions are unlikely to be representative of the user base. 

On the same reasoning it's the ever-growing Pine strand that should have 
a new name, not the "original". The original joke (PIne's Not Elm) is 
going to backfire when people start to say that Pine's Not Pine Anymore.

Mike

==============================================================================
Mike Roch, Computer Services Centre,                          Tel: 0734 318430
The University, Whiteknights, Reading, RG6 2AF                Fax: 0734 753094

---

From: Philip Hazel <[email-masked]>
Date: Fri, 4 Feb 1994 09:27:52 +0000 (GMT)

>     here.  Only bug fixes would be back-grafted onto Pinelet.

I don't think this is a good idea. There would be confusion between 
the two products, and one wouldn't be able to remember which did what.

We already have problems with the "novice" vs "old growth" modes in Pine.
Scenario:

A user phones up with a problem about the message. Adviser asks "What are 
the full headers?". User can't see all the headers, of course. Adviser says 
"press h to see the full headers". Users presses h. Nothing happens, 
because h is a "power user feature". A messy interchange follows.

I see no reason why Pine shouldn't have a number of configurable options, 
provided that the defaults are all suited for the novice, and there is an 
easy-to-use configuration screen with lots of explanation for each option, 
(a paragraph rather than a couple of words), so it is simple to make changes.

Users will advance as time progresses. Novices become power users in time. 
It's simpler if they can just start to use additional features of the same, 
familiar product. 

Philip

--
Philip Hazel                   University Computing Service,
[email-masked]             New Museums Site, Cambridge CB2 3QG,
[email-masked]          England.  Phone: +44 223 334714

---

From: Dave King <[email-masked]>
Date: Fri, 4 Feb 1994 11:30:48 +0000 (GMT)

Apologies for yet another suggestion (which may have been made before),
but if "pine.conf" settings (when set) took precendence over ".pinerc" 
settings this would give sites an opportunity to setup Pine to suit their
user community. This would allow sites to: 

1.  Take advantage of new Pine releases (to overcome possible bugs).
2.  Control the release of new features to the user community.
3.  Block possibly undesireable features ("Update" and enable-suspend).
4.  Fix variables such as "user-domain", and possibly "news-server", etc.

If this approach was adopted, Pine would need to clearly inform the user
when a user configured option has been disabled if the user sets it in 
their .pinerc file.

As an example, I currently have the bounce and zoom commands disabled in
pine.conf to avoid user confusion, but will make them available when they
are implemented. 

Is the "pine.conf takes precedence over .pinerc" the perfect solution? 

Dave

-------------------------------------------------------------------
Dave King, Admin. Computing Services Manager, University of Bristol
[email-masked] (JANET)  [email-masked] (INTERNET)

---

From: "A. Hilborne" <[email-masked]>
Date: Fri, 4 Feb 1994 12:31:05 +0000 (GMT)

I must say I am impressed by the level of debate which has come about as a
result of my previous message.

To answer all the messages I have seen so far...

0.  I should have started off by thanking the UoW crew for giving us Pine at
    all.  I'd like to make amends by offering a VERY BIG THANKYOU here.

1.  I think that a reasonable config/preference screen would remove a lot of
    the problems with the present config file.

2.  The possibility that "Pine-out-of-the-box" should use a simple config
    file, with a "power-user option" to create and use a more complex one
    sounds attractive, but would clearly be considerable work.

3.  I shall definitely bear in mind the suggestion that "Pinelet" be something
    like "pine -p <simple config file>."

4.  I accept the argument that Pine and "Pinelet" should not be developed
    separately.

5.  The suggestion that pine.conf override .pinerc also sounds interesting,
    but there should be a .pinerc option to override the override!  Many
    mature UNIX programs do this sort of thing (UCB Mail, EMACS, nn, ...) but
    normally it is only a command-line option.  This a pain because it makes
    the user have his own wrapper when he hardly needs one.

6.  Documentation.  If a reasonable paper manual appears, it should hive off
    all the advanced options to a _very_ separate section.

---

From: Barry Landy <[email-masked]>
Date: Fri, 4 Feb 1994 14:46:32 GMT

Sounds to me like three levels are needed:

pine.conf  -  naive users standard defaults
.pinerc    -  upgrades for less naive users (settable by editor or online 
              config system) 
pine.absolute - local settings that cannot be over-ridden in any way

(and this does not make things more complicated for the simple users, but 
does allow the system managers to lock out things that they dont want 
experimented with or altered).

> Is the "pine.conf takes precedence over .pinerc" the perfect solution? 

-------------------------------------------------------------------------------
Barry Landy                        Computer Laboratory:+44 223 334600
Head of Systems and Development    Direct line:        +44 223 334713
University of Cambridge Computing Service
New Museums Site                   Email:[email-masked]
Pembroke Street, Cambridge CB2 3QG

---

From: "Robert A. Hayden" <[email-masked]>
Date: Fri, 4 Feb 1994 13:32:29 -0600 (CST)

> experimented with or altered).

I dont' like it.

Admins I know are very paranoid.  As a matter of fact, when I installed 
filter and started sorting my mail into different subject-related 
mailboxes, I had to spend an hour explaining to the admin exactly what it 
was I was doing, and even then she only grudingly agree to allow me to do 
it because I get so much mail.

All it would take is an unapproachable and uninformed admin and users 
have all advanced options locked out, which turns around and makes pine 
useless.

I'd simply have it so that pine.conf is the default, and then users who 
know what they are doing modify their .pinerc for their specific needs.

Of course, since I'm not an admin, I'm just reporting on what I;d like as 
a user (and what I fear as a user).

____        Robert A. Hayden          <=> [email-masked]
\  /__          -=-=-=-=-             <=>          -=-=-=-=-
 \/  /   Finger for Geek Code Info    <=> In the United States, they
   \/  Finger for PGP 2.3a Public Key <=> first came for us in Colorado...
-=-=-=-=-=-=-=-
(GEEK CODE 1.0.1)  GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
		       n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

---

From: Dan Schlitt <[email-masked]>
Date: Fri, 4 Feb 1994 15:26:37 -0500 (EST)

I would suggest to you that there are already the three levels that some
folks want.  There is the global configuration file, the individual
configuration file and there are the compilation options.  But the
individual ought to be able to override the global configuration on most
things.

One should remember that on most unix systems MUAs are user level programs
that don't require privilege.  With docile users (or in a rigid corporate
environment) you may be able to impose strict rules.  But in many places
anyone can bring in their own MUA and use it.  This means that
restrictions on the configuration of MUAs better have good rationales and
that the global configuration is primarily to make it convenient for most
users to use the program without having to worry about the configuration.

/dan

Dan Schlitt                           School of Engineering Computer Systems
[email-masked]        City College of New York
(212)650-6760                         New York, NY 10031

---

From: Barry Landy <[email-masked]>
Date: Sat, 5 Feb 1994 18:51:34 +0000 (GMT)

True on many but not all systems. Some of us (and not just me!) run mail 
systems on restricted shell unix systems where the usrs do not have the 
freedom to install their own programs, and where we have to do a lot of 
work to keep them out of things we dont want them to have (shell busters 
like calling your own editor, for example).
 
Compilation options are fine when they exist, but if they dont we are 
down to hacking or nagging the developers.

---

From: Barry Cornelius <[email-masked]>
Date: Mon, 7 Feb 1994 12:56:02 +0000 (GMT)

> down to hacking or nagging the developers. 

One change to Pine that we would like is to prevent the user from setting
the user-domain and use-only-domain-name variables.  It is inappropriate
in our environment for users to change these.  If they do, they send out
messages that can't be replied to by the recipient. 

To use the terminology introduced above, I have "hacked" the code to 
give out a message if the user sets either of these variables.

I was going ask the Pine development team if they could add a compilation
option for this.  Or it could instead be done by the third configuration
file that others are suggesting.  This is the file that overrides the
user's settings of some variables. 

--
Barry Cornelius                            Durham (091 or +44 91) 374 4717
Information Technology Service,                IT Service Office: 374 2892
University of Durham, Durham.                                Fax: 374 3741
DH1 3LE, UK                           E-mail: [email-masked]

---

From: David L Miller <[email-masked]>
Date: Fri, 18 Feb 1994 17:19:40 -0800 (PST)

Gregory,

Sorry about the slow response!  We've got your first suggestion on our 
list of enhancements to consider.  Your second suggestion os not really 
doable though.  You can most certainly have spaces in the fullname part 
of the address.  Even your address has spaces in it...

--DLM

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing
4545 15th Ave NE, Seattle WA 98105, USA

On Thu, 27 Jan 1994, Gregory J. Atchity wrote:

> Thanks for listening.
> ---
> Greg Atchity ([email-masked] and [email-masked])
> Iowa State University and Ames Laboratory - USDOE
> 
>