[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Terminology questions + fetch more articles wishlist
Re: Terminology questions + fetch more articles wishlist
Tue, 29 Jun 2004 17:39:49 -0000
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Enrique Perez-Terron <address@hidden> writes:
> 1. I have difficulty using the gnus manual because I never know what
> the specialised terms mean. For instance,
It helps if you understand the basic idea of news first. The
newsserver maintains a collection of articles, and these articles
belong to groups. Your newsreader (gnus) can retrieve information
about this collection (group listings, articles listing) or the
articles themselves. It can also `upload' (post) a new article.
The important detail about this model is what the newsserver does
*not* do -- it doesn't keep track of which groups you read, or which
articles you have read. Your newsreader does that.
Now on to your questions...
> a. Having read what I want in group I have recently "subscribed"
> to, I want to see if there has arrived more news since the
> summary buffer was formed. I look around in the menus, which
> should I choose? Catchup? Catchup all? What is "Catchup to
> here"? Would one of the "Mark" entries be better?
Catching up means your newsreader will mark all of the articles in
that group as `read'. Consequently, the default display of the group,
which only shows `unread' articles, will not list those articles. You
can still direct gnus to list them if you want.
"Catching up to here" is a way, in gnus, that you can mark a bunch of
articles as `read' all in one go. On the other hand, catching up a
whole group means all of the articles get marked as read.
"Mark" can mean two things depending on what you're reading, so it
would be better if you were a little more specific. Firstly there's
`the mark' in the general emacs sense (a bit like `the
point'). Secondly, there are the marks that gnus uses to keep track of
the status of articles for you (read, ticked, etc.).
> b. I just mentioned "subscribe", by some fluke of the universe I
> (believe I) understand what that means. How can I quickly
> check that I actually do? (besides trying it out.)
Being subscribed to a group means gnus will track whether you've read
articles in it or not. It also makes a difference to whether that
group is displayed in the group buffer `by default' (I'm speaking
quite loosely here).
> c. Some days ago I decided to read to some depth about "scoring" to
> find out what it is, and what that is good for. After several
> hours it dawns on me that perhaps it is way of making gnus guess
> what articles I would like to see, and suppress others. Cool.
> Why must it take so long to find out?
Think about its purpose -- it is trying to rank articles for you. Even
if you had a human doing that for you you would have trouble
explaining what you liked and what you didn't. The complexity is in
the user's preferences, and so the facility that attempts to support
those preferences will probably be complex.
> d. Have I found out?
Impossible to tell. Start using it if you need to. I would suggest you
don't use it at first, however. In general you won't have a good idea
of your own preferences until you've been reading news for a little while.
> e. While reading about scoring there are some uses of another word,
> "kill". What's that?
A very primitive means of ranking. When you configure gnus to kill
articles of a certain kind it marks them as read immediately and by
default you never see them.
> f. What was the "dribble file", again? (And how did it get this
> funny name?)
Don't know the history, but the purpose of the dribble file is to
track what you've done in the current gnus session. Think of it as the
change file between what your .newsrc* files were like when the
session started up and what they will be like when the session
> 2. I would like to have newly arrived articles added to the summary
> buffer without deleting the existing threads, because I want to be
> able to go back and reread earlier articles in the thread. I have
> seen there are some commands to fetch thread or fetch related
> articles, but I think I would be most comfortable if the thread
> hierarchy remained stable modulo additions. (Additions should stand
> out somehow.) Is there a way to do that?
It depends what you want to remain visible. It's not exactly clear.
If new articles appear in a thread, gnus will group them together and
you'll still have a thread. To retrieve the old articles is easy: `^'
to get the parent, and `A t' to get the whole thread once you're at
the root article. It's difficult to see what advantage there would be
in having the old article headers listed in the summary buffer, unless
you *really* like seeing the posters' names, because the subject is
almost always the same for the whole thread. If, instead, what you're
interested in is the `shape' of the thread with the new articles
incorporated, you may like something like this:
(setq gnus-summary-make-false-root nil)
(setq gnus-build-sparse-threads 'some)
which goes in your .gnus file.
> 3. If my dream (see 2.) comes true, it could easily become my
> nightmare unless I am still able to throw out old stuff. How can I
> do that without throwing out the dream as well?
This isn't really how news works. The articles are always available
until the *server* `throws them out' (expires them). What you and gnus
have control over is the display of the summary buffer.
> 4. I would especially like to keep threads that I have contributed to
> easily available across restarts of emacs/gnus.
Again it depends what you mean by `keep'. Perhaps you should tick such
articles so they always display whenever you enter the group.
> 5. I have discovered on some occasion that there is a handy keyboard
> shortcut to enter the gnus info manual. I have a brain dammage
> that prevents me from remembering it until I have used it a couple
> of times. (When I have used it a couple of times I hopefulley don't
> need it any more :) Would it be a bad idea to have this shortcut
> show up in the help menu when any of the gnus-related buffers are
You're asking an emacs question, I think. If you are able to customise
the help menu, I can't think of any harm it would do.
> 6. I always used to be very pleased by the high quality info manuals
> of emacs. They are sometimes a little verbose, but that is very
> small price to pay for having such excellent gentle introductions
> to the subjects. The gnus manual has some of the same verbose
> taste, but somehow there is something that doesn't quite work out.
> What is the best forum for discussing what to do about it? After
> all, I might be able to contribute. (I am certainly willing to
> devote some time.)
It depends what the problem is. I suspect some of your confusion stems
from a misunderstanding about how news works. I'm not sure correcting
this is the reponsibility of a newsreader's manual. Perhaps you should
read about news (usenet) in general, and then come back to the manual.
If, on the other hand, the problem is particular to gnus, then this is
the right place.