diff options
author | Erich Eckner <git@eckner.net> | 2019-09-01 21:39:52 +0200 |
---|---|---|
committer | Erich Eckner <git@eckner.net> | 2021-05-11 21:05:00 +0200 |
commit | 85617fe554d6de26b4582ce187df1e2e34921897 (patch) | |
tree | bf0591fa4a037e5837026b9b59e5670dc180f3bc /pith/pine.hlp | |
parent | b5eb45a153202d72aeb48de1149e7c74aef979fd (diff) | |
download | alpine-85617fe554d6de26b4582ce187df1e2e34921897.tar.xz |
rules.patch appliedrules
Diffstat (limited to 'pith/pine.hlp')
-rw-r--r-- | pith/pine.hlp | 1125 |
1 files changed, 1124 insertions, 1 deletions
diff --git a/pith/pine.hlp b/pith/pine.hlp index d973a0e..dbe36ca 100644 --- a/pith/pine.hlp +++ b/pith/pine.hlp @@ -4672,6 +4672,7 @@ There are also additional details on <li><a href="h_config_alt_reply_menu">FEATURE: <!--#echo var="FEAT_alternate-reply-menu"--></a> <li><a href="h_config_force_low_speed">FEATURE: <!--#echo var="FEAT_assume-slow-link"--></a> <li><a href="h_config_auto_read_msgs">FEATURE: <!--#echo var="FEAT_auto-move-read-msgs"--></a> +<li><a href="h_config_auto_read_msgs_rules">FEATURE: <!--#echo var="FEAT_auto-move-read-msgs-using-rules"--></a> <li><a href="h_config_auto_open_unread">FEATURE: <!--#echo var="FEAT_auto-open-next-unread"--></a> <li><a href="h_config_auto_unselect">FEATURE: <!--#echo var="FEAT_auto-unselect-after-apply"--></a> <li><a href="h_config_auto_unzoom">FEATURE: <!--#echo var="FEAT_auto-unzoom-after-apply"--></a> @@ -20004,6 +20005,7 @@ This set of special tokens may be used in the <A HREF="h_config_index_format">"<!--#echo var="VAR_index-format"-->"</A> option, in the <A HREF="h_config_reply_intro">"<!--#echo var="VAR_reply-leadin"-->"</A> option, in signature files, +in the <A HREF="h_config_reply_leadin_rules">"new-rules" option</A>, in template files used in <A HREF="h_rules_roles">"roles"</A>, and in the folder name that is the target of a Filter Rule. @@ -20016,7 +20018,7 @@ and in the target of Filter Rules. <P> <P> -<H1><EM>Tokens Available for all Cases (except Filter Rules)</EM></H1> +<H1><EM>Tokens Available for all Cases (except Filter Rules or in some cases for new-rules)</EM></H1> <DL> <DT>SUBJECT</DT> @@ -20050,6 +20052,22 @@ email address, never the personal name. For example, "mailbox@domain". </DD> +<DT>ADDRESSTO</DT> +<DD> +This is similar to the "TO" token, only it is always the +email address of all people listed in the TO: field of the messages. Addresses +are separated by a blank space. Example, "mailbox@domain" when +the e-mail message contains only one person in the To: field, or +"peter@flintstones.com president@world.com". +</DD> + +<DT>ADDRESSSENDER</DT> +<DD> +This is similar to the "sender" token, only it is always the +email address of all person listed in the Sender: field of the message. +Example: "mailbox@domain". +</DD> + <DT>MAILBOX</DT> <DD> This is the same as the "ADDRESS" except that the @@ -20097,6 +20115,15 @@ are unavailable) of the persons specified in the message's "Cc:" header field. </DD> +<DT>ADDRESSCC</DT> +<DD> +This is similar to the "CC" token, only it is always the +email address of all people listed in the Cc: field of the messages. Addresses +are separated by a blank space. Example: "mailbox@domain" when +the e-mail message contains only one person in the Cc: field, or +"peter@flintstones.com president@world.com". +</DD> + <DT>RECIPS</DT> <DD> This token represents the personal names (or email addresses if the names @@ -20105,6 +20132,14 @@ message's "To:" header field and the message's "Cc:" header field. </DD> +<DT>ADDRESSRECIPS</DT> +<DD> +This token represent the e-mail addresses of the people in the To: and +Cc: fields, exactly in that order separated by a space. It is almost obtained +by concatenating the ADDRESSTO and ADDRESSCC tokens. +</DD> + + <DT>NEWSANDRECIPS</DT> <DD> This token represents the newsgroups from the @@ -21229,6 +21264,110 @@ This is an end of line marker. </DL> <P> +<H1><EM>Tokens Available Only for New-Rules</EM></H1> + +<DL> +<DT>FCCFROM</DT> +<DD> +The Fcc: folder assigned to the email address in the From: field in the +addressbook. +</DD> +</DL> + +<DL> +<DT>FCCSENDER</DT> +<DD> +The Fcc: folder assigned to the email address in the Sender: field in the +addressbook. +</DD> +</DL> + +<DL> +<DT>ALTADDRESS</DT> +<DD> +The value of your +<a href="h_config_alt_addresses"><!--#echo var="VAR_alt-addresses"--></a> +variable. At this time, no expansion of regular expressions is supported. +</DD> +</DL> + +<DL> +<DT>NICK</DT> +<DD> +Nickname of the person in the From field in your addressbook. +</DD> +</DL> + +<DL> +<DT>FOLDER</DT> +<DD> +Name of the folder where the rule will be applied. +</DD> +</DL> + +<DL> +<DT>COLLECTION</DT> +<DD> +Name of the collection list where the rule will be applied. +</DD> +</DL> + +<DL> +<DT>ROLE</DT> +<DD> +Name of the Role used to reply a message. +</DD> +</DL> + +<DL> +<DT>BCC</DT> +<DD> +Not implemented yet, but it will be implemented in future versions. It will +be used for <A HREF="h_config_compose_rules">compose</A> +<A HREF="h_config_reply_rules">reply</A> +<A HREF="h_config_forward_rules">forward</A> +rules. +</DD> +</DL> + +<DL> +<DT>LCC</DT> +<DD> +This is the value of the Lcc: field at the moment that you start the composition. +</DD> +</DL> + +<DL> +<DT>FORWARDFROM</DT> +<DD> +This corresponds to the personal name (or address if there's no personal +name) of the person who sent the message that you are forwarding. +</DD> +</DL> + +<DL> +<DT>FORWARDADDRESS</DT> +<DD> +This is the address of the person that sent the message that you +are forwarding. +</DD> +</DL> + + + + +<DL> +<DT>FLAG</DT> +<DD> +A string containing the value of all the flags associated to a specific +message. The possible values of allowed flags are "*" for Important, "N" +for recent or new, "U" for unseen or unread, "R" for seen or read, "A" for +answered and "D" for deleted. See an example of its use in the +<A HREF="h_config_new_rules">new rules</A> explanation and example help. +</DD> +</DL> + +<P> <H1><EM>Token Available Only for Templates and Signatures</EM></H1> <DL> @@ -24584,6 +24723,897 @@ character sets Alpine knows about by using the "T" ToCharsets command. <End of help on this topic> </BODY> </HTML> +====== h_config_procid ===== +<HTML> +<HEAD> +<TITLE>Token: PROCID</TITLE> +</HEAD> +<BODY> +<H1>TOKEN: PROCID explained</H1> + +<P> +The PROCID token is a way in which the user and the program can differentiate +between different parts of a program. It allows the user to tell the +program when to use a specific rule, and only use it at that specific +moment. + +<P> The normal way in which this is done is by adding a new configuration +variable. The idea behind the PROCID token is that instead of adding a new +configuration variable (which means the user has to go through more +configuration variables just to tune the program to his liking), we reuse +an old variable and let the user look inside that variable for the desired +behavior, which is actually set by setting the PROCID token. + +<P> +Consider the following examples for forward-rules: + +<P> +_ROLE_ == {work} => _SUBJECT_ := _COPY_{[tag] _SUBJECT_} + +<P> +and + +<P> +_ROLE_ == {work} => _LCC_ := _TRIM_{_FORWARDFROM_ <_FORWARDADDRESS_>} + +<P> +both are triggered by the same condition. Since both are configured in the +same variable, only one of them will be executed all the time (whichever +is first). Therefore in order to differentiate, we add a _PROCID_ token. +So, for example, the first example above will be executed only when we are +determining the subject. In this case, the following rule will accomplish +this task + +<P> +_PROCID_ == {fwd-subject} && _ROLE_ == {work} => _SUBJECT_ := _COPY_{[tag] _SUBJECT_} + +<P> +In this case, this rule will be tested fully only when we are determining +the subject line of a forwarded message, not otherwise. + +<P> +It is wise to add the _PROCID_ token as the first condition in a rule, so +that other conditions will not be tested in a long list of rules. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_compose_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_compose-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_compose-rules"--></H1> + +<P> At this time, this option is used to generate values for signature +files that is not possible to do with the use of +<A HREF="h_rules_roles">roles</A>. + +<P> For example, you can have a rule like:<BR> +_TO_ >> {Peter Flintstones} => _SIGNATURE_{~/.petersignature} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_forward_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_forward-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_forward-rules"--></H1> + +<P> This option has several uses. This feature uses the PROCID function +to identify different features of forwarding. You can read more about PROCID +by following <A HREF="h_config_procid">this link</A>. + +<P> If you want to edit the subject of a forwarded message, use the +PROCID <I>fwd-subject</I>. For example you could have a rule like + +<P> +_ROLE_ == {admin} && _SUBJECT_ !> {[tag] } => _COPY_{[tag] _SUBJECT_} + +<P> Another way in which this option can be used, is to trim the values of +some fields. For this application the PROCID is <I>fwd-lcc</I>. For +example it can be used in the following way: + +<P> +_ROLE_ == {work} => _LCC_ := _TRIM_{_FORWARDFROM_ <_FORWARDADDRESS_>} + +<P> Other functions that can be used in this option are _EXEC_ and _REXTRIM_. + +<P> You can also use the _EXEC_ function. The documentation for this function +is in the +<A HREF="h_config_resub_rules"><!--#echo var="VAR_reply-subject-rules"--></A> +help text. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_index_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_index-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_index-rules"--></H1> + +<P> This option is used to supersede the value of the option <A +HREF="h_config_index_format"><!--#echo var="VAR_index-format"--></A> for specific folders. In +this form you can have different index-formats for different folders. For +example an entry here may be: + +<P> +_FOLDER_ == {INBOX} => _INDEX_{IMAPSTATUS DATE FROM(33%) SIZE SUBJECT(67%)} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_pretty_command ===== +<HTML> +<HEAD> +<TITLE>Pretty-Command Explained</TITLE> +</HEAD> +<BODY> +<H1>Pretty Command Explained</H1> + +<P> This text explains how to encode keys so that they will be recognized +by Alpine in the _PKEY_ token. Most direct keystrokes are recognized in the +same way. For example, the key ~ is recognized by the same character. The +issue is how control, or functions keys are recognized. The internal code +is most times easy to find out. If the key you want to use is not already +recognized by Alpine simply press it. Alpine will print its code. For example, +the return key is not recognized in this screen, so if you press it, you +will see the following message. + +<P> [Command "RETURN" not defined for this screen. Use ? for help] + +<P> from here you can guess that the code for the return command is +RETURN. You can try other commands, like Control-C, the TAB key, F4, etc. +to see their codes. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_key_macro_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_key-definition-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_key-definition-rules"--></H1> + +<P> This option can be used to define macros, that is, to define a key that +when pressed executes a group of predetermined keystrokes. Since Alpine is +a menu driven program, sometimes the same key may have different meanings +in different screens, so a global redefinition of a key although possible +is not advisable. + +<P> <B>Always use the _SCREEN_ token as defined below.</B>. You have been +warned! + +<P> In each screen, every time you press a recognized key, a command is +activated. In order to understand this feature, think of commands instead +of keystrokes. For example, you can think of the sort by thread command. +This command is associated to the keystrokes $ and h. You may want to +associate this command to a specific keystroke, like ~, so every time you +press the ~ key, Alpine understand the $ and h keystrokes, which activates +the sort by thread command. + +<P> Therefore, in order to use this option you must think of three +components. The screen where you will use the macro, the keystroke you +want to use and the set of keystrokes used by Alpine to accomplish the task +you want to accomplish. We will talk about these three components in what +follows. + +<P> First you must decide in which screen the macro will be used. This +feature is currently only available for the screen where your messages +are listed in index form (<A HREF="h_mail_index">MESSAGE INDEX</A>), +the screen where your message is displayed +(<A HREF="h_mail_view">MESSAGE TEXT</A>) and the screen where the list of +folders is displayed (<A HREF="h_folder_maint">FOLDER LIST</A>). The +internal names of these screens for this patch are "index", +"text" and +"folder" respectively. Please note that the internal names are +all in lowercase and are case sensitive. + +<P> In order to define the screen, you use the _SCREEN_ token, so for +example, you can write _SCREEN_ == {index}. + +<P> Second you must think of which key you will use to activate the macro. +Here you can use any key of your choice. The token you use to designate a +key is the _PKEY_ token (PKEY stands for "pressed key"). For +example you could use _PKEY_ == {~}, to designate the "~" +key to activate the command. Some keystrokes (like control, or +function keys) are encoded in special ways. You should read the +<A HREF="h_config_pretty_command">full explanation</A> on how to find +out the encoding for each keystroke. + +<P> Last, you must think of the list of keys you will use to accomplish +the task you want Alpine to perform. Say for example you want to have the +folder sorted by thread. That means you want Aline to execute the keys +"$" and "h". You use the _COMMAND_ function to specify +this. The syntax in this case is _COMMAND_{$,h}. + +<P> Observe that in the above example the different inputs are separated +by commas. This is the standard way in which the +<A HREF="h_config_init_cmd_list"><!--#echo var="VAR_initial-keystroke-list"--></A> command works from +the command line. Due to restrictions in the way Alpine works, a comma is a +special character, which when added to a configuration option like this +will cause the configuration to split into several lines in the +configuration screen. This has the effect of producing several +configuration options, all of which are incorrect. This is undesirable +because what you want is to have it all in one line. In order to force the +configuration into one line you must quote the comma. The best way to +accomplish this is by quoting the full definition of the rule. For +example. + +<P> +"_SCREEN_ == {index} && _PKEY_ == {~} => _COMMAND_{$,h}" + +<P> Another way to accomplish the same effect is by quoting the command and +not using quotes for the full command, nor commas to separate the +keystrokes in the command, for example + +<P> +_SCREEN_ == {index} && _PKEY_ == {~} => _COMMAND_{"$h"} + +<P> For more information on how to define the argument of the _COMMAND_ +token see the help of +<A HREF="h_config_init_cmd_list"><!--#echo var="VAR_initial-keystroke-list"--></A>. + +<P> Because the $ command can also be used as the first character in the +definition of an environemnt variable, no expansion of environment variables +is done when parsing this variable. The $ character does not need quoting +and quoting it will make Alpine fail to produce the correct result. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_replace_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_replace-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_replace-rules"--></H1> + +<P> This option is used to have Alpine print different values for specific +tokens in the <A HREF="h_config_index_format"><!--#echo var="VAR_index-format"--></A>. For example you +can replace strings like "To: newsgroup" by your name. + +<P> Here are examples of possible rules: + +<P>_FOLDER_ != {sent-mail} && _NICK_ != {} => _FROM_ := _REPLACE_{_FROM_ (_NICK_)} + +<P> or if you receive messages with tags that contain arbitrary numbers, and +you want them removed from the index (but not from the subject), use a rule +like the following + +<P>_FOLDER_ == {INBOX} => _SUBJECT_ := _REXTRIM_{\[some-tag-here #[0-9].*\]} + +<P> You can also use this configuration option to remove specific strings of +the index display screen, so that you can trim unnecessary information in +your index, like the reply leadin string in the OPENINGTEXTNQ token of the index.<BR> + +<P>_FOLDER_ == {some-folder} => _OPENINGTEXTNQ_ := _REXTRIM_{On.*wrote: } + +<P> You can also use the _EXEC_ function. The documentation for this function +is in the +<A HREF="h_config_resub_rules"><!--#echo var="VAR_reply-subject-rules"--></A> +help text. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_reply_leadin_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_reply-leadin-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_reply-leadin-rules"--></H1> + +<P> This option is used to have Alpine generate a different +<A HREF="h_config_reply_intro"><!--#echo var="VAR_reply-leadin"--></A> string dependent either on +the person you are replying to, or the folder where the message is being +replied is in, or both. + +<P> Here there are examples of how this can be used. One can use the definition +below to post to newsgroups and the pine-info mailing list, say: +<P> +_FOLDER_ << {pine-info;_NEWS_} => _REPLY_{*** _FROM_ _ADDRESS_("_FROM_" "" "(_ADDRESS_) ")wrote in_NEWS_("" " the" "") _FOLDER_ _NEWS_("" "list " "")_SMARTDATE_("Today" "today" "on _LONGDATE_"):} + +<P> Here there is an example that one can use to change the reply indent string +to reply people that speak spanish. +<P> +_FROM_{Condorito;Quico} => _REPLY_{*** _FROM_ (_ADDRESS_) escribió _SMARTDATE_("Today" "hoy" "en _LONGDATE_"):} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_resub_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_reply-subject-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_reply-subject-rules"--></H1> + +<P> This option is used to have Alpine generate a different subject when +replying rather than the one Alpine would generate automatically. + +<P> Here there are a couple of examples about how to use this +configuration option: + +<P> In order to have messages with empty subject to be replied with the message +"your message" use the rule<BR> +<center>_SUBJECT_ == {} => _RESUB_{Re: your message}</center> + +<P> If you want to trim some parts of the subject when you reply use the +rule<BR> +<center>_SUBJECT_ >> {[one];two} => _SUBJECT_ := _TRIM_{[;];two}</center> + +<P>this rule removes the brackets "[" and "]" whenever the string "[one]" +appears in it, it also removes the word "two" from it. + +<P>Another example where you may want to use this rule is when you +correspond with people that change the reply string from "Re:" +to "AW:" or "Sv:". In this case a rule like<BR> +<center>_SUBJECT_ >> {Sv: ;AW: } => _SUBJECT_ := _TRIM_{Sv: ;AW: }</center> +<P> +would eliminate undesired strings in replies. + +<P> Another interesting use of this option is the use of the _EXEC_ function. +This function takes as an argument a program or a script. This program +must take as the input a file, and write its output to that file. For example, +below is a sample of a script that removes the letter "a" of a file. + +<PRE> +#!/bin/sh +sed 's/a//g' $1 > /tmp/mytest +mv /tmp/mytest $1 +</PRE> + +<P> +As you can see this script took "$1" as input file, the sed program +wrote its output to /tmp/mytest, and then the move program moved the file +/tmp/mytest to the input file "$1". This is the kind of behavior +that your program is expected to have. + +<P> +The content of the input file ("$1" above) is the value of a token +like _SUBJECT_. In order to indicate this, we use the notation + +<P> +_SUBJECT_ := _EXEC_{/path/to/script} + +<P> for the action. So for example + +<P> +_FOLDER_ := {sent-mail} => _SUBJECT_ := _EXEC_{/path/to/script} + +<P> is a valid rule. + +<P> You can also use this configuration option to customize reply subjects +according to the sender of the message. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> +</BODY> +</HTML> +====== h_config_sort_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_sort-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_sort-rules"--></H1> + +<P> This option is used to have Alpine sort different folders in different orders +and thus override the value already set in the +<A HREF="h_config_sort_key"><!--#echo var="VAR_sort-key"--></A> configuration option. + +<P> Here's an example of the way it can be used. In this case all incoming +folders are mailing lists, except for INBOX, so we sort INBOX by arrival +(which is the default type of sort), but we want all the rest of mailing +lists and newsgroups to be sorted by thread. + +<P> +_COLLECTION_ >> {Incoming-Folders;News} && _FOLDER_ != {INBOX} => _SORT_{tHread} + +<P> Another example could be<BR> +_FOLDER_ == {Mailing List} => _SORT_{Reverse tHread} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> + +</BODY> +</HTML> +====== h_config_save_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_save-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_save-rules"--></H1> + +<P> This option is used to specify which folder should be used to save a +message depending either on the folder the message is in, who the message +is from, or text that the message contains in specific headers (Cc:, +Subject:, etc). + +<P> If this option is set and the +<A HREF="h_config_auto_read_msgs"><!--#echo var="FEAT_auto-move-read-msgs"--></A> configuration +option is also enabled then these definitions will be used to move messages +from your INBOX when exiting Alpine. + +<P>Here there are some examples<BR> +_FLAG_ >> {D} -> Trash<BR> +_FROM_ == {U2} -> Bono<BR> +_FOLDER_ == {comp.mail.pine} -> pine-stuff<BR> +_NICK_ != {} -> _NICK_/_NICK_<BR> +_DATEISO_ >> {02-10;02-11} -> archive-oct-nov-2002 + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> + +</BODY> +</HTML> +====== h_config_reply_indent_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_reply-indent-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_reply-indent-rules"--></H1> + +<P> This option is used to specify which reply-indent-string is to be used +when replying to an e-mail. If none of the rules are successful, the result in +the variable <a href="h_config_reply_indent_string"><!--#echo var="VAR_reply-indent-string"--></a> +is used. + +<P> The associated function to this configuration option is called "RESTR" (for +REply STRing). Some examples of its use are:<BR> +_FROM_ == {Your Boss} => _RESTR_{"> "}<BR> +_FROM_ == {My Wife} => _RESTR_{":* "}<BR> +_FROM_ == {Perter Flintstone;Wilma Flintstone} => _RESTR_{"_INIT_ > "}<BR> + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> + +</BODY> +</HTML> +====== h_config_smtp_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_smtp-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_smtp-rules"--></H1> + +<P> This option is used to specify which SMTP server should be used when +sending a message, if this rule is not defined, or the execution of the rule +results in no server selected, then Alpine will look for +the value from the role that is being used to compose the message. If no smtp +server is defined in that role or you are not using a role, then Alpine will get +the name of the server from the +<A HREF="h_config_smtp_server">"<!--#echo var="VAR_smtp-server"-->"</A> configuration +option according to the rules used in that variable. + +<P> The function associated to this configuration option is _SMTP_, an example +of the use of this function is<BR> +_ADDRESSTO_ == {peter@bedrock.com} => _SMTP_{smtp.bedrock.com} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> + +</BODY> +</HTML> +====== h_config_startup_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: <!--#echo var="VAR_startup-rules"--></TITLE> +</HEAD> +<BODY> +<H1>OPTION: <!--#echo var="VAR_startup-rules"--></H1> + +<P> This option is used when a folder is being opened. You can use it to specify its <A +HREF="h_config_inc_startup"><!--#echo var="VAR_incoming-startup-rule"--></A> and override +Alpine's global value set for all folders. + +<P> An example of the usage of this option is:<BR> +_FOLDER_ == {Lynx;pine-info;_NEWS_} => _STARTUP_{first-unseen} + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P><End of help on this topic> + +</BODY> +</HTML> +====== h_config_new_rules ===== +<HTML> +<HEAD> +<TITLE>OPTION: New Rules Explained</TITLE> +</HEAD> +<BODY> +<H1>OPTION: New Rules Explained</H1> + +This is a quite powerful option. Here you can define rules that override +the values of any other option you have set in Alpine. + +<P> +For example, you can set your folders to be sorted in a certain way when +you open them (say by Arrival). You may want, however, your newsgroups to +be sorted by thread. The set of "rules" options allows you to +configure this and many other options, including the index-format for +specific folders, the way the subject is displayed in the index screen or +the reply-leadin-string, to name a few. + +<P> +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 satisfied. + +<P> + Here is an example: + +<P> + _FROM_ == {Fred Flintstone} => _SAVE_{Fred} + +<P> + Here the separator is "=>". Whatever is to the left of the separator +is the condition (that is _FROM_ == {Fred Flintstone}) 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 +Flintstone", 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. + +<P> + The separator is always "=>", with one exception to be seen +later. But for the most part this will be the only one you will ever need. + +<P> + Now let us see how to do it. There are 13 functions already defined for +you. These are: _EXEC_, _INDEX_, _REPLACE_, _REPLY_, _RESUB_, _SAVE_, +_SIGNATURE_, _SORT_, _STARTUP_, _TRIM_, _REXTRIM_, _THREADSTYLE and +_THREADINDEX_. The parameter of a function has to be enclosed between +"{" and "}", so for example you can specify +_SAVE_{saved-messages} as a valid sentence. + +<P> + Later in the document you will find examples. Here is a short +description of what each function does: + +<P> +<UL> +<LI> _EXEC_ : This function takes as an argument a program. This program +gets as the input a file and must rewrite its output to that file, which +is then taken as the value to replace from the contents of that file. You +can use this function with +<A HREF="h_config_resub_rules"><!--#echo var="VAR_reply-subject-rules"--></A>, +<A HREF="h_config_replace_rules"><!--#echo var="VAR_replace-rules"--></A> and +<A HREF="h_config_forward_rules"><!--#echo var="VAR_forward-rules"--></A>. +See the help of those options for examples of how to use this function +and configure these rules. +<BR> <BR> +<LI> _INDEX_ : This function takes as an argument an index-format, and +makes that the index-format for the specified folder. +<BR> <BR> +<LI> _REPLACE_ : This function replaces the subject/from of the given e-mail by +another subject/from only when displaying the index. +<BR> <BR> +<LI> _REPLY_ : This function takes as an argument a definition of a +reply-leadin-string and makes this the reply-leading-string of the +specified folder or person. +<BR> <BR> +<LI> _RESTR_ : This function takes as an argument the value of the +reply-indent-string to be used to answer the message being replied to. +<BR> <BR> +<LI> _RESUB_ : This function replaces the subject of the given e-mail by +another subject only when replying to a message. +<BR> <BR> +<LI> _SAVE_ : The save function takes as an argument the name of a +possibly non existing folder, whenever you want to save a message, that +folder will be offered for you to save. +<BR> <BR> +<LI> _SIGNATURE_ : This function takes as an argument a signature file and +uses that file as the signature for the message you are about to +compose/reply/forward. +<BR> <BR> +<LI> _SMTP_ : This function takes as an argument the definition of a +SMTP server. +<BR> <BR> +<LI> _SORT_ : This function takes as an argument a Sort Style, and sorts a +specified folder in that sort order. +<BR> <BR> +<LI> _TRIM_ : This function takes as an argument a list of strings that +you want removed from another string. At this time this only works for +_FROM_ and _SUBJECT_. +<BR> <BR> +<LI> _REXTRIM_ : Same as _TRIM_ but its argument is one and +only one extended regular expression. +<BR> <BR> +<LI> _STARTUP_ : This function takes as an argument an +incoming-startup-rule, and open an specified folder using that rule. +<BR> <BR> +<LI> _THREADSTYLE_ : This function takes as an argument a +threading-display-style and uses it to display threads in a folder. +<BR> <BR> +<LI> _THREADINDEX_ : This function takes as an argument a +threading-index-style and uses it to display threads in a folder. +</UL> + +<P> +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 another words for +the rule: + +<P> + _FROM_ == {Fred Flintstone} => _SAVE_{Fred} + +<P> it will only be applied if the from is "Fred Flintstone". If +the From is "Wilma Flintstone" the rule will be skipped. + +<P> In order to test a condition you can use the following tokens (in +alphabetical order): _ADDRESS_, _CC_, _FOLDER_, _FROM_,_NICK_, _ROLE, +_SENDER_, _SUBJECT_ and _TO_. 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". The definition +of each token can be found <A HREF="h_index_tokens">here</A>. + +<P> A special testing token called _PROCID_ can be used to differentiate +inside a rule, between two rules that are triggered by the same condition. +A full explanation of the _PROCID_ token can be found in +<A HREF="h_config_procid">this link</A>. + +<P> There are two more tokens related to the option +<A HREF="h_config_key_macro_rules">key-definition-rules</A>. Those tokens +are only specific to that option, and hence are not explained here. + +<P> You can also test in different ways, you can use the following +"test operands": <<, !<, >>, !>, == and !=. +All of them are two characters long. Here is the meaning of them: + +<P> +<UL> +<LI> << : It tests if the value of the token is contained in +the condition set. Here for example if the condition set were equal to +"Freddy", then the condition: _NICK_ << {Freddy}, would be true if +the value of _NICK_ were "Fred", "red" or "Freddy". You are just looking +for substrings here. +<LI> >> : It tests if the value of the token contains the value of +the condition set. Here for example if the condittion set were equal to +"Fred", then the condition: _FROM_ >> {Fred}, would be true if +the value of _FROM_ were "Fred Flintstone" or "Fred P. Flintstone" or "Freddy". +<LI> == : It tests if the value of the token is exactly equal to the value +of the set condition. For example _NICK_ == {Fred} will be false if the value +of _NICK_ is "Freddy" or "red". +<LI> !< : This is true only when << is false and vice versa. +<LI> !> : This is true only when >> is false and vice versa. +<LI> != : This is true only when == is false and vice versa. +</UL> + +<P> + 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. + +<P> + _FOLDER_ << {folder1; folder2} => _SORT_{OrderedSubj} + +<P> + Here is the first subtlety about these definitions. Notice that the +following rule: + +<P> + _FOLDER_ == {folder1; folder2} => _SORT_{Reverse OrderedSubj} + +<P> 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 <BR> +"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. + +<P> + Here are a few examples of what we have talked about before. + +<P> +_NICK_ == {lisa;kika} => _SAVE_{_NICK_/_NICK_} <BR> +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" + +<P> +_FOLDER_ == {Lynx} -> lynx <BR> +This, is an abbreviation of the following rule:<BR> +_FOLDER_ == {Lynx} => _SAVE_{lynx} <BR> +(note the change in separator from "=>" to "->"). In the future +I will use that abbreviation. + +<P> _FOLDER_ << {comp.mail.pine; pine-info; pine-alpha} -> pine <BR> +Any message in the folders "comp.mail.pine", "pine-info" or "pine-alpha" +will be saved to the folder "pine". + +<P> _FROM_ << {Pine Master} -> pine <BR> +Any message whose From field contains +"Pine Master" will be saved in the folder pine. + +<P> _FOLDER_ << {Lynx; pine-info; comp.mail.pine} => +_INDEX_{IMAPSTATUS MSGNO DATE FROMORTO(33%) SUBJECT(66%)} <BR> Use a +different index-format for the folders "Lynx", "pine-info" and +"comp.mail.pine", where the size is not present. + +<P> _FOLDER_ == {Lynx;pine-info} => _REPLY_{*** _FROM_ (_ADDRESS_) +wrote in the _FOLDER_ list _SMARTDATE_("Today" "today" "on +_LONGDATE_"):}<BR> 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_. For example answering to a +message in the pine-info list would look like: + +<P> +*** Steve Hubert (hubert@cac.washington.edu) wrote in the pine-info list today: + +<P> +However replying for a message in the Lynx list would look: + +<P> +*** mattack@area.com (mattack@area.com) wrote in the Lynx list today: + +<P> +If you write in more than one language you can use this feature to create +Reply-leadin-strings in different languages. + +<P> 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. + +<P> _FOLDER_ << {Lynx; comp.mail.pine; pine_info; pine-alpha} => +_SORT_{OrderedSubj}<BR> This means upon opening, sort the folders "Lynx", +"comp.mail.pine", etc in ordered subject. All the others use the default +sort order. You can not sort in reverse in this form. The possible +arguments of this function are listed in the definition of the +default-sort-rule (Arrival, scorE, siZe, etc). + +<P> The last examples use the function _TRIM_ which has a special form. +This function can only be used in the index list. + +<P> _FOLDER_ << {Lynx} => _SUBJECT_ := _TRIM_{lynx-dev }<BR> 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. + +<P> _FROM_ >> {Name (Comment)} => _FROM_ := +_TRIM_{ (Comment)}<BR> Remove the part " (Comment)" +from the _FROM_, so when displaying in the index the real From "Name" +will appear. + +<P> _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. + +<P> You can add more complexity to your rules by checking more than one +conditions before a rule is executed. More than one condition can be +checked by separating different conditions by the && (and) separator, +or using the || (or) separator. For example we could have a rule that +saves all +messages in inbox from Rubye, to the Personal folder, as + +<P> _FOLDER_ == {INBOX} && _FROM_ >> {Rubye} => _SAVE_{Personal} + +<P> We could also have a rule that is triggered by an "or" +condition by, sat for messages from Andres or messages in the index +to trigger a specific reply leadin string. + +<P> _FOLDER_ == {INBOX} || _FROM_ >> {Andres} => _REPLY_{You wrote:} + +<P>Observe that the construction + +<P> _TOKEN_ == {value1} || _TOKEN_ == {value2} + +<P>can be shortened to + +<P> _TOKEN_ == {value1;value2} + +<P> Round parentheses can be used to group some conditions, for example + +<P> (_FROM_ >> {Andres} && _FOLDER_ == {INBOX}) || _FROM_ >> {Rubye} + + +<P> You can also list your index by nick, in the following way:<BR> +_NICK_ != {} => _FROM_ := _REPLACE_{_NICK_} + +<P> + If you want to open the folder "pine-info" in the first non-read message +use the rule:<BR> +_FOLDER_ == {pine-info} => _STARTUP_{first-unseen} + +<P> + If you want to move your deleted messages to a folder, called "Trash", use +the following rule:<BR> +_FLAG_ >> {D} -> Trash + +<P> +The reason why the above test is not "_FLAG_ == {D}" is because that would mean +that this is the only flag set in the message. It's better to test by containment in this case. + +<P> If you want to use a specific signature when you are in a specific collection +use the following rule:<BR> +_COLLECTION_ == {Mail} => _SIGNATURE_{/full/path/to/.signature} + +<P> 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. + +<P> +<UL> +<LI><A HREF="h_finding_help">Finding more information and requesting help</A> +</UL><P> +<End of help on this topic> +</BODY> +</HTML> ====== h_config_char_set ===== <HTML> <HEAD> @@ -28206,6 +29236,76 @@ MESSAGE TEXT screen. <End of help on this topic> </BODY> </HTML> +====== h_config_thread_display_style_rule ===== +<HTML> +<HEAD> +<TITLE>OPTION: Threading-Display-Style-Rule</TITLE> +</HEAD> +<BODY> +<H1>OPTION: Threading-Display-Style-Rule</H1> + +This option is very similar to <A HREF="h_config_thread_disp_style"> +<!--#echo var="VAR_threading-display-style"--></A>, but it is a rule which specifies the +display styles for a thread that you want displayed in a specific +folder or collection. +<P> +The token to be used in this function is _THREADSTYLE_. Here there is +an example of its use +<P> +_FOLDER_ == {pine-info} => _THREADSTYLE_{mutt-like} +<P> +The values that can be given for the _THREADSTYLE_ function are the +values of the threading-display-style function, which can be found +listed in the <A HREF="h_config_thread_disp_style">threading-display-style</A> +configuration option. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P> +<UL> +<LI><A HREF="h_finding_help">Finding more information and requesting help</A> +</UL><P> +<End of help on this topic> +</BODY> +</HTML> +====== h_config_thread_index_style_rule ===== +<HTML> +<HEAD> +<TITLE>OPTION: Threading-Index-Style-Rule</TITLE> +</HEAD> +<BODY> +<H1>OPTION: Threading-Index-Style-Rule</H1> + +This option is very similar to <A HREF="h_config_thread_index_style"> +<!--#echo var="VAR_threading-index-style"--></A>, but it is a rule which specifies the +index styles for a thread that you want displayed in a specific +folder or collection. +<P> +The token to be used in this function is _THREADINDEX_. Here there is +an example of its use +<P> +_FOLDER_ == {pine-info} => _THREADINDEX_{regular-index-with-expanded-threads} +<P> +The values that can be given for the _THREADINDEX_ function are the +values of the threading-index-display function, which can be found +listed in the <A HREF="h_config_thread_index_style"><!--#echo var="VAR_threading-index-style"--></A> +configuration option. + +<P> This configuration option is just one of many that allow you to +override the value of some global configurations within Alpine. There is a +help text explaining how to define all of them, which you can read by +following this <A HREF="h_config_new_rules">link</A>. + +<P> +<UL> +<LI><A HREF="h_finding_help">Finding more information and requesting help</A> +</UL><P> +<End of help on this topic> +</BODY> +</HTML> ====== h_config_thread_disp_style ===== <HTML> <HEAD> @@ -31928,6 +33028,29 @@ them as deleted in the INBOX. Messages in the INBOX marked with an <End of help on this topic> </BODY> </HTML> +====== h_config_auto_read_msgs_rules ===== +<HTML> +<HEAD> +<TITLE>FEATURE: auto-move-read-msgs-using-rules</TITLE> +</HEAD> +<BODY> +<H1>FEATURE: auto-move-read-msgs-using-rules</H1> +This feature controls an aspect of Alpine's behavior upon quitting. If set, +and the +<A HREF="h_config_read_message_folder">"<!--#echo var="VAR_read-message-folder"-->"</A> +option is also set, then Alpine will automatically transfer all read +messages to the designated folder using the rules that you have defined in +your +<A HREF="h_config_save_rules">"<!--#echo var="VAR_save-rules"-->"</A> and mark +them as deleted in the INBOX. Messages in the INBOX marked with an +"N" (meaning New, or unseen) are not affected. +<P> +<UL> +<LI><A HREF="h_finding_help">Finding more information and requesting help</A> +</UL><P> +<End of help on this topic> +</BODY> +</HTML> ====== h_config_auto_fcc_only ===== <HTML> <HEAD> |