Suggested enhancements for PCOak

This documents all enhancement suggestions that have been made since it became apparent that the PCElm source would become available, in late 1999. The lists are presented first as a one-line summary of each suggestion, with links to greater detail further on in the page.

Various people have contributed to this list: for brevity they are referred to by initials here, but a list matching initials to names is available. The same initials are used in both the buglist and wishlist pages.

Enhancements are listed by index number; these are sequentially assigned when new suggestions are received, so there is no implicit "order" in the list.

Items shown with an asterisk (*) have been partially implemented, but there is more to be done; the implemented and unimplemented parts are described separately.

The lists shown below are based on PCOak 0.2.1.

Suggestions made, but not yet implemented: summary list

Index Description   Suggested by
001 Proper documentation IF
003 Default directory for saved messages IF
004 Delete empty mailboxes/folders PC
005* Improve viewing/decoding MIME messages PC, MS, ST, PD
006* Improve flaky MIME decoding capabilities NJ, ST, JW
007 Improve MIME sending PC, ST
008 Better view of existing folders TW, IR, ST
009* Printing with summary header & margin TW
010 Configurable message forwarding ARG, TW, MS, IR, ST, BHK
011 Edit existing mail messages in situ MS
013 Filter out HTML-like <...> formatting PDa
016* Move through parts of multipart at will DGB, ST
017 Specify default choice for attachment "save"/"view" DGB, ST
019* Improved input editor PC, JW
020 Weed out obviously broken destination addresses RC
022 Better handling of multiparts, especially attachments IF, PC, ST
023 Removing decoded attachments from original message IF, PC, ST, MS, JW
024 Better support for 8-bit charsets MS, JW, ST, PD, BHK
025 Better support for viewing HTML IF
026 Address book functionality IF
027 Option to view complete raw message JW
028* Progress indicator when skipping large parts PC, JW
029 Optionally skip multipart sections when replying PC, ST
031 Optional no "Status" header addition/modification JW
032 Support "start at line x" for external editor BHK
033 Support "alternative" identities like Elm BHK
034 Support "tochars" indicator like Elm BHK
035 Support "pointnew" option like Elm BHK
036 Definable attribution lines for replying/forwarding BHK, PD, ST
037 Improved message sorting options C, BHK, ST
038 Direct option configuration within program BHK
043 Archive oldest messages when folders grow too large PD
044 Weed out duplicate recipients ST, PD
045 Optionally make SMTP envelope-From match "From" header ST
046 Better handing of multipart/digest and message/rfc822 DGB, BHK, ST
047 Specify screen mode to use, restore on exit PD
048 Perform sanity checking on attachment filenames ST
049 Better/configurable default "save" filenames (esp. for faxes) MS
050 External send/edit/return "filter" program(s) ST, IF, JW
052 Support "group" style addresses BHK
054 Proper word-wrapping for long q-p lines in replies PC
055 Improved wrapping in viewer MS
056 User-defined prologue/epilogue for printing ST
057 External program to print messages ST
059 X-PCOak-Subject header for edited subject, shown by preference MS
061 Check file contents *while* encoding; warn if poor encoding MS
063 4-way choice for automatic mp/alt handling ST
064 Rethink all prompting to be more instinctive MS
067 Key (Esc?) to halt loading (long) mailbox MS
069 Re-enable lock files when accessing mailboxes BHK
070 Remove builtin editor, ship TED instead PD, ST, IF
073* Compact MIME/Tagged/etc. display in index, extend size MS, ST
074 Specify user (and read <user>.rc) on command line PD
075 Use global pcoak.cfg and "differences only" <user>.rc files PD
076 Run external program between editing and sending JS
077 Forward all tagged files, not just current one PC
079 Include attachments with [...] in message body DN
082 Handle more than 1 uuencoded item in a message ST
083 Base default save name on recipient if you are the sender ST
084 Use "----message/rfc822 part n---" separators for digest PC
086 Stop using Esc to dismiss viewer prompts IF, ST
089 Allow > 1 line per index entry, for long subjects IF
091 Save screen on entry, restore on exit PD
092* Handle =?iso-8859-1?q?"encoded-word"?= (RFC 2047) in headers ST
093 Scan HTML for mention of VBS, which may mean a virus MS
094 Support "blacklist" of file extensions to warn about MS
095* Make compliant with RFC 2822, as far as possible ST, BHK
099 Save last sent address, recall with F3 at "To" prompts MS
100 Don't keep saving attachments when moving through with Return MS
101 Permit user-configurable "Status:" header field name ST, MS, IF
103 Automatically keep backup copy of previous mail text BL
105 Option to reply without quote characters MS
106 Ctrl+Fn keys to run user-defined programs on message parts IF
107 Mark section(s) of viewer text and run program on marked bits IF
109 Optionally write non-blank Bcc: in saved copies of sent mail ST
110 Optionally sort messages older than days as sent today MS
111 Use better locally-sent mail test for "From" line in index PD, ST
112 Bookmark viewer position to allow return after sending mail PD
114 Save message/body-part text with decoding / wrapping PDa, IF, MS
116 User-definable keystroke macros with hotkeys ST
119 Reply attribution should include message date BL
120 Use some relevant date for messages with no "Date:" field PD
121 Run-time toggling of sort options PD, ST, BHK
122 Search all messages (not just subjects) from index screen PD
123 HOME and END keys in pager to move to top and bottom of message IF
125 Improved editing of multiple addresses on "To:" line etc. ST
126 Store pre-parsed header info in X-PCOak-* header fields ST
127 Make mailbox-indexing progress indicator optional IS
129 User-tunable buffer sizes for file reading/copying PD
131 Configurable key mapping ST
133 List domains which should always be sent via the smarthost ST
134 Configurable index entry layout ST
135 Display free memory on index page PD
136 "Save as draft" facility PD
137 Option to see sender's address at index screen DGB, IF
138 Option to change .RC settings as you change mailboxes PD
139 Option to use sender-initial-quoting (e.g. "LT> ") LT
140 Don't require <CR> when choosing options from list IR
141 Use RFC 2047 encoded-words in headers containing binary chars ST
143 Option to save read mail to =received when leaving mailbox IF
144 Option to prompt for Bcc: recipients IF, ST
145 Options to disable incomplete mailbox reading warning LT, ST

Suggestions that have already been implemented: summary list

Index Description   Suggested by
Implemented in PCOak 0.2.1 (27 Mar 2006)
072 Include more characters in Subject display MS
078 Say "Folder=" instead of "Mailbox=" when viewing folders DN
092* Handle =?iso-8859-1?q?"encoded-word"?= (RFC 2047) in headers ST
117 Track mailbox changes better ST
124 Optional / before year on index page display PD
130 Support year 0102 etc. and missing time in "Date:" fields IR, ST
132 Togglable 'long subject' view on index page IF
142 Make box-drawing characters user-configurable PD
 
Implemented in PCOak 0.2 (14 Nov 2003)
128 Report detected file types more usefully ST
 
Implemented in PCOak 0.1.1 (10 Apr 2002)
009* Printing with summary header & margin TW
014 Proper timezone info. in the Date: header ST, BHK
019* Improved input editor PC, JW
030 Easier to exit pager at end of multipart message PC
039 More flexible header weeding options BHK, ST, IF
040 Wildcard matches for header weeding LT
042 Remove dependency on external PCELM.MSG file PD
053 Save screen mode on shelling out/restore later PD
058 Option to stop moving into next msg when pressing 'd' in viewer BHK
060 Better content checking & default encoding for Transmitted files MS
065 Allow UpArrow/PageUp/Again etc. when at multipart prompts MS
066 Omit "Lines" header completely MS, ST, PD
068 Override "program" for prompt after decoding (skip if null?) PD
071 Improve Date display; show year, not time, for old messages ST, PD
072* Include more characters in Subject display MS
073* Compact MIME/Tagged/etc. display in index, extend size MS, ST
080 Allow \ in file paths in .RC file IF, MS
081 Improve critical error handling MS
085 Allow message/rfc2822 MIME type, like message/rfc822 ST
087 Remove prompt after returning from a shell IF
088 Make prompting after running command configurable ST
090 Display text/plain with 8bit encoding automatically ST
095* Make compliant with RFC 2822, as far as possible ST, BHK
096 Improve "Append, replace, type again or exit?" prompt MS
097 When saving, report whether appending to or creating a folder ST
098 Ask whether or not to create new folders BHK
102 Optionally confirm Abort when sending mail BL
104 Allow shelling out from within pager IF
108 Allow user's address to be defined separately from "USER" ST
113 Use 'e' to quit pager and start up external pager on message IF
115 Option for 'n' in pager to read next unread message directly PC
118 Base64 encoded lines should be longer PD
 
Implemented in PCOak 0.1 (17 May 2001)
028* Progress indicator when skipping large parts PC, JW
041 Default to viewing message/delivery-status as text BHK
062 Don't use y_n() for mp/alt skipping (CR/Esc instead) MS, IF
 
Implemented in PCOak 0.0.9 (20 Oct 2000)
002 Improve free mem when shelled out IF, JW, ...
005* Improve viewing/decoding MIME messages PC, MS, ST, PD
006* Improve flaky MIME decoding capabilities NJ, ST, JW
012 Configurable smarthost sending ST
015 Improve long line wrapping in pager ST
016* Move through parts of multipart at will DGB, ST
018 View message with full headers (toggle weedout) ST
021 Remove all references to Demon JW
051 Support multiple Reply-To recipients properly BHK, RR

Details of suggestions

Not yet implemented:

001: Proper documentation (IF)

Need a plan for future documentation.

There is a sort-of plan, but so far not much has been done

003: Default directory for saved messages (IF)

It would be v useful to be able to declare a default directory for saved messages.

Sounds sensible to me

004: Delete empty mailboxes/folders (PC)

Delete empty mailboxes and folders, when exiting or having moved/deleted all items from the mailbox/folder.

Sounds reasonable, although it must be optional and configurable

005*: Improve viewing/decoding MIME messages (PC, MS, ST, PD)

The first one may be worth leaving until a DJGPP version is compiled, which will give LFN support for free; I'm moving away from the second point, since it would be a lot of work for little benefit. Let me know if you disagree!

006*: Improve flaky MIME decoding capabilities (NJ, ST, JW)

Can anybody provide more details? Is it known which ones cause problems? Examples would help! (This may have been fixed in PCOak 0.0.9, which has better code for recognising the start of uuencoded sections.)

007: Improve MIME sending (PC, ST)

The current plan is for a message to have an optional list of attachments, which can be set up by the user; there will be a single (optional) text part, which is edited in the usual way, and then a MIME multipart/mixed message will be constructed (comprising the text and all attachments) when the message is finally sent; if the user *really* wants to edit the complete message, with all its MIME entities etc., it can be edited in the outgoing queue once PCOak has finished with it

008: Better view of existing folders (TW, IR, ST)

When creating or changing to subdirectories, show all existing sub-directories in a scrolling list; proper support for multi-level hierarchical folders.

Definitely needed. It may be possible to adapt Dave Scott's command-line history code (which will be borrowed for PCOak anyway) to provide the functionality

009*: Printing with summary header & margin(TW)

Print without full header but with From, Date: Subject: and To: lines and with a left margin.

The extended header weeding options in 0.1.1 provide the ability to print with summary headers (see 009* in the "implemented" list below); adding a margin still needs doing

010: Configurable message forwarding (ARG, TW, MS, IR, ST, BHK)

Configure whether to use (a) begin/end lines with no quoting, or (b) initial quotes ("> ") on each line (the current behaviour) when forwarding a message to someone; also configure whether to quote headers.

This would be useful; another option is to forward the message as a MIME message/rfc822 entity

011: Edit existing mail messages in situ (MS)

Controversial, but it would be nice to he able to edit Subject: headers to better reflect the message's content; or, indeed, be able to edit the mail body to leave only the gist of a long message.

Not really convinced about this one; Michael's later suggestion of the extra "X-PCOak-*" headers (059) is perhaps better. If desired, it could be achieved by the proposed send/return filtering mechanism (050)

013: Filter out HTML-like <...> formatting (PDa)

Remove HTML-like <param>...</param> formatting from messages for display. [This is actually MIME text/enriched format. -ST]

PCOak needs the ability to render text/enriched in order to meet minimum MIME compliance standards, although it will be little more than stripping out the tags to leave the underlying text. This could also be used for rudimentary HTML tag-stripping

016*: Move through parts of multipart at will (DGB, ST)

Some way to move backwards and forwards through the parts of a message, rather than only being able to step through forwards: e.g. a dialog listing the available parts, with their types, allowing you to choose which part you want to view/extract etc. now - once you've finished, select "Done" (or hit Esc).

Minor improvment made (see 016* in the "implemented" list below), but needs doing properly. Allowing more keys to work at multipart prompts (065) will help as a stop-gap, but the whole way the pager handles multipart messages is going to be redone (see 022)

017: Specify default choice for attachment "save"/"view" (DGB, ST)

For non-binary content, make the default choice between exporting the data and viewing within pcelm a configurable option.

This is somewhat redundant with PCOak, which has a much better understanding of what constitutes "text" and whether something is an attachment or not; proper support for the MIME "Content-Disposition: inline" would help as well

019*: Improved input editor (PC, JW)

Improve the string handling on user input (sending/forwarding messages, specifying filenames etc.) from its current "push insert to create an extra character space for EACH character you are inserting..."; perhaps reuse the recent character handling additions to Snews, including history recall.

The broken Insert mode has been fixed in 0.1.1 (see 019* in the "implemented" list below); there may be a horizontally scrolling single-line editing system in the next release, and some of Dave Scott's command-line editing and history recall code is going to be borrowed from Snews in the long term

020: Weed out obviously broken destination addresses (RC)

You also need to decide when to reject valid addresses because they are unlikely to exist in reality... fred@local for example.

Good point. Haven't really done anything on this front yet 8-(

022: Better handling of multiparts, especially attachments (IF, PC, ST)

A method for indicating attachments without breaking up the flow of the text around them, and then permitting the user to process each attachment as he or she wishes, rather than having to deal with them every time the pager moves past the first line of the attachment.

The current plan is to indicate any attachments (as well as unviewed multipart/alternative sections etc.) with a line across the message at that point, noting the name and type of attachment; individual attachments can then be processed as the user sees fit, rather than having to deal with them every time the message is viewed. Perhaps they could be selected from a list, or directly from with the message display in the viewer?

023: Removing decoded attachments from original message (IF, PC, ST, MS, JW)

Have the ability to remove the encoded body of attachments from a message once they have been successfully decoded, optionally replacing the encoded text with a 1-line summary of the attachment, perhaps using a format like
    !<attachment: \path\foobar.doc size=xKB CRC=0x3487F0AD>!
Perhaps the Status line could be marked to indicate this has happened?

I already do this (or something very similar) by hand, and it's very useful; this is fairly high on my personal priority list. Allowing the user to define the format of the line, as well as whether to keep any lines of encoded text as "context" for the original attachment, seems sensible

024: Better support for 8-bit charsets (MS, JW, ST, PD, BHK)

Allow 8-bit characters which use ISO-8859-1 and Windows-1252 charsets to be displayed properly, perhaps using the same methods as Snews.

The Snews methods (Pete Disdale's chargen system, which works very well but only in DOS or Windows full-screen mode, backed up by Dave Scott's character substitution system for the current code page) work well, and should be fairly easy to slot in; the code page should be user-definable, as it can be tricky to detect under Windows

025: Better support for viewing HTML (IF)

Allow an external HTML viewer, to which any HTML message bits could be passed to. Ian Smith's offline Browse would be particularly useful as any links can be sent to an http script for collection. People wanting something more elaborate could use Arachne. (Possibly also consider a very rudimentary internal HTML stripper for very basic internal viewing.)

Both methods have their methods; there has been considerable support for piping the HTML to an external program, but some rudimentary HTML tag-stripping in PCOak would be nice. See also 013

026: Address book functionality (IF)

Some people using PcElm will be using the useful little PcElm Address book ... however now PcOak is open source, perhaps the address book facility could be incorporated into the main program.

Good idea, but at present not much thought has gone into this

027: Option to view complete raw message (JW)

An option to see the entire message as received, with no headers weeded out or any MIME processing.

Very good idea; needs to be togglable at the main index screen (perhaps with a "once-only" setting similar to Snews)

028*: Progress indicator when skipping large parts (PC, JW)

It would be useful to have a 'skipping....' message at the bottom as large sections skipped at first look like a hang! That is until you see the busy hard drive light. Ideally a rotating \|/- or a counter?

PCOak 0.1 displays "Skipping..." while it is skipping a section, but there's no counter or other progress indicator yet

029: Optionally skip multipart sections when replying (PC, ST)

Replying (quoting original) should on reading the file ask to skip each attachment/multipart section. Choice to remove/skip on reply is useful; quoted HTML back at someone shows them how big the message is!

It would be useful to be able to quote (a) none, (b) all, or (c) some (user's choice) when replying; and for those which are quoted, you need to be able to quote them directly with quote marks, or as a proper attachment in its own right (either MIME multipart, or perhaps uuencode)

031: Optional no "Status" header addition/modification (JW)

For reasons of not amending headers even the teensiest bit, I would probably want to slip in an option not to add that "Status: R" line that PcElm uses.

Agreed. Good idea

032: Support "start at line x" for external editor (BHK)

When using an external editor, can it be passed a second parameter to specify at which line it should be opened: this would be handy when using in "edit the whole shebang, including headers" mode, for those that have editors capable of this feat.

Should be easy to do; may tie in with the proposed user-configurable strings system alluded to in 036

033: Support "alternative" identities like Elm (BHK)

The "alternatives" keyword lists other identities under which one might send mail from other computers, and yet still allows it to be recognized as being from oneself, for relevant filing under the actual addressee.

This one sounds very useful; I might need this quite soon

034: Support "tochars" indicator like Elm (BHK)

The "tochars" keyword tags messages visibly under four circumstances: (1) Mail addressed to onself and no one else; (2) Mail addressed explicitly to oneself along with other recipients; (3) Mail addressed to multiple recipients, but with onself included only in the Cc: line; (4) Mail not addressed directly to oneself, which may include mailing list traffic.

A nice idea; should mean that you never accidentally reply to just the author, not realising that there were other recipients as well

035: Support "pointnew" option like Elm (BHK)

The "pointnew" feature is quite nice too, setting the initial view to point to the first unread message, rather than the start of the mailbox itself.

Another good idea from Elm

036: Definable attribution lines for replying/forwarding (BHK, PD, ST)

Add a user-definable attribution line; Elm has both an "attribution" keyword and a "fwdattribution" one, the latter being used when forwarding a mail.

This is definitely required; there's actually quite a lot of scope for having user-definable string contents in various places (see 032 above, for instance), so this may be part of a grander scheme

037: Improved message sorting options (CM, BHK, ST)

Options to sort by date sent, date received, name of sender, subject, any others?; all in forward or reverse, of course.

How would different sort options be ranked, when the main criterion is a dead heat? Sorting properly by date-and-time should be in 0.1.1, converting the times to UTC for sorting purposes so international exchanges get the correct order

038: Direct option configuration within program (BHK)

The (o)ptions menu of Elm allows one to select features, and have them written automatically to the elmrc file; a nice feature.

But perhaps only in a 32-bit version to avoid bloating the 16-bit program?

043: Archive oldest messages when folders grow too large (PD)

The ability to specify in the .rc a max mailbox size such that mail in folders that exceeded the limit would automatically spill into an archive (oldest first, of course); perhaps not completely automatically, but at the press of an "archive now" key after prompting.

Sounds a good idea; I wonder if multiple archive files would be needed, so that no archive file got too big to load?

044: Weed out duplicate recipients (ST, PD)

Check all recipient lists (To, Cc, Bcc) and remove any duplications, e.g. when replying to people who Cc the message to themselves.

Good idea; may get done as part of the recipient list handling rewrite

045: Optionally make SMTP envelope-From match "From" header (ST)

If you change the address on "From:" header line, optionally make the SMTP Return-Path address (the "envelope-From") match the new address.

Should this be a global .rc file option, or something that can be toggled on and off (perhaps with a once-only setting) from within the program?

046: Better handing of multipart/digest and message/rfc822 (DGB, BHK, ST)

MIME multipart/digest messages generally consist of multiple message/rfc822 entities; at present each new message in the digest causes a new prompt asking what to do with it, which isn't very good. Treating them all as a single block text would be better, but there should be an indication of where one message stops and the next one starts.

This will be sorted out when the pager's multipart handling gets rewritten (see 016 and 022 above); the digest will appear as a single block of text, with the individual messages separated by divider lines (see also 084 for a possible stop-gap solution)

047: Specify screen mode to use, restore on exit (PD)

Perhaps yet another thing for the wishlist might be an option to run PCOak in a .rc-defined screen mode as does GremNOS/tw? For example, a 'videomode nn' entry to switch to 43/50 lines 80/132 chars or whatever whilst PCOak is running.

Sounds a good idea; you might want a 43-line PCOak even if you normally use 25 lines, for example. Should be fairly easy to do

048: Perform sanity checking on attachment filenames (ST)

if you accept an illegal filename, it will try to use it. Most over-long filenames will work OK; but ones with an '=' in them, for instance, cannot be opened at all. Some sanity checking before it tries to use your chosen filename, with the opportunity to correct it, would be a good start.

Checking a file name for legality should be easy; see also 092 for one source of illegal filenames

049: Better/configurable default "save" filenames (esp. for faxes) (MS)

(DFAX) ... the filename offered is of the form FAX=+442071234567-1234567890.tif. It would be nice if, for this particular case (filename beginning FAX=+), an 8.3 name could be offered; perhaps a more general system could be used? Perhaps taking the form
    Original file name is "A.long-file name.xyz.html"
    Save as ALONGFI7.HTM (this to be editable)

I don't want to bloat PCOak with too many specific conversion rules; the current plan is to allow the use of an external program which suggests short names to use, given the long form: this could be as simple or as complex as desired, with a simple one being supplied by default

050: External send/edit/return "filter" program(s) (ST, IF, JW)

Some people wish to modify stored mail messages; a good way of doing this would be a facility to save a message to a file, run some external program on said file to do something unspeakable to the message, then (if the file has been changed) reintegrate the result into the mailbox in place of the original message. One could even provide a set of configurable hot-keys to run various different processes; perhaps you could have separate files for different parts of a message (header, body etc.)

This is appealing as a generic solution to various different problems; I think it could turn out to be very useful, if perhaps dangerous if not used carefully

052: Support "group" style addresses (BHK)

PCOak makes no attempt to handle the RFC 822 "group" form of address (e.g. Them: him, her, that.lot;), but it should do.

Agreed; PCOak expects all addresses to be in "mailbox" form, which isn't really good enough

054: Proper word-wrapping for long q-p lines in replies (PC)

Replying to a quoted-printable message with long lines, PCOak uses the q-p "soft" line breaks to break the lines for reply; this may work well if the q-p breaks are at word boundaries, but looks awful if not.

It really needs to reformat long single-line q-p paragraphs properly, with word wrapping, before quoting the text for a reply

055: Improved wrapping in viewer (MS)

The viewer wraps lines at the 80th column regardless; it would be much easier to read if the lines wrapped at word boundaries.

Agreed; should be fairly easy to achieve

056: User-defined prologue/epilogue for printing (ST)

To get the best from your printer, define strings of characters which should be sent to the printer before and after each print job (e.g. reset and set margins at the start, end with eject page etc.)

Straightforward

057: External program to print messages (ST)

Allow the use of a favourite "pretty printing" program for printing messages; PCOak could create a file containing the message, then call the user's defined external printing program.

I think it's worthwhile, but does anyone else?

059: X-PCOak-Subject header for edited subject, shown by preference (MS)

It would be very useful to edit the Subject or add a new header to the mail after it has been received (PCOak-Subject? X-Subject?). In the one-line-per-message summary, PCOak would then display the beginning of the PCOak-Subject ine if present, else the beginning of the existing Subject - if no new subjects are entered, the program will behave exactly as at present, so should not offend traditionalists. This will also help with long Subjects, where the important bit falls of the end of the line.

Nice idea; I'd suggest X-PCOak-Subject, which has scope to extend the X-PCOak-* scheme to other header fields in the future

061: Check file contents *while* encoding; warn if poor encoding (MS)

While encoding a file, check the input file and complain if it seems to be the wrong encoding for the type of file.

Interesting idea; for the long term, though

063: 4-way choice for automatic mp/alt handling (ST)

When presenting extra multipart/alternative sections to the user; have a four-way configurable choice of what to do: 0 = always show them; 1 = ask whether to show them (default yes); 2 = ask whether to show them (default no); 3 = don't show them at all.

Events may have overtaken this somewhat; the 0.1 system is much more RFC-compliant, in that it defaults to ignoring the alternatives unless the user chooses to view them, and I don't really want to have to put in a load of different prompts. When the pager multipart system is redone, this will all be water under the bridge anyway

064: Rethink all prompting to be more instinctive (MS)

Yes/No prompts are bad; avoid asking the question that way, but use things like Save, Cancel, Delete? instead.

Certainly the current prompting system leaves a lot to be desired, and could be improved; this is good food for thought

067: Key (Esc?) to halt loading (long) mailbox (MS)

Loading a large mailbox takes a noticeable time. It's not possible to stop this, as far as I know (e.g., pressing ESC). It would be useful to be able to escape, either after choosing this mailbox in error, or if intending to change immediately to view the contents of a different mailbox.

Good idea! Esc is the obvious choice; pressing Esc while loading a mailbox could abort loading that file, and instead present an empty "null" mailbox, ready for the user to move to another one etc.

069: Re-enable lock files when accessing mailboxes (BHK)

PCTree doesn't use lock files when accessing the original mailbox; once upon a time it was evidently supposed to use them, but somebody took it upon themselves to disable this. This might cause problems if new mail arrives while PCTree is rewriting the file...

I'll try re-enabling the dormant support for lock files in PCOak, and see if it works properly

070: Remove builtin editor, ship TED instead (PD, ST, IF)

Does anyone use the built-in editor? I'd actually quite like to remove it altogether, and save some memory. It's badly broken, and will crash PCOak at times! [Nobody seems to use it.] We could ship Ted/SuperTed instead as a default external editor, if the user doesn't already have one...

Removing the internal editor would be nice; PCOak could still have a lowest-level line input editor, so that users with no editor at all could at least enter mail messages line-by-line

073*: Compact MIME/Tagged/etc. display in index, extend size (MS, ST)

The current system is certainly wasteful; you can't sensibly have a message which is both New and Deleted, for example, so they could occupy the same space. Tagging could probably be indicated differently, too.

0.1.1 has changed the way that tagged messages are displayed (see 073* in the "implemented" list below), but after trying having the New and Deleted flags using the same column, I no longer think this is a good idea (it gets too difficult to see which messages you've processed and deleted, and which ones are still new); I'm sure there's still more than can be done, though. Suggestions?

074: Specify user (and read <user>.rc) on command line (PD)

Howsabout being able to specify the user on the commandline instead? For example: pcoak [-pete] [...] or pcoak [/user:pete] [...]

Useful idea, to get rid of the ghastly DIS system of copying <user>.rc to pcelm.rc to change user; Pete suggested that it could tie in with an environment variable, e.g. invoking PCOak with pcoak -U%mailbox%

075: Use global pcoak.cfg and "differences only" <user>.rc files (PD)

IMHO we already have more "config" files than sticks to shake at them. Perhaps in the fullness of time the present pcoak.rc could become a pcoak.cfg (containing system-wide defaults/settings) and individual {mailuser}.rc files containing *only* the personalised settings?

A nice idea, but (as noted by Pete) a serious deviation from the PCElm way of doing things; whether this is a Good Thing or a Bad Thing is open to debate, but it could save a lot of config file maintenance time

076: Run external program between editing and sending (JS)

Re SigSeps : it could be optional to run a named program, or list thereof, on the file after editing but before posting. A program to ensure that the last occurrence of a "--" / "-- " line would, if "--", be upgraded should be easy enough. That flexibility could enable spell-checking, sending copies to printer, etc.

One for the long term, perhaps, but a good idea nonetheless

077: Forward all tagged files, not just current one (PC)

The problem was forwarding multiple messages, requires saves and read in on insert, as I needed several copies to forward to the postmaster in question. Wish list item is to forward all tagged messages, if possible.

Sounds good

079: Include attachments with [...] in message body (DN)

In a message can I do:
    [include <filename> text/plain base64]
 to include a file in the message?

This is apparently something that Elm does; I'll look into it further, although instinctively I don't like the idea very much

082: Handle more than 1 uuencoded item in a message (ST)

The viewer exits after decoding the first uuencoded section; why?

"Because", I suspect; there are plenty of messages generated with multiple uuencoded attachments, so this needs to be fixed. It may get sorted out as part of the great pager multipart rewrite

083: Base default save name on recipient if you are the sender (ST)

When saving a message, e.g. from the SENT folder, the default save name should be based on the first recipient if you are the sender, as it is for "saveall 2"; being offered your own name as a default isn't much help.

I agree; but then I would, wouldn't I?

084: Use "----message/rfc822 part n---" separators for digest (PC)

Digests of message/rfc822 messages are awkward to read because of the prompting; a separator line "----message/rfc822 part n---" would probably be enough if they were all in a single scrolling list.

Good stop-gap until the big multipart pager rewrite

086: Stop using Esc to dismiss viewer prompts (IF, ST)

It certainly seems a waste to me to use Return/Space and Esc all for the same purpose.

Agreed; since Esc normally quits the pager, I feel it should do the same at a pager multipart prompt, instead of being a "carry on" key (see also 065)

089: Allow > 1 line per index entry, for long subjects (IF)

May I propose a third mode [of index page display] that has the message subjects wrapped to more than one line in some way. [This would make long subject lines easier to see.]

I can't see any particular reason not to do this at some stage

091: Save screen on entry, restore on exit (PD)

[The PCElm method for saving and restoring the screen when exiting the program never worked, and has been disabled in PCOak 0.1.] Something like a "restore_screen 0/1" .rc setting would allow the user to choose whether to have this or not.

Sounds good to me. That way nobody can accuse us of removing functionality (even though it didn't work in the first place!)

092: Handle =?iso-8859-1?q?"encoded-word"?= (RFC 2047) in headers (ST)

Handle the RFC 2047 encoded-word construct in headers; this is the =?iso-8859-1?q?this=20is=20a_strange_name?= construct, which if left alone produces illegal filenames (if nothing else). It's also found in some From and Subject lines.

0.2.1 features a basic and rather limited decoder for 'Q' encoded-words in From: and Subject: fields (see 092* in the "implemented" list), but proper support is needed as these are becoming more common

093: Scan HTML for mention of VBS, which may mean a virus (MS)

It's probably easy for PCOak to distinguish a likely script virus (Presence of "<SCRIPT language=VBScript>", HTML is much longer than otherwise expected, probable sequence of many blank lines, "</script>" occurs probably near the end of the HTML).

It may be worth considering this one special case, but personally I'd probably prefer a general solution for virus detection using an external scanner

094: Support "blacklist" of file extensions to warn about (MS)

Internally it would be dead easy to check the extension of attachments (before starting the extraction process), and warn if any on the blacklist are present. There are a large number of extensions which are unlikely to be used legitimately.

Nice idea

095*: Make compliant with RFC 2822, as far as possible (ST, BHK)

The long-awaited arrival of RFC 2822 changes a few things; things that should be addressed include:

All the above except the thread tracking have been implemented in 0.1.1 (see entry 095* in the "implemented" list below); further RFC 2822 compliance work will be done shortly

099: Save last sent address, recall with F3 at "To" prompts (MS)

Is there any way to pick up the address from the previous message? A list of the last (say) 10 messages is relatively unimportant, but the last _one_ is very useful given that one often needs to send a file and its description as separate messages.

Excellent idea

100: Don't keep saving attachments when moving through with Return (MS)

When skimming rapidly through a message with attachments (e.g., one that's already been extracted, but is still in the mailbox), if you just press Enter repeatedly to go though as quickly as possible you end up saving the attachment(s) again I know not where.

The current suggestion, in the short term, is to change the
    Multipart message - more to come. Hit return or ESC to continue
prompt to allow a default action of skipping the attachment, without having to deal with the big multimedia options dialog; something like
    base64 item (application/octet-stream) next: ESC/ret/spc=skip, o=options

101: Permit user-configurable "Status:" header field name (ST, MS, IF)

After problems with users being sent mail containing "Status: RO" header lines, it was suggested that allowing users to change the header field name used by PCOak to store its status information might be useful.

It's not a bad idea, but the best solution is to ensure that the incoming mail doesn't have this spurious header lines, perhaps by prepending > in time-honoured fashion

103: Automatically keep backup copy of previous mail text (BL)

Could there be a back-up file for the currently being composed message, which is not deleted on abandoning/aborting the message but can happily be overwritten when you start to compose the next message?

Good idea; it didn't quite make it into 0.1.1, but it will be done ASAP

105: Option to reply without quote characters (MS)

I'd very much like an option to reply either with or without quote characters, as required; maybe it's already there and I haven't found it?

Sounds a reasonable idea to me

106: Ctrl+Fn keys to run user-defined programs on message parts (IF)

With the Rat-Wash Snews we now have all the useful Ctrl+Fx shells in addition to the regular "!" shell. They can run external programs on
    %f (whole article)
    %b (body only)
    %h (header only)
Wouldnt that be a good thing in the PcOak viewer? Rather a long way in the future probably.

A very nice idea indeed; I use it a lot in Snews. See also 116

107: Mark section(s) of viewer text and run program on marked bits (IF)

[In the context of 106] In addition an ability to mark sections of text in the viewer and run the external program just on the marked bits (say %m) would be a great timesaver.

I can see how this would be useful, but I feel there are bigger fish to fry before getting into selecting sections of text from the viewer; it will almost certainly have to wait until after The Great Pager Rewrite

109: Optionally write non-blank Bcc: in saved copies of sent mail (ST)

Saved copies of sent mail are just the 1234.TXT file from the mail queue; Bcc: lines are not part of that file and so don't get saved. It would be nice to have the option of adding a non-blank Bcc: field to the saved copy, for completeness.

I'd find this useful; don't know about anyone else

110: Optionally sort messages older than days as sent today (MS)

(a) For every message in every mailbox or folder it ever opens, PCOak should parse the "Date:" header field to find out the message's apparent sending date; (b) if said date is more than than N days before the current time, PCOak should henceforth ignore that date - regardless of the fact that in 99.9% of cases it will be perfectly correct - and should use today's date instead.

After a long discussion about this idea in demon.ip.support.pc, I still don't understand how it would help; I think this is an unlikely one to get done in the near future

111: Use better locally-sent mail test for "From" line in index (PD, ST)

PCTree detects mail sent by the current user and shows it as "To: user@host..." on the index screen rather than showing your full name; while this is useful, its detection of which messages were sent by the current user is very simplistic. There are two obvious improvements: (a) match on several alternative "me" addresses (I believe Elm does something like this, although in a different context), and (b) regard any message which doesn't have any "Received:" header fields as a locally-originated one which may be handled differently, but regard any message with even one "Received:" field as an external one which should display the author regardless of whether it appears to have been sent by you. Pete favours (b).

A reasonable request, but there are more pressing things to work on

112: Bookmark viewer position to allow return after sending mail (PD)

[Discussing Ian's desire not to leave the pager when sending mail] How about a sort of temporary "bookmark" in the message being read, so that after carrying out whatever, one is returned to the appropriate place in the viewer?

Nice idea; needs to wait for The Great Pager Rewrite

114: Save message/body-part text with decoding / wrapping (PDa, IF, MS)

What I am looking for is a way to get PCELM to export plain text files as they display on the screen.

The current suggested system is to have an "export" function, which treats the message body (or current MIME body part if a MIME multipart message) as an attachment and writes it to a file of your choice

116: User-definable keystroke macros with hotkeys (ST)

Allow the user to define macros of keystrokes to be simulated, with a hotkey method of running them: e.g. 's=junk' bound to F11 to forcibly save a message to folder =junk; this could be expanded in future to encompass the Ctrl+Fn keys of item 106.

Anyone else think this is a good idea?

119: Reply attribution should include message date (BL)

Something like
    In message <12345@domain.invalid> of Mon, 18 Mar 2002 08:32
      user@domain.invalid (A User) writes:
would be very helpful.

Agreed; until the definable attribution lines of item 036 are realised, this would be a useful stop-gap

120: Use some relevant date for messages with no "Date:" field (PD)

Messages with no "Date:" header field get sorted at the end of the list; it would be better if they had a date representative of when they were received.

Agreed; the obvious thing would be to parse a date from the other header fields (e.g. "Received:")

121: Run-time toggling of sort options (PD, ST)

It would be useful if both 'sortdirection' and 'sortby' could be toggled while the program was running, rather than having to exit and edit the .RC file.

Definitely; I would find this useful

122: Search all messages (not just subjects) from index screen (PD)

Can I suggest a search command to search an *entire* mailbox? More often than not I can remember a word or abbrev of some sort that I've used/seen in correspondence, but not for the life of me which message it was in :-(

This would indeed be useful, although personally I tend to grep the folders outside PCOak

123: HOME and END keys in pager to move to top and bottom of message (IF)

The viewer could definitely do with HOME and END commands to move to the top or bottom of the message. There is 'a' which serves as HOME but nothing serves as END.

HOME is trivial, and will be done; END is less so, because of the way the pager renders the text (wrapping as it goes) as it's moving through the message. This is one of the problems with the current pager design; it may be easier to leave the END stuff until after/during The Grand Pager Rewrite

125: Improved editing of multiple addresses on "To:" line etc. (ST)

For editing long address lists, the ability to fold a long line on to multiple lines and fire up the normal editor, then unfold it after editing, would be useful. Maybe Alt-E or something?

This would undoubtedly be useful, but there are bigger fish to fry

126: Store pre-parsed header info in X-PCOak-* header fields (ST)

For slow machines, it might be useful to add special "PCOak only" lines to the header of each message, containing things like pre-parsed timestamps etc.; these lines ("X-PCOak-Date:" or similar) could be read quickly, avoiding the need to call time-consuming parsers for the "real" header fields.

This could provide real speed benefits on slow machines, although I doubt those with faster systems would notice any improvement

127: Make mailbox-indexing progress indicator optional (IS)

The running count display of mail items indexed can be expensive in speed terms on some displays. For one OLIM user with a weird CGA screen it almost tripled the index time :( V-I users might also find it a pain as well.

A very good point; this will be included when the file handling rewrite is completed

129: User-tunable buffer sizes for file reading/copying (PD)

It would be nice if the buffer sizes used for reading and writing files could be tuned by the user.

Very good idea; this will be part of the file handling rewrite

131: Configurable key mapping (ST)

Different people are used to different key combinations for editing actions in particular, e.g. Ctrl-Y and Ctrl-U. It would be nice if PCOak keystrokes could be user-definable, like 'less' or Dave Scott's SNews system.

This would obviously be useful, but is probably a long-term goal

133: List domains which should always be sent via the smarthost (ST)

With AOL insisting on people sending via ISP smarthosts, it would be useful to have a list of domains which should *always* be sent via the smarthost (if configured), regardless of the "smarthost" setting or the number of destinations domains for the message.

Fortunately AOL have enabled Demon users to register for direct sending, but there will no doubt come a time when this becomes necessary

134: Configurable index entry layout (ST)

The format of the message line in the index display should be user-controllable; and allowing multiple formats which can be switched between would provide great flexibility. Also, things like allowing the size to be displayed as bytes/K/M/G, which allows you to guarantee that it will only ever be 4 characters long (e.g. 996, 47K, 2.2M), would be useful.

The "long-subject" version of 0.2.1 helps with displaying more of the subject, but proper user control would be the best option

135: Display free memory on index page (PD)

A "free memory" display somewhere on the index page (a la Snews) would be useful.

Agreed; but it needs to be optional

136: "Save as draft" facility (PD)

Something that I would find particularly useful is a "save as draft" facility. That's to say, when one is midway through a long email/reply, the ability to save the work so far, and to pick it up later where one left off. Perhaps there could be an extra option to the "send/edit/abort?" prompt where the composition to date could be saved to a file in '=suspense' or '=work' folder, and at some future time be resumed. And of course, when finally completed and posted, be deleted from this 'pending' area.

Nice idea; being able to suspend a reply-in-progress to read newly-arrived mail, for instance, would be a useful facility

137: Option to see sender's address at index screen (DGB, IF)

The usual email listing gives the sender's identity, rather than the email address. KA9Q's mailkill works on the SMTP address. It would be handy if I could see the email address, or the SMTP-envelope address, as easily.

Nice idea: the obvious thing would be to show the entire "From:" field contents verbatim, perhaps using the right-arrow key in a similar way to the long-subject version of 0.2.1

138: Option to change .RC settings as you change mailboxes (PD)

Have a {user}.rc for each "user" which contains the settings one would like to use for that persona (not to be confused with the {user}.rc that DIS uses for switching users, which I don't use and which only happens at PCTree startup). When switching mailboxes inside PCOak the new .rc settings would be loaded automatically for the new user, with a fallback to PCOAK.RC/PCELM.RC if no such {newuser}.rc is available.

Good plan: it would be a fully viable alternative to the old DIS way of exiting PCTree, copying a different .RC file, then restarting it

139: Option to use sender-initial-quoting (e.g. "LT> ") (LT)

I seem to remember some talk of using initials to mark quoted text, like LT> for example.

It's certainly possible, but that quoting style seems to have fallen out of favour; it may not be worth the extra code required

140: Don't require <CR> when choosing options from list (IR)

On opening a message in html or some other ghastly non-plaintext format, and selecting from the 3 options - read with your viewer, skip or decode, I always expect the keypress 1 2 or 3 to initiate the action, instead of having to follow up with ENTER. Most other programs I use don't wait for the ENTER after choosing an option like this.

Fair point; there are many other parts that just take single keypresses for prompts, which would doubtless work better

141: Use RFC 2047 encoded-words in headers containing binary chars (ST)

If binary characters (pound signs etc.) are found in outgoing mail header fields, they should be wrapped up in RFC 2047 encoded-word format to convert them to 7-bit representation - at present it just generates 8-bit mail, which is a Bad Thing.

This is already done for the message body (automatic conversion to quoted-printable if binary characters are found), so doing the same for header text seems only sensible; it should probably be optional, though

143: Option to save read mail to =received when leaving mailbox (IF)

[Elm and Mutt by default like to save read messages from your "mailbox" (your mail spool file) to your '=received' folder when you leave the mailbox, so that it only contains unread mail (they ask first, unless told not to); PCTree has never had this behaviour.] I rather like to sound of that. If it was in Oak, it would mean that boxes containing new mail would load very much faster, saving lots of time every day.

Good idea; it would be easy to do and could be useful to some people, so why not?

144: Option to prompt for Bcc: recipients (IF, ST)

Why doesnt Tree have Bcc: ? Its useful if you want to keep your recipient list confidential. As things are, there wouldnt be anywhere to put it. I suppose you could get a Bcc: dialogue to pop up by pressing Alt-B after youve done the Cc: entries.

You can add them directly to the header when re-editing the message, but that's hardly nice; there should be a way to allow prompting for Bcc: as well as To: and Cc:

145: Options to disable incomplete mailbox reading warning (LT, ST)

When loading the mailbox file, I got an error message "Didn't read all of file, close and restart". After a bit of head-scratching (because it _had_ read all the file), I realised that it was picking up a control-Z.

This checking was new in 0.2.1; it should (a) give a more informative report, and (b) allow the warning to be disabled (e.g. '0' disables it completely, '1' warns only if more than one byte was missed, and '2' (the default) warns if the byte count didn't agree exactly)

The following suggestions have been implemented in PCOak 0.2.1

072: Include more characters in Subject display (MS)

By the way, I personally would include a few more characters into the Subject: line, by cramping the display a bit. ...
    MN123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
    !*123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
    +123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
instead of
    M N 123 Concorde International Plc 15 Feb 19:181234567 I love you.VBS etc.

Some changes were made in 0.1.1 (see 072*); 0.2.1 has a special "long-subject" build available (see 132 below) which now allows the subject line to be extended over most other parts of the display

078: Say "Folder=" instead of "Mailbox=" when viewing folders (DN)

... I think that I should be seeing the SENT folder, yet your top status line show "Mailbox =sent". It would be less confusing if it read "Folder =sent" would it not.

Implemented; highlighting the difference between reading a spool-level mailbox file (which implicitly ends with .txt) and a user-level folder (which doesn't) seemed like a good idea to me

092*: Handle =?iso-8859-1?q?"encoded-word"?= (RFC 2047) in headers (ST)

Handle the RFC 2047 encoded-word construct in headers; this is the =?iso-8859-1?q?this=20is=20a_strange_name?= construct, which if left alone produces illegal filenames (if nothing else). It's also found in some international From and Subject lines.

Pete Disdale's basic "iso-killer" (From: and Subject: fields only, 'Q' encoding only, doesn't handle folded fields) is in 0.2.1, toggled on and off with the '=' command (initial setting via the new mimehdrdecode .rc file entry); further improvements to come

117: Track mailbox changes better (ST)

Keep track of mailbox changes better: e.g. deleting a message then undeleting it should not flag the mailbox as changed, since effectively the change has been undone. This is annoying when saving a message with "autodel 1", and then undeleting the message; the mailbox should not be re-saved!

Now implemented; saves quite a bit of unnecessary file saving, at least with my way of working

124: Optional / before year on index page display (PD)

Having a '/' ahead of the year in the index display would be more pleasing to the eye than a space.

Although the current style mimics UN*X 'ls -l' output, which is what my brain expects to see, the user can now choose the separator character with the new yeardispsep .rc file entry

130: Support year 0102 etc. and missing time in "Date:" fields (ST, IR)

Mail sometimes arrives with years like 0102, or with the date but not the time, which makes the date parsing code give up altogether; while such broken formats are not RFC-compliant, it would be nice if the date parsing code could deal with them.

Now done

132: Togglable 'long subject' view on index page (IF)

Posts there (yahoogroups) are always prefixed by the name of the group, e.g. [Blah, blah, discuss] and this leaves very little space on PcOak's message listing to work out what the real subject of the message is. I was wondering whether it would be easy to have a toggle key to switch between PcOak's normal listing and a listing that consists only of subject lines (with Status characters like M, D and N).

Pete implemented a 'special' version of 0.1.1 for Ian, with longer subjects being stored and the left- and right-arrow keys extending and contracting the subject display in three stages; this system is now available in the "long-subject" version of 0.2.1 (0.2.1-L), with the new subjectsize .rc file entry specifying the initial setting. See also 072, which is related

142: Make box-drawing characters user-configurable (PD)

I use an iso-8859-1 screen font (loaded beforehand) and '\315' [the message-separator graphic character] looks really naff! Perhaps one could have a .rc entry like 'boxchars "..........."' containing the 11 box-drawing characters?

The new boxchars .rc file entry allows you to specify the 12 graphics characters used (11 for boxes and one for the message separator)

The following suggestions have been implemented in PCOak 0.2

128: Report detected file types more usefully (ST)

It would also be more helpful if the "choose the encoding" dialog was rather more specific about the detected file type, rather than "I think this is a (text|binary) file".

Now implemented, as part of improving Ctrl-Z handling

The following suggestions have been implemented in PCOak 0.1.1

009*: Printing with summary header & margin(TW)

Print without full header but with From, Date: Subject: and To: lines and with a left margin.

The extended header weeding options in 0.1.1 provide the ability to print with summary headers; you can't actually specify a list of headers specifically for printing use, but I suspect that using the same "summary" level for both screen display and printing will be adequate (does anyone disagree?); adding a margin still needs doing

014: Proper timezone info. in the Date: header (ST, BHK)

Proper timezone information in the Date: header, using the [G]TZ environment variable, rather than using local time but reporting the (fixed) timezone string from pcelm.rc.

This has now been done; the old zone .rc file entry is no longer used, and dates are now compliant with RFC 2822 (which supersedes RFC 822)

019*: Improved input editor (PC, JW)

Improve the string handling on user input (sending/forwarding messages, specifying filenames etc.) from its current "push insert to create an extra character space for EACH character you are inserting..."; perhaps reuse the recent character handling additions to Snews, including history recall.

PCOak 0.1.1 has a proper user-configurable insert mode, with insert/overwrite mode being indicated by different (again user-configurable) cursor sizes; there may be a horizontally scrolling single-line editing system in the next release, and some of Dave Scott's command-line editing and history recall code is going to be borrowed from Snews in the long term

030: Easier to exit pager at end of multipart message (PC)

At the end 'Command..(100%)', after pressing Return to continue after each message part, it doesn't get you out of the viewer; maybe handle space and return differently from page-down and down-arrow (configurable), or handle "return at 100%" differently if you've only just finished a multipart (in this case alone, quit the pager).

The new retendquit .rc file entry allows you to specify that pressing Return at the end of a message should quit the pager

039: More flexible header weeding options (BHK, ST, IF)

Have four levels of header viewing: none, summary, weeded and full. None means weed them all out, and don't show any headers at all; summary shows only those headers in the user's "summary" list; weeded only weeds out those in the user's "weedout" list; and full doesn't weed out anything, and displays full headers. Pressing 'h' in the pager could cycle round the four modes, always starting with your normal setting upon entry (default state could be changed with 'H' at the main prompt).

The header weeding system has been completely rewritten for 0.1.1, and now features the suggested four levels of weeding

040: Wildcard matches for header weeding (LT)

I tried setting weedout * but it didn't like that!

The new weeding system in 0.1.1 has three different "styles" of weedlist entry, specified by the weedstyle .rc file entry: (0) normal case-sensitive fixed strings; (1) case-insensitive fixed strings; and (2) case-insensitive wildcard matches, with patterns starting with ! meaning "don't match" to override matches due to other patterns

042: Remove dependency on external PCELM.MSG file (PD)

The external PCELM.MSG file is unmaintained and possibly dangerous, allowing users to change vital formatting strings; it would be better to have all strings embedded in the program, and provide user configuration and preferences in additional/alternative .rc entries.

The file is no longer used; all strings are compiled into the program. This saved several KB of memory in the running program

053: Save screen mode on shelling out/restore later (PD)

If some called program changes the screen mode while running under PCOak, it will mangle the screen and cursor handling in PCOak when the program returns; the screen parameters should be saved before calling external program, and restored on return if they have changed.

This is now done

058: Option to stop moving into next msg when pressing 'd' in viewer (BHK)

If I press 'd' for delete then I'd like the message to be marked as deleted, and return to the mailbox listing. If I want to read the next message, I can always press .

The viewdelread .rc file entry now enables you to turn this behaviour off

060: Better content checking & default encoding for Transmitted files (MS)

I would suggest that if a "transmitted" text file contains lines longer than, say, 75 characters it should default to some form of encoding (PCTree defaults to no encoding for text). The present system of deciding what type of encoding to apply to a transmitted file is lousy!

A considerably superior check for the type of a file, and therefore what encoding to suggest, is in 0.1.1

065: Allow UpArrow/PageUp/Again etc. when at multipart prompts (MS)

Getting stuck at a "Multipart message - more to come" message, and having to hit Return or Esc to get back to a normal prompt where you do something else, is infuriating!

All "bottom line" prompts in the pager now accept a variety of the "standard" keys in addition to the ones they used to accept; you can use up-arrow, s to save the message, ! to run a shell etc. Esc is still used as a "carry on" key, when it means "quit the pager" under other circumstances; this still needs be improved ASAP (see 086)

066: Omit "Lines" header completely (MS, ST, PD)

The Lines: header field is frequently wrong (e.g. it reports 0 when sending a base64-encoded file); it should be removed altogether, or corrected.

The Lines: header field is not a recognised mail header field in the first place (it's for Usenet posts), it appears in virtually no other MUAs, and is difficult to maintain correctly: it has been removed in 0.1.1

068: Override "program" for prompt after decoding (skip if null?) (PD)

The hard-wired "program" string for execution after decoding a miscellaneous file isn't very useful; it might be better not to allow the user to provide a default command, and not offer the command option if this is a null string.

Good idea; it allows people to retain the current system (specific viewers for .jpg, .gif etc. is defined, or "program" for evertything else), while also allowing users to choose to have no command prompts at all

071: Improve Date display; show year, not time, for old messages (ST, PD)

It would help if the displayed date on the index page showed year, rather than time, for old messages (say more than 6 months old, but could be configurable - Pete would like 12 months), similarly to the UN*X ls -l command.

0.1.1 has a yeardispage .rc file parameter which lets you define a time before the program's startup time (in days or months), before which messages are shown with year instead of time

072*: Include more characters in Subject display (MS)

By the way, I personally would include a few more characters into the Subject: line, by cramping the display a bit. ...
    MN123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
    !*123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
    +123 Concorde International Plc 15Fe 19:181234567 I love you.VBS etc.
instead of
    M N 123 Concorde International Plc 15 Feb 19:181234567 I love you.VBS etc.

0.1.1 has increased the size of subject display by reducing the size of author display and using the full screen width including the 80th column, as well as trying to ensure that large numbers don't mangle the display alignment; there's more to do, though

073*: Compact MIME/Tagged/etc. display in index, extend size (MS, ST)

The current system is certainly wasteful; you can't sensibly have a message which is both New and Deleted, for example, so they could occupy the same space. Tagging could probably be indicated differently, too.

0.1.1 indicates tagged messages with a + in between the message number and the author name, which releases one column from the left, but after trying having the New and Deleted flags using the same column, I no longer think this is a good idea (it gets too difficult to see which messages you've processed and deleted, and which ones are still new). I'm sure there's still more than can be done, though. Suggestions?

080: Allow \ in file paths in .RC file (IF, MS)

On setting a program (in the DIS front end) to handle JPEG files to E:\MVIEW\MVIEW.EXE, the program is invoked as E:MVIEWMVIEW; using double backslashes restores this to the way it should be.

0.1.1 no longer subjects .rc file entries which involve paths (directories and commands) to the \-escape parsing that previous versions used to (although they still get processed for quotes); this enables you to use backslashes in file paths. It should be noted that to do so breaks backwards compatibility of the .rc file with older versions

081: Improve critical error handling (MS)

When trying to save a .JPG enclosure to the wrong place (B:name.jpg), there are 20 unsuccessful attempts to save the file, with no way I can find to exit (ESC is ignored). Drive B: does exist, but there is no disc in it.

The critical error handler has been rewritten in 0.1.1 and should now work much better

085: Allow message/rfc2822 MIME type, like message/rfc822 (ST)

No doubt we will, at some stage, have updated MIME RFCs which add the new type "message/rfc2822", but probably not for a while yet. (I might stick support in for it anyway, just in case some "clever" software out there decides it knows better than RFC 2046 and starts using a MIME type which doesn't actually exist.)

Done

087: Remove prompt after returning from a shell (IF)

I never did understand why you get a prompt before you exit the shell. I think Ive seen it a couple of times with other programs but its most unusual. It seems an entirely pointless delay to me.

0.1.1 no longer prompts you after returning from a shell, although it still does so if you run a program rather than shelling out; however this may be avoided by using the system described in 088 below

088: Make prompting after running command configurable (ST)

Following on from 087 above, it should perhaps be configurable whether to prompt for a key when simply running a program under PCOak.

By putting the special character * at the start of a command, you can inhibit any prompt that would have appeared after the command finishes; the * is removed before running the command. Note that if this is done to .rc file entries like multimedia, the file will not be backwards compatible with older versions

090: Display text/plain with 8bit encoding automatically (ST)

Plain text, encoded with the MIME 8bit encoding, isn't displayed as text by default (you get prompted for what to do); with more and more of it about these days, it should just be displayed

Done

095*: Make compliant with RFC 2822, as far as possible (ST, BHK)

The long-awaited arrival of RFC 2822 changes a few things; things that should be addressed include:

All the above except the thread tracking have been implemented in 0.1.1, including checking all message bodies for lines with more than 78 characters in them, with such messages being auto-encoded with quoted-printable to reduce the line lengths; this may be contentious, so the enclong .rc file entry allows the user to opt out of this; there's still more compliance work to do, though

096: Improve "Append, replace, type again or exit?" prompt (MS)

Saving to a file: if the file exists, a discreet line appears at the bottom of the screen with the same appearance as the message (white on black), inviting you to append, replace, etc. It is very easy to miss this line...

This now follows the same style as the other bottom of the screen prompts

097: When saving, report whether appending to or creating a folder (ST)

I'd like it to distinguish between appending to an existing folder ("... appended") and creating a new one ("... created") in its report of what it did.

This one annoyed me for years; now done

098: Ask whether or not to create new folders (BHK)

If PCOak would only say "Folder helpdesk does not exist; do you want to create it?", then I'd be prevented from making that simple and silly mistake so often. [Typing in the wrong folder name.]

The new confirmfoldcreate .rc file entry allows you to enable this behaviour (off by default)

102: Optionally confirm Abort when sending mail (BL)

Accidentally pressing a when intending to press s, and thereby losing your just-completed mail message, is very annoying!

Yup! 0.1.1 has a confirmsendabort .rc file entry which allows you to require confirmation of aborting messages

104: Allow shelling out from within pager (IF)

How difficult would it be for PcOaks shell ! function to be made to work from within the message viewer, just as it does from the message lister screen?

Not particularly difficult; it's now done

108: Allow user's address to be defined separately from "USER" (ST)

The USER entry in the RC file defines the "local-part" of your address, thereby (a) limiting it to a DOS-filename-compatible string and (b) meaning you can't have user "pcoak", for instance; it would be nice - optionally - to override this default local-part with one of your choice, while still using the USER entry for filenames, folder directory etc.

This is now available, with the usraddr .rc file entry

113: Use 'e' to quit pager and start up external pager on message (IF)

Would it be hard to have a viewer key, say "e" which drops the viewer and starts up the external viewer on the same article? It would certainly save a lot of time. I wouldnt think that it would be a good idea for this to change the "e" status of the mail lister screen.

Nice idea; done. Pressing E at the main index screen reads the message with the external pager as a one-off; pressing e in the pager quits the pager and does the same thing

115: Option for 'n' in pager to read next unread message directly (PC)

It might be useful (optionally, of course) to allow 'n' from within the pager to take you into the next unread message, rather than leave you at the index page.

Now done; the viewnextunread .rc file entry allows you to enable this

118: Base64 encoded lines should be longer (PD)

I changed a number somewhere in the B64 encoding to make longer lines (76 chars) to create slightly smaller huge files <g> by using fewer newlines.

Done. 76 character base64 lines are common among other mailers

The following suggestions have been implemented in PCOak 0.1

028*: Progress indicator when skipping large parts (PC, JW)

It would be useful to have a 'skipping....' message at the bottom as large sections skipped at first look like a hang! That is until you see the busy hard drive light. Ideally a rotating \|/- or a counter?

PCOak 0.1 displays "Skipping..." while it is skipping a section, but there's no counter or other progress indicator yet

041: Default to viewing message/delivery-status as text (BHK)

PCOak offers by default to display message/rfc822 as text. Could it please do the same for message/delivery-status?

Done; message/delivery-status is now displayed as text without any prompting

062: Don't use y_n() for mp/alt skipping (CR/Esc instead) (MS, IF)

The Yes/No question for skipping extra multipart/alternative sections is a poor choice of interface; using CR or Esc would be better than Y or N, especially since those are the normal keys for moving through a message.

The prompt has been replaced in 0.1 with a new prompt, using Esc/CR/Space to "ignore" the alternative, and v to "view" it; this should be easier to use

The following suggestions have been implemented in PCOak 0.0.9:

002: Improve free mem when shelled out (IF, JW, old uncle Tom Cobley and all)

Use Snews' swapping code to reduce memory size when shelled out.

Thomas Wagner's swapping exec code (used in Snews) has been added; this reduces PCOak's footprint to a couple of kilobytes when shelled out, or running external programs

005*: Improve viewing/decoding MIME messages (PC, MS, ST, PD)

MIME text parts are now generally just displayed; attachment names are now properly picked up from the headers

006*: Improve flaky MIME decoding capabilities (NJ, ST, JW)

Quoted-printable decoding is much improved in the pager, and will now also be applied when saving quoted-printable attachments; the code for detecting uuencoded attachments has been improved, which may help with uuencoded item decoding

012: Configurable smarthost sending (ST)

Togglable sending via a smarthost, for when (a) you know that a particular site is hard to get at, or (b) you are sending a large message to several different sites, and you want to reduce your phone bill!

Sending via a user-defined smarthost may be done in three ways: (a) never, (b) always, and (c) whenever the message has recipients at more than one domain

015: Improve long line wrapping in pager (ST)

Fix the broken wrapping of long quoted-printable lines with the built-in pager: when the text runs over the end of the line, it backs off by 3 characters before starting the next one, which looks awful.

The pager code has been revised, and unfolded long quoted-printable lines (which are what caused the problem) should now be wrapped correctly

016*: Move through parts of multipart at will (DGB, ST)

Some way to move backwards and forwards through the parts of a message, rather than only being able to step through forwards: e.g. a dialog listing the available parts, with their types, allowing you to choose which part you want to view/extract etc. now - once you've finished, select "Done" (or hit Esc).

Only partially implemented: at the end of a multipart message, you are now returned to the "Command? (100%)" prompt, from which you can scroll backwards, re-process the message etc.

018: View message with full headers (toggle weedout) (ST)

Sometimes I want to inspect the complete headers. If the weedout could be toggled on and off, that would be perfect.

Done: the command 'H' toggles header weedout on and off

021: Remove all references to Demon (JW)

Check for refs to Demon, remove anything that could mislead users to think this version is Demon supported.

Done!

051: Support multiple Reply-To recipients properly (BHK, RR)

Support multiple addresses on the Reply-To line properly

PCElm would only use the first address in a multi-address Reply-To header; PCOak 0.0.9 will send replies to all addresses on the line (multiple Reply-To lines don't work so well - only the last one is used - but they are illegal anyway)

Written by Simon Turner (simon at twoplaces.co.uk)
Last updated 06 April 2006