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_}
_FOLDER_ == {Lynx} -> lynx _FOLDER_ << {comp.mail.pine; pine-info; pine-alpha} -> pine _FOLDER_ << {Lynx; pine-info; comp.mail.pine} =>
_INDEX_{IMAPSTATUS MSGNO DATE FROMORTO(33%) SUBJECT(66%)} _FOLDER_ == {Lynx;pine-info} => _REPLY_{*** _FROM_ (_ADDRESS_)
wrote in the _FOLDER_ list _SMARTDATE_("Today" "today" "on
_LONGDATE_"):}
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} 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 }
_SUBJECT_ == {} => _RESUB_{Re: your mail without subject}
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} 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:
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"
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.
Any message in the folders "comp.mail.pine", "pine-info" or "pine-alpha"
will be saved to the folder "pine".
Use a
different index-format for the folders "Lynx", "pine-info" and
"comp.mail.pine", where the size is not present.
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_.
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).
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.
If there is no subject in the message, use the subject "Re: your mail
wiyhout subject" as a subject for the reply message.
This was meant to be an example only.
Get The patch!