Next Previous Contents

3. Usage

3.1 What is a prefix argument?

Many key-bindings accept prefix arguments. A prefix argument is a number that is generated prior to a key sequence and is used as a way of controlling the behavior of that key sequence. It is generated by pressing the ``ESC'' key and then pressing the keys that correspond to the number. For example, to generate a prefix argument of 314, simply press the 4 keys: ``ESC 3 1 4''.

Some functions use such arguments as repeat factors. That is, the function bound to the key sequence that they modify will be repeated the number of times specified by the prefix argument.

Other functions may simply use it as a way of slightly modifying the behavior of the function. For example, if ``1'' is used as a prefix argument for the ``followup'' function, the original article's headers will be included in the followup message; if ``2'' is used, the article also does not get modified (i.e. slrn does not insert quoting characters and neither attaches nor strips signatures). Without a prefix argument, you get a ``regular'' followup without the original article's headers.

3.2 Treatment of read articles

By default, slrn does not display articles that were previously marked as read. In most cases, this makes entering groups a lot faster, especially as slrn currently does not cache the headers locally and thus would have to download all the header information from the server again, each time you enter a group.

At first, most people who are used to a newsreader that always shows all available messages are often disappointed by this. After some time, they might find that slrn's default way of doing things allows them to read their news efficiently, because it keeps their mind on articles they did not yet deal with.

However, others still prefer to see everything and even if you don't, you still need to re-read an old article now and then. The following questions deal with these cases:

How can I never mark articles as read?

There is an option for it - you just need to set ``auto_mark_article_as_read'' to 0 in your slrnrc file.

In most cases, you will find that this is not what you really wanted to do, as it will make it difficult to find the ``new'' articles (i.e. the ones you did not yet read), so you might want to consider the answers to the following questions.

How can I get slrn to show both read and unread articles?

If you want to see all articles in a group (read and unread ones), simply set a ``prefix argument'' before entering a newsgroup. Using the default bindings, you can do this by pressing ``ESC 1 RETURN'' in group mode. There are variations of this; the online help or the manual will tell you more about them.

If you always want to enter groups that way, pressing three keys instead of one is annoying. You can avoid this using a special keybinding in your slrnrc file. Here is an example:

        setkey group "set_prefix_argument(4); () = select_group();" " "

With this line, pressing ``SPACE'' in group mode will enter the selected group with four as the prefix argument.

However, you might find it sufficient to make use of the following ways to display specific articles that were previously marked as read:

How can I retrieve read articles from the same thread?

If you want to read the ``parent'' of the article you are currently reading (e.g. because the author did not quote enough material to understand his message), ``ESC p'' will attempt to find it, using the ``References'' header line.

It is also possible to find all ``children'' of a given article using ``ESC Ctrl-P'' (note that this does not work with all servers) and, using a recursive combination of both, to reconstruct the entire thread tree. This is done by pressing either ``ESC 1 ESC p'' or ``ESC 2 ESC p'' - the second alternative can be much faster, but the first is more likely to find all articles even if some articles contain incomplete ``References''.

How can I retrieve other read articles?

You can locate any article if it is available on your server and you know its Message-ID. Pressing ``ESC l'' will produce the necessary prompt.

I want to see full threads as soon as they contain at least one unread article. Can slrn do this?

This is currently not implemented, although it should be possible to achieve such an effect using a macro.

For many, this behaviour would be a useful compromise between the two extremes of seeing all messages and seeing unread ones only, so this feature might be added in a future version of slrn.

3.3 Handling of binary postings

slrn is primarily designed as a newsreader (i.e. for reading and processing text messages); it is not a dedicated agent for downloading and decoding binary postings from Usenet. However, there is some basic functionality for decoding binary postings and there are some ways to make handling them a bit more convenient:

How do I uudecode articles?

Fortunately, the easiest way is also the most efficient. Basically this involves using the ``#'' key to numerically tag articles that you want to decode and then the ``:'' key to start the decode process. The only restriction is that multi-part uuencoded articles must be tagged in their proper order (see the next question if you think this is too much trouble). There is no need to uudecode one article at a time. Simply mark everything that you would like to decode and then press ``:''. Here is an actual example taken from alt.binaries.pictures.fractals:

        -    9:[Mike In Indy]    Kaboom! - kaboom.gif (0/1)
        - 3078:[Mike In Indy]    Kaboom! - kaboom.gif (1/1)
        -   23:[Gumbycat    ]    lucifer.gif  (0/7)
        -  433:[Gumbycat    ]    lucifer.gif -  for Halloween  (5/7)
        -  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (3/7)
        -  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (4/7)
        -  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (6/7)
        -  244:[Gumbycat    ]    lucifer.gif  -  for Halloween (7/7)
        -  434:[Gumbycat    ]    lucifer.gif  - for Halloween (1/7)
        -  433:[Gumbycat    ]    lucifer.gif - for Halloween (2/7)
        -   16:[Paul Carlson]    My Halloween Fractal - devil.gif (0/1)
        - 4310:[Paul Carlson]    My Halloween Fractal - devil.gif (1/1)
As you can see, 3 files have been posted: kaboom.gif, lucifer.gif, and devil.gif (At the time of this writing, it is Halloween weekend). Both kaboom.gif and devel.gif are single part files whereas lucifer.gif is a seven part series. Since lucifer.gif is displayed out of order, care must be exercised when tagging it (slrn will sort threads by subject and in this case the poster used an inconsistent subject format -- usually, sorting will result in the correct ordering). Assuming that we wish to decode these three gif images, the ``#'' key will be used to tag them. The result of using the ``#'' key is shown below:
        -     9:[Mike In Indy]    Kaboom! - kaboom.gif (0/1)
        1- 3078:[Mike In Indy]    Kaboom! - kaboom.gif (1/1)
        -    23:[Gumbycat    ]    lucifer.gif  (0/7)
        6-  433:[Gumbycat    ]    lucifer.gif -  for Halloween  (5/7)
        4-  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (3/7)
        5-  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (4/7)
        7-  433:[Gumbycat    ]    lucifer.gif  -  for Halloween (6/7)
        8-  244:[Gumbycat    ]    lucifer.gif  -  for Halloween (7/7)
        2-  434:[Gumbycat    ]    lucifer.gif  - for Halloween (1/7)
        3-  433:[Gumbycat    ]    lucifer.gif - for Halloween (2/7)
        -    16:[Paul Carlson]    My Halloween Fractal - devil.gif (0/1)
        9- 4310:[Paul Carlson]    My Halloween Fractal - devil.gif (1/1)
Now nine headers have been numerically tagged. To decode these, simply press the ``:'' key. slrn will prompt for a filename to save the articles to and after saving, it will prompt to go ahead and decode. The decoded files will be placed in the directory specified by the ``decode_directory'' variable that one can set in the slrnrc file. The end result is that after tagging with the ``#'' key, one presses ``:'' and hits return twice. To un-tag articles, press ``ESC #''.

What are the advantages of using uudeview?

slrn can be linked against the uudeview library; in this case, it will use the library functions to decode uuencoded articles. Unlike slrn's internal routines, uudeview is usually able to decode multipart messages even if you did not tag them in the correct order. Another advantage of (current versions of) uudeview is that it supports yEnc (see next question for details). A disadvantage is that it needs a lot more memory for decoding than slrn.

I got reports that uudeview decoded files for which slrn's code failed (and vice versa), so if you run into problems with a particular binary posting, it might be worth trying both - to allow this, there is the config variable ``use_uudeview'' which can be set to zero in case you have uudeview support compiled in, but want to use the builtin code nonetheless.

To link against uudeview, you need to have the library installed on your system; one way to get it is its homepage at <http://www.fpx.de/fp/Software/UUDeview/>. You also need to pass ``--with-uu'' to the configure script when building slrn (on Unix-like systems). If you did not compile your copy of slrn yourself, you can still find out whether it has uudeview support by looking for a ``+'' sign in front of ``uudeview'' in the output of ``slrn --version''.

What about yEnc?

yEnc <http://www.yenc.org/> is a way to encode binaries that makes use of 8bit characters, thus creating less overhead than the traditional uuencode and base64 methods. For this reason, it has become increasingly popular in certain binary groups. slrn does not have native support for yEnc: one reason for this is that I do not need this feature myself and so far, no patches for it have been contributed; besides, yEnc is still under development and still has some drawbacks which I'd like to see solved first. However, there already are two ways to decode such messages:

Prior to 0.9.7.4, slrn would corrupt some yEnc-encoded postings (by removing backspace-letter combinations traditionally used for formatting text messages). As this code has now been removed, you can pipe yEnc-encoded messages to external decoding programs from slrn; if you want to decode them from within slrn, you can link against a current version of uudeview, which now also supports yEnc (see previous question for details on this). However, uudeview sometimes generates ``no data found'' error messages when dealing with yEnc-encoded postings (even if it does decode them correctly); if you want to avoid them, you need at least version 0.9.8.0 of slrn, which simply ignores them.

Can I put multipart binary postings into one thread?

That option has been added in slrn 0.9.7.1. To use it, you need to define a macro that can compare two subjects and tell slrn whether or not they should be put into the same thread. An implementation of such a macro that should work for most cases and can serve as a starting point for your own experiments can be found in macros/multipart.sl in the source distribution.

3.4 How can I mark cross-posts as read in other groups as well?

For slrn to mark an article as read in more than one group, it needs information about what groups the article was cross-posted to. This information is provided by the ``Xref'' header. Not all servers provide this header so this feature will not work with those servers.

Now suppose that your server provides the ``Xref'' header as one of the headers of the article and at the same time, provides support for the NOV database (via the ``XOVER'' NNTP command). In this case, unless the server has been configured to provide the ``Xref'' header as part of the NOV database, slrn will not be able to get the header without accessing the article. Unfortunately, ``Xref'' is optional under NOV so many systems do not automatically provide it even though it is one of the recommended headers.

To summarize, make sure that your server provides the ``Xref'' header AND if it supports NOV, make sure that the ``Xref'' header is part of the NOV database.

3.5 Why doesn't the ``L'' command work as advertised?

Capital ``L'' lists all un-subscribed groups that slrn knows about. slrn gets this information through one of three sources. It tries the following in order and stops when one is successful:

  1. From the server via the active file. It only does this if the line ``set read_active 1'' is in your slrnrc file. By default, slrn does not read the active file.
  2. By querying the server using the ``LIST ACTIVE'' NNTP command with a wildmat argument. Please note that not all servers support this kind of query.
  3. From the groups listed in your newsrc file. In that case, the ``L'' command will only list unsubscribed groups that are present in this file.

The last one always succeeds with results that may be less than desirable. If you have a fast network connection to your server, simply put

        set read_active 1
in your slrnrc file. If you do not want slrn to read the active file because your connection is slow, see whether or not your server supports ``LIST ACTIVE'' with a wildmat argument. As a last resort, try to keep a full list of newsgroups in your newsrc file.

3.6 How do I cross-post an article?

There are two ways:

  1. When slrn prompts for a newsgroup, simply specify a comma-separated list of newsgroups. Do not use spaces!
  2. Edit the ``Newsgroups'' header line when editing the message. Again, the list of newsgroups must be comma separated with no whitespace. Also make sure that you do not wrap this line.

Note: When crossposting, it is often polite to set a ``Followup-To'' header.

3.7 How do I use the mouse in an XTerm to copy/paste?

If mouse reporting is turned on (via the ``-m'' command line switch or the ``mouse'' config variable), you need to hold down the shift key to mark text for copy/paste.

3.8 How can I sort the list of newsgroups?

Depending on what exactly you want to do, there are different possibilities: First of all, you can use the interactive ``move_group'' command (by default bound to ``m'') to move a single newsgroup to a different position. Before doing this, I recommend you display all subscribed groups (using ``toggle_hidden'', usually bound to ``l'', if necessary) so you won't be surprised by the result.

However, if you want to sort all groups alphabetically, you don't have to do this manually. slrn comes with a simple macro that does the job for you (gsort.sl) and you can find a more sophisticated one on the macro page of J.B. Nicholson-Owens.

On Unix-like systems, you can also use the sort command to sort your /newsrc file (do this while slrn is not running). For example, if you use .jnewsrc as your newsrc file:

        sort .jnewsrc > .jnewsrc-sorted
        mv .jnewsrc-sorted .jnewsrc
Note: Simply doing sort -o .jnewsrc .jnewsrc may or may not work depending on your version of sort.


Next Previous Contents