treatment of prefix arg in `gnus-group-select-group'

treatment of prefix arg in `gnus-group-select-group'

[Cyprian Laskowski]

Hi,

I'm lovin' Oort Gnus; thanks everyone!

I think I have a feature request or improvement suggestion.  Or maybe
there's some configuration that I could be doing that I've missed.

Basically, I think the prefix argument should be treated more cleverly
by `gnus-group-select-group' (and its other group-entering
colleagues).  In 2 respects, IMHO:

1.  If the group has lots of unread articles, past the threshold where
    it normally asks me how many articles to fetch, it should not ask
    me if I provide a prefix argument.  I.e., if I do `10 RET', I
    should not be asked how many articles to fetch.

2.  The prefix argument of 0 should be treated specially: if I do `0
    RET', Gnus should not bother with any sort of scoring (I'm not
    sure if it does now) or whatnot, and should immediately just put
    me in the summary buffer.

    I sometimes do `0 RET' if I'm just looking for some cached article,
    and in these cases I don't want to bother fetching new articles.
    I just want to type `/ *' and see cached articles (which don't
    require interacting with the server).  In fact, even if the server
    is totally down, a `0 RET' should work like this, I think.


What do you think?

cyp

Re: treatment of prefix arg in `gnus-group-select-group'

[Kai Großjohann]

Cyprian Laskowski <cyp@swagbelly.net> writes:

> 1.  If the group has lots of unread articles, past the threshold where
>     it normally asks me how many articles to fetch, it should not ask
>     me if I provide a prefix argument.  I.e., if I do `10 RET', I
>     should not be asked how many articles to fetch.

This is what happens for me.  I wonder why that does not happen for
you.

> 2.  The prefix argument of 0 should be treated specially: if I do `0
>     RET', Gnus should not bother with any sort of scoring (I'm not
>     sure if it does now) or whatnot, and should immediately just put
>     me in the summary buffer.

Does M-RET do what you want?

>     I sometimes do `0 RET' if I'm just looking for some cached article,
>     and in these cases I don't want to bother fetching new articles.
>     I just want to type `/ *' and see cached articles (which don't
>     require interacting with the server).  In fact, even if the server
>     is totally down, a `0 RET' should work like this, I think.

Hm.  Hmmm...  What about `1 RET'?

kai
-- 
~/.signature: No such file or directory

Re: treatment of prefix arg in `gnus-group-select-group'

[Cyprian Laskowski]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Grossjohann) writes:

> Cyprian Laskowski <cyp@swagbelly.net> writes:
>
>> 1.  If the group has lots of unread articles, past the threshold where
>>     it normally asks me how many articles to fetch, it should not ask
>>     me if I provide a prefix argument.  I.e., if I do `10 RET', I
>>     should not be asked how many articles to fetch.
>
> This is what happens for me.  I wonder why that does not happen for
> you.
>
I don't know why, but it's not a big deal.

>> 2.  The prefix argument of 0 should be treated specially: if I do `0
>>     RET', Gnus should not bother with any sort of scoring (I'm not
>>     sure if it does now) or whatnot, and should immediately just put
>>     me in the summary buffer.
>
> Does M-RET do what you want?
>
M-RET is almost what I want: it'll do.

>>     I sometimes do `0 RET' if I'm just looking for some cached article,
>>     and in these cases I don't want to bother fetching new articles.
>>     I just want to type `/ *' and see cached articles (which don't
>>     require interacting with the server).  In fact, even if the server
>>     is totally down, a `0 RET' should work like this, I think.
>
> Hm.  Hmmm...  What about `1 RET'?
>

1 RET' works well, and And fetching one header doesn't concern me
 (unless the server is toast)! :) I'll just do that when required.

These are not major issues at all, I just thought that maybe I should
 mention them.  And I'm not an exerienced Gnus user :)

Thanks,

cyp