OPTION: New Rules

This is a quite powerful option. Here you can define rules that override the values of any other global rule you have globally set in pine.

For example, you can set your folders to be sorted in a certain way when you open them (say by Arrival). You may not want to be this the behavior of, say, a Newsgroup, maybe you would like there to have your folder to be automatically ordered by Ordered Subject. The purpose of this feature is to accomplish exactly that. You can use this option for defining such exception and make Pine automatically sort your favorite Newsgroup by Ordered Subject.

On the other hand you may be suscribed to a mailing list, and maybe you don't care to see in the index the size of the messages, however in other lists you may want to see the size of the messages. You can use this configuration for changing the way the index is displayed in a folder.

Also there may be a mailing list that identifies itself by adding a certain string to its subject which makes difficult to read the total subject, so you may want to delete that string from the subject whenever it appears. You can do that also with this configuration.

You may also want to make your reply-leadin-string person or folder dependent. You can do this with this feature (part of this feature can be accomplised with the roles definitions, but roles are not the right tool to do this as you will see).

Every rule has three parts, a condition, a separator and an action. The action is what will happen if the condition of the rule is satisified.

Here is an example:

_FROM_ == {Fred Flinstone} => _SAVE_{Fred}

Here the separator is "=>". Whatever is to the left of the separator is the condition ( _FROM_ == {Fred Flinstone}) and to the right is the action (_SAVE_{Fred}). The condition means that the rule will be applied only if the message that you are reading is from "Fred Flinstone", and the action will be that you will be offered to save it in the folder "Fred", whenever you press the letter "S" to save a message.

The separator is always "=>", with one exception to be seen later. But for the most part this will be the only one you'll ever need.

Now let us see how to do it. There are 8 functions already defined for you. These are:" _INDEX_, _REPLACE, _REPLY_, _RESUB_, _SAVE_, _SORT_,_STARTUP_ and _TRIM_.. The parameter of a function has to be enclosed between "{" and "}", so for example you can specify _SAVE_{saved-messages} as a valid sentence.

At the end of the document you will find more examples.Here is a short description of what each function does:

You must me wondering how to define the person/folder over who to apply the action. This is done in the condition. When you specify a rule, the rule is only executed if the condition is satisfied. In other words for the rule:

_FROM_ == {Fred Flinstone} => _SAVE_{Fred}

it will only be applied if the from is "Fred Flinstone", if the From is "Wilma Flinstone" the rule will be skipped.

In order to test a condition you can use the following tokens: _NICK_, _FROM_, _TO_, _CC_, _SENDER_, _SUBJECT_ and _FOLDER_. The token will always be tested against what it is between "{" and "}" in the condition, this part of the condition is called the "condition set". You can also test in different ways, you can use the following "test operands": <<, !<, >>, !>, == and !=. All of them are two strings long. Here is the meaning of them:

Now let us say that you want the same action to be applied to more than one person or folder, say you want "folder1" and "folder2" to be sorted by Ordered Subject upon entering. Then you can list them all of them in the condition part separting them by a ";". Here is the way to do it.

_FOLDER_ << {folder1; folder2} => _SORT_{OrderedSubj}

Here is the first subtelty about these definitions. Notice that the following rule:

_FOLDER_ == {folder1; folder2} => _SORT_{OrderedSubj}

works only for "folder1" but not for "folder2". This is because the comparison of the name of the folder is done with whatever is in between "{", ";" or "}", so in the above rule you would be testing "folder2" == " folder2". The extra space makes the difference. The reason why the first rule does not fail is because "folder2" << " folder2" is actually true. If something ever fails this may be something to look into.

Here are a few examples of what we have talked about before.

_NICK_ == {lisa;kika} => _SAVE_{_NICK_/_NICK_}
This means that if the nick is lisa, it will save the message in the folder "lisa/lisa", and if the nick is "kika", it will save the message in the folder "kika/kika"

_FOLDER_ == {Lynx} -> lynx
This, is an abreviation of the following rule:
_FOLDER_ == {Lynx} >> _SAVE_{lynx}
(note the change in separator from "
>>" to "->"). In the future I will use that abreviation.

_FOLDER_ << {comp.mail.pine; pine-info; pine-alpha} -> pine
Any message in the folders "comp.mail.pine", "pine-info" or "pine-alpha" will be saved to the folder "pine".

_FOLDER_ << {Lynx; pine-info; comp.mail.pine} => _INDEX_{IMAPSTATUS MSGNO DATE FROMORTO(33%) SUBJECT(66%)}
Use a different index-format for the folders "Lynx", "pine-info" and "comp.mail.pine", where the size is not present.

_FOLDER_ == {Lynx;pine-info} => _REPLY_{*** _FROM_ (_ADDRESS_) wrote in the _FOLDER_ list _SMARTDATE_("Today" "today" "on _LONGDATE_"):}
If a message is in one of the incoming folders "Lynx" or "pine-info", create a reply-leadin-string that acknowledges that. Note the absence of "
," in the function _SMARTDATE_.

If you write in more than one language you can use this feature to create Reply-leadin-strings in different languages.

Note that at least for people you can create particular reply-leadin-string using the role features, but it does not work as this one does. This seems to be the right way to do it.

_FOLDER_ << {Lynx; comp.mail.pine; pine_info; pine-alpha} => _SORT_{OrderedSubj}
This means upon opening, sort the folders "Lynx", "comp.mail.pine", etc in ordered subject. All the others use the default sort order. The possible arguments of this function are listed in the definition of the default-sort-rule (Arrival, scorE, siZe, Reverse tHread, etc).

The last examples use the function _TRIM_ which has a special form. This function can only be used in the index list.

_FOLDER_ << {Lynx} => _SUBJECT_ := _TRIM_{lynx-dev }
In the folder "Lynx" eliminate from the subject the string "lynx-dev " (with the space at the end). For example a message whose subject is "Re: lynx-dev unvisited Visited Links", would be shown in the index with subject: "Re: unvisited Visited Links", making the subject shorter and giving the same information.

_SUBJECT_ == {} => _RESUB_{Re: your mail without subject}
If there is no subject in the message, use the subject "Re: your mail wiyhout subject" as a subject for the reply message.

You can add more complexity to your rules by checking more than one conditions before a rule is executed. For example: Assume that you want to answer every email that contains the string "bug report", with the subject "Re: About your bug report", you could make

_SUBJECT_ == {bug report} => _RESUB_{Re: About your _SUBJECT_}

The problem with this construction is that if the person emails you back, then the next time you answer the message the subject will be: "Re: About your Re: About your bug report", so it grew. You may want to avoid this growth by using the following rule:

_SUBJECT_ >> {bug report} && _SUBJECT_ !> {Re: } => _RESUB_{Re: About your _SUBJECT_}

which will only add the string "Re: About your" only the first time the message is replied.

Of course you can always reply by using the rule

_SUBJECT_ == {bug report} => _RESUB_{Re: About your bug report}
This was meant to be an example only.

Finally about the question of which rule will be executed. Only the first rule that matches will be executed. It is important to notice though that "saving" rules do not compete with "sorting" rules. So the first "saving" rule that matches will be executed in the case of saving and so on.

Here are some things to do still:

Get The patch!