Help for Pine - Index Format
You are in Home > Miscellaneous > Index-Format


The Index-Format variable allows you to decide in which way you will see the list of messages that belong to a folder in the screen. As we will see, there are several configuration options that affect the way things appear in the screen.

The Index-Format for Starters

If you have never touched your configuration in Pine, the index will show you information (if available) about each message in the folder. This information includes among other things, the date in which the message was sent, the person who sent it, and the subject.

Let us talk about each field in the default configuration of Pine.

  1. Who Sent the Message: This is probably one of the most confusing parts about the index. Pine makes an effort to give you information that could be useful for you. Normally a message contains two important headers, the To: and From: fields. The rule is that Pine will show you the From field if the message is not from you, and if the above is not true, the To field.
    This sounds very good, there is one problem though.
    How does Pine know who you are?

    This is the key question. In general, one could say the the answer should be, by looking at the username that you use to login to the server that contains your INBOX, and by looking at the user-domain variable.
    The above seems to be a good rule, but it is not the end of the story. What happens if you decide to move your folders to another server? (say when you change your ISP). In this case, for a folder like sent-mail, Pine will be unable to determine who you are correctly (because the above stated rule will probably fail) and it will see a lot of messages from someone who Pine can not say that it's you. In other words, you will see that the sent-mail folder in another server will only show the From: field, which you already know, it's always the same, and this will make distinguishing between sent messages very difficult, since the index is not showing who the messages were sent to, but where the message came from.
    Therefore, we have transformed the question into, how do I tell Pine who I am? The answer is that most of the time you don't need to. In the event that Pine needs to know, because the above rules are failing, you should use the alt-addresses configuration option. You should add to that variable any e-mail address that is yours. Note that the alt-addresses variable is a list of addresses, which means that different entries must be separated by a comma ",". In order to configure this variable press M S C and scroll almost to the end. We will refer to this field, by reasons explained later as the FROMORTO field.
  2. The Subject of the Message: This field shows as much of the subject as it fits in the screen. It is normally double the size of the FROMORTO field.
    If the subject contains characters that are not part of the English alphabet, and in general that do not belong to the US-ASCII charset, then the standard says that these characters must be encoded before being transmitted through the net. This encoding is quite un-intuitive, and almost impossible to read for humans.
    In general when you send a message whose subject contains non US-ASCII characters, Pine encodes this subject using the charset defined in your character-set variable. For example, if you have set this variable to be ISO-8859-1, then the phrase El Niño, will be encoded as =?iso-8859-1?Q?El_Ni=F1o?=.
    On the other hand, when you receive a message, Pine will show you the subject in the charset specified in the subject. Normally, this does not cause any trouble, because you will probably be sending messages in just one charset, but sometimes, you may receive messages in some other charset. If the subject is not encoded in the charset that you specified in the character-set variable, then a warning will be shown to you in the index, in the form of a string which looks like [charset] preceding the subject. So, for example, if your character-set variable is set to US-ASCII, then Pine will display the subject El Niño (which is actually encoded in the message as =?iso-8859-1?Q?El_Ni=F1o?=) as [iso-8859-1] El Niño.
    Note that it is not guaranteed that you will see the letter ñ in Niño, since that depends on what your screen can display, so the warning is there to tell you that if something appears displayed incorrectly or not displayed at all, it's because of the strange characters in the subject, and not because of a bug in Pine.
    Finally notice that the same type of encoding can occur in the FROMORTO field, but because of space constrains, no warning is shown about characters not in the US-ASCII charset being encoded.
  3. The Size of the Message: This is a misleading number, but it represents the number of characters in the message. This includes the headers of the message, and in general anything included as part of the message. The reason why this is a misleading number is because attachments do not have the same size when attached than when they are part of your file system. The reason for this is that attachments are encoded before they are attached in a standard called MIME. This encoding usually makes files bigger in size than what they are.
    Incredibly enough, you can configure the way that the size is displayed in the screen. We will see how to do this later, and there was a change in the way that this field looks in version 4.40 of Pine, which makes the field shorter. For some reason, the Pine team decided that this was better. Maybe you will agree with them.
  4. The Date of the Message: This represents the date when the message was sent, so if you live in the US and have a friend living in Australia, it may very well be that you see the date of tomorrow in your index when reading a message from your friend. Pine does not do any type of conversion of this date to your date.
  5. The Status of the Message: This is the leftmost part of the index, in its leftmost column, you can see either one of five characters +, -, X, * or nothing (a space), then you will see another column which will contain a > character or a space, and finally another column with one of the following letters D, A, N, or nothing at all (a space). Let us see what all this means

    There is some priority between these characters, which is as follows. If a message is selected, and the message is not to be shown in boldface, then the X mark is shown. If the X mark is not shown, and the message is flagged important, then the * mark is shown. If the * mark is not shown, and your address appears in the To field, then the + mark is shown. If the + mark is not shown, and the message was sent to you as a copy, then a - mark may be shown. If this mark is not shown, then a blank space is shown in this column.
    Now let's talk about the second column of the Status of a message. There are only two possibilities, there is either a > sign or a space. The > appears only if you have selected the option [X] assume-slow-link, and it is used to indicate the position of the cursor in the index. In the case that the first column is empty (or there is a space in it), then a dash - is shown in the first column to have the effect of Pine showing an arrow -> to indicate the position of the cursor. Quite nice, I'd say.
    Finally, let's talk about the last column in the status field. Here are the possibilities. Finally we have the last field,
  6. The Number of the Message: this field contains a sequential number that identifies the message inside the folder. This number may be completely unrelated to the position that the message occupies in the folder (thinking of the folder as a file). For example, the last message of a folder appears as the number 1 message when the folder is sorted by reverse-arrival. There's an internal number, however, called the UID (Unique Identification Number) of the message that the server keeps, which never changes, regardless of how many messages arrive or are expunged from the folder. That number is the one that the server uses to identify a specific message in the folder.

Configuring the Index-Format

Now that you know what each field means, you may want to have Pine display either some other type of information or reorganize the way that the index is displayed in the screen.

Measuring Sizes

The width of the screen determines how much of the index is displayed in the screen. Some fields have a fixed width, like for example the Status field, which takes 3 columns, or the date field, which takes 6 columns. Some others do not have a fixed width, like the Message Number field.

The default algorithm that Pine uses to determine width of each field, is by first determining the available space. At the beginning this is the width of the screen, from which we must subtract the width of the fields that are fixed and the number of spaces in between the fields, then it is subtracted the width of the maximum message number in the folder and the width of the maximum size, which in the default configuration of Pine has a maximum of 6 characters wide. After having subtracted all of this width, and assuming that we have a positive number the remaining space is divided in a 2 to 1 proportion, leaving the subject twice as wide as the FROMORTO field.

In practice this means that the parts of the index that have fixed width have priority in the display of the screen over those that have variable width, which you can see if you shrink the width of your screen to be a very small value. Later on we will talk about how to set width for each field in the index display.

Setting the Fields in the Index

The way that the index appears on the screen is determined by the value of the index-format variable. There is extensive help on how to set this variable, which you can get to by pressing M S C, moving the cursor to this variable and pressing the ? key. Therefore I will assume that you will go and read that information, so that I do not have to rewrite it.

What follows is a brief summary of that information. The index-format is a line that contains a list of tokens (and their width). All tokens are written in CAPITAL letters. For example, SUBJECT and DATE are tokens. You should think of a token as a variable, which is replaced by the value that represents, so for example SUBJECT is always replaced by the subject of the message, and DATE by the date it was sent.

If we ignore sizes, then the default configuration of Pine, more or less is the following:

which means that the status of the message first, then the number that the message occupies in the folder, the the date it was sent, then who sent the message, the size and finally its subject. All of the definitions of these tokens were explained before in this document, and can be read by following this link.

Each token can be given a width. It makes sense to assign width only to those fields that have variable width. Those fields that have variable width have their final width determined last and therefore may not appear in the screen if this is not wide enough to contain more than the fields with fixed width.

When a field has variable size, you can specify its size by adding it to the name of the token, so something like SUBJECT(60%), or SUBJECT(23) has this effect.

Here are the rules that determine how the specification of sizes determines the width of the fields, when the width is variable.

Now we are finally ready. The default configuration of the index-format variable for Pine is

See Also:

Additional Tokens

Pine includes much more tokens that the ones discussed. Similar tokens to STATUS are FULLSTATUS and IMAPSTATUS, which contain more information about the status of a message than what STATUS does. I recommend to change STATUS by IMAPSTATUS, since it denotes Unread messages with the U flag and not with the N flag, which is more proper, I think. It takes some time to get used to it, but it is worth it. Also, it has the advantage that it uses different columns for different flags, so you can always tell which flags were set to any message, by just looking at the index, which is not the case with the STATUS token.

Tokens that are similar to FROMORTO, include FROM, TO, and FROMORTONOTNEWS. The first two are self explanatory, the latter is the same as the FROMORTO token, with the difference that in a newsgroup it behaves like the FROM token.

Tokens that are similar to SIZE, include the SIZECOMMA and KSIZE. SIZECOMMA is a new token, but it is the old definition of SIZE previous to version 4.40.

Among the tokens that are similar to DATE you can find SMARTTIME, SMARTDATE, which are tokens that display the date in a different way (like saying yesterday instead of saying yesterday's date)

The only token that does not enter into any of the categories discussed above is the SCORE token, which will show you the score of the message in the folder.

Generating the Index

When you open a folder, Pine requests from the server the information that it needs in order to display the index. What this means is that Pine requests about 20 envelopes from the server (which is about the number of messages that fit in a screen of 24 lines). Pine caches this information, so that whenever needed again, this information is not requested to the server again, reducing traffic to the server.

Notice that Pine needs to connect to the server to request this information, since it is not handed to Pine when a folder is opened. Even if we needed to sort this folder, the sorting process of the folder will be done by the server, so envelopes will not be sent to Pine by the server.

One of the reasons why this is done this way, is because otherwise, Pine would be very slow. Not because the program itself would be slow, but because transferring the information from the server has a cost, and that cost is paid in speed, so in a way, one would like that the server did all the work, and Pine only request information about the work done. That's why only a limited number of envelopes are requested, and later cached, as opposed to requesting all the envelopes.

In order to increase speed, Pine usually sends to the screen a line in the index as soon as the information is available. Sometimes this can be seen (because of traffic speed) and this causes that empty lines will be momentarily seen in the screen. This behavior annoys some people, and if this annoys you, you should manually add them to your .pinerc file. Just write under feature-list the following:

You are in Home > Miscellaneous > Index-Format