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.
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:
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.
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:
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''.
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.
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
.
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:
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 #
''.
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
''.
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.
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.
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.
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:
set read_active 1
'' is in your slrnrc file. By default, slrn
does not read the active file.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 1in 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.
There are two ways:
slrn
prompts for a newsgroup, simply specify a comma-separated
list of newsgroups. Do not use spaces!Note: When crossposting, it is often polite to set a ``Followup-To'' header.
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.
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 .jnewsrcNote: Simply doing
sort -o .jnewsrc .jnewsrc
may or may not work
depending on your version of sort
.