TODO: customizable help line error message line command line xterm GUI with menus: number of commands, j extra mode with *fixed*, non-changeable key bindings payoff: known bindings. good for documentation. low bandwidth remote connections (eg through modem) use on server with high load internal MTA port forwarding extensions/patches: compressed folders header cache thread editing modularity: why bark *must* not incorporate external functionalities (MTA, EDITOR etc) [you just cannot make it any simpler than externals already are..] a good systems offers *choices* for MTAs, EDITORs, etc. why not try a few and simply choose the one who fits best? IMAP: which features? support for multiple accounts?
BARK will be a text-based mailer for unix systems based on the code of the mailer "mutt". The first goal will be to remove some strange ways and to clean up the code, improve the documentation and the user interface. Long term goals of BARK are an internal scripting language to allow for solutions for which there need not be code within mutt. Removal of the bugs is alway .. of course). Code development will be done via CVS and maybe Subversion. The display will show name+version in every menu and the help line can be customized. There will also be an extra line for messages from the mailer to the user (good for debugging, documentation, and understand of commands). Error message will get a number, can be seen in an extra window and can be written into a log file.
Why yet another mailer? Mutt sucks less - but its development has lost the touch to the community. Bark will finally have the features which Mutt users have been longing for some years.
What's it all about? Improving mutt - the faster way. Getting rid of inconsistencies. Better documention - of code, too. Developer reports. Besides manual page and manual for the setup files there will be an intro, a user manual and a manual for admins. Lots of examples, too.
Will it be a newsreader? Maybe. But Mail comes first. But NNTP support might be a compile time feature, too.
So - where is it then? Nothing there yet - sorry. We need you help to make it happen. We'll start by cleaning up the code and making more modules. Then we'll start working on adding some design features.
ok - but *when* will it be here? the first prototype for users shall be ready for release in April 2005. see the roadmap for details.
$ bark -v bark 1.2.3 $ bark -V bark 1.2.3 2004-04-06 $ bark --version bark 1.2.3 2004-04-06 copyright licence basci help: "man bark" "info bark" urls.. homepage: ... compile time: ... compiled by: ... compile option: -bar +foo external commands: ...
CVS
Version InfoClear version info. Compile options. Included/excluded code. List of external commands. Extended version shows file permissions of all external commands.
Snapshots will be name "bark-YYYY-MM-DD.tar.gz". No more than one snapshot each day, of course.
When BARK starts up you'll get to the startup screen. This does not open the mailbox right away. For those who want a startup directly on their mailbox there's startup_on_mailbox which opens up on $MAIL or on $mailbox.
An option to suppress checking of setup files and folders. for use in scripts. faster. more consistent.
A clear concept on naming conventions.
All letters are available to flag messages. So you basically have a-z and A-Z as flags available. The meaning is user defined.
set flag_a=""
Punctuation characters are used for! New
T 1+ at least one personal address appears in To: C 1+ at least one personal address appears in Cc: + all all addresses are personals ones - none no personal addresses in all address lines F forw the message got forwarded through a personal addres R resent the message was resent (bounced)
Optionally show *all* header lines (with an additional positive and negative list along the lines of "ignore" and "unignore"). If the user screws up on editing the header then it is his own fault. Warning when the header seems to have been split.
By default, BARK will warn you on these things:
Access to score file via editor (similar to slrn). More dialogs - but very comfortable. Entries can be made with a command on the current message via a comfortable dialog; the resulting score rule gets appended to $file_scores - and the additional rule can be applied right away. scoring rules can also be applied on the fly without being added to the score file.
Scorefile format:
Score [List] Rules..List: list of folders/newsgroups default: * (all)
Example: =-9999 [*] From: invalid 100 Subject: bark
HOWTO on shell interaction. suspend, job control, fg. example: lokking at other mail folders, copying some messages to a file, compressing them, going back to mutt and atatching the compressed messages.
private: maillist1 maillist2 projects: maillist3 maillist4 fun: maillist5 maillist6 News programs: comp.mail.bark comp.mail.mutt
Some of the things that won't happen - and their reasons:
No builtin filter: A filter should get active when new mail comes in - and sort or delete the mails *once* when they arrive. You don't want this to happen when you start your mailer, though. You need to rely on the fact that all mails are where they were put. You don't want your mailer to keep moving messages about as this costs time and might accidentally lose mails. There are good filter about - use them! They have debug modes and log files, too, something which simply cannot be added to a mailer unless you want it to be really bloated. No builtin bouncer : Again, BARK should not automatically start sending out mails. BARK sends mail when the *user* sends it *interactively*. (well, you can use it in scripts, too, but those were created by humans, too, right?) It would be wrong to make the mailer send mails without the user noticing. An error in the setup file could quickly result in many sent emails - and even mail loops. We don't want this to happen. If you want to bounce on a mail - fine, use the "bounce" command. If you want to send on a mail with *any* kind of changes then you must *not* do this under someone else's name or address. you are in fact sending a *new* mail and must become the sender of it, too. WARNING If you ever use BARK for spamming then you *will* be in trouble. Fear the wrath of the community and the pain of the BITE! no builtin message correction many mailers and newsreaders screw up the text even after you have typed the key for sending off your message. BARK will *not* be a program which corrects all those broken kinds of text when you reply to those messages. there ar simply too many ways to break text - and only a human can correct this properly. however, there are tools which can help you correct broken text. use them along with your $EDITOR! mind you, there is an editor which includes all those extra features of corrections. it can even send email and news... modes prevail mostly users of GUI mailers think that they have access to all commands at any time because the menu are always available. well, this is *not* true, of course. many commands are only useful in context - and this is where "modes" come into play. as much as it seems painful to switch modes to access a command - there is always the possibility to create a macro to switch the context/menu to use a command.Documentation is based on SGML - which allows conversion to several formats (HTML, PDF, TeX, TXT). [maybe as "info" files and
all this will be a lot of data, so the additional documentation will probably be available as a separate archive.
List-Subscribe: List-Unsubscribe: List-Help:
message IN message OUT From: address From: me To: me To: NAME <address>when you receive an email from an address without a name and you have an alias pointing to that address then you can optionally have BARK add the name you have in that alias.
Much of mutt's code needs to be rewritten - so we might as well start all of it anew.
The main features of BARK are *speed* and *customization*. Anything that hampers its performance is a no-go.
Language: Although C is the most widely used language there are other popular languages about. Python and other interpreted langauges will probably be restricted in speed. But speed is vital. BARK *must* be speedy.
Internal language. BARK will have an internal language to allow the user to customize it more to his needs. There is no need to put all kinds of features into the program itself when a small script will
Code supervision: CVS, Subversion.
== Feedback Useful Comments and Questions: Andreas Kneip ... Andreas Borchert (Ulm) Franz Lax (Wien) == Documentation == Code == Support
BARK 0.0.0 2004-04-06 first release of detailed roadmap BARK 1.0.0 2007-04-06 interface overtakes elm, mutt, and pine