What do I do to get 'ask-server behaviour when I hit F but not on startup?

What do I do to get 'ask-server behaviour when I hit F but not on startup?

[Greg Stark]

If I set gnus-check-new-newsgroups to a list or 'ask-server then it uses a
better mechanism for getting new newsgroups.  If I don't want it to that
whenever I log in though I should set it to nil, but if I do that then F will
not do the smart thing and I'm worried what it will do.

greg

Re: Alternate realities

[Darren Stalder]

In a brilliant manifestation of diety, Lars Magne Ingebrigtsen said:
>Anyways, I think the pick-and-read interface is only of interest to
>hardened nn users, so I don't really feel like putting in much work on
>it. :-) At least not at the moment. 

Actually, it's for hardened strn users too.  That's where I'm coming
from.  I've even formatted the summary window to look like strn.  I'm
waiting with ba(i)ted breath for the pick-and-read interface.

Darren/Torin
<torin@daft.com> <http://www.daft.com/~torin/>    <tnd@iswp.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Re: What do I do to get 'ask-server behaviour when I hit F but not on startup?

[Lars Magne Ingebrigtsen]

Greg Stark <gsstark@mit.edu> writes:

> If I set gnus-check-new-newsgroups to a list or 'ask-server then it uses a
> better mechanism for getting new newsgroups.  If I don't want it to that
> whenever I log in though I should set it to nil, but if I do that then F will
> not do the smart thing and I'm worried what it will do.

It will do the stupid thing; yes.  September 0.28 will allow a prefix
to the `F' command to force using `ask-server'.  In addition, if
`gnus-read-active-file' is nil or `some', that command will always use
`ask-server'.  (Well, it doesn't make sense not to, does it?)

-- 
Home is where the cat is.

Re: Alternate realities

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> LMI> That's also a definite possibility, although I think people prefer
> LMI> hitting `SPC' to hitting `,'...
> 
> They can use space (and all other article navigations commands) if
> they use `V m' after upping the score of the selected articles. 

But isn't it possible that the user doesn't want the un-picked
articles to be marked as read?  

> In fact, I think using scores is the cleanest solution, since it also
> allows people to use the score files as a method for "pre-selecting"
> articles.

That's true.  I hadn't thought of it that way...  Actually, that fits
in with the limit scheme currently used -- I've now added a new
command (`gnus-uu-mark-over') that puts the process mark on all
articles that have a high score.  

> I suspect picking will become quite popular even outside the hard code
> nn fans.

Perhaps...  It does allow one to concentrate more on just reading the
news, instead of concentrating on avoiding having to read the things
one aren't interested in.  :-)

-- 
Home is where the cat is.

Re: Alternate realities

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> That's also a definite possibility, although I think people prefer
LMI> hitting `SPC' to hitting `,'...

They can use space (and all other article navigations commands) if
they use `V m' after upping the score of the selected articles. 

In fact, I think using scores is the cleanest solution, since it also
allows people to use the score files as a method for "pre-selecting"
articles.

To be really convenient, exiting pick mode should automatically raise
the mark-below threshold temporarily.

Actually the choices of whether you want to use mark-uninteristing or
limit-to-interesting and whether you want
raise-score-of-picked-then-use-high-score-as-interesting and
use-picked-as-interesting should probably be orthogonal.

I suspect picking will become quite popular even outside the hard code
nn fans.

Re: Alternate realities

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> LMI> The problem with using the process marks for that is that it would
> LMI> make it more difficult to execute commands that normally react to the
> LMI> process mark -- like saving articles, for instance.
> 
> One possible way around that would be that:
> 
> 1) When you press `RET' to leave pick mode, all process marks get
>    converted to another secondary mark (e.g. `I' for interesting).
> 
> 2) Make `next-unread' prefer interesting articles.

That would definitely be a possibility, but I think *all* the movement
commands should only go to the "picked" articles, not just
`next-unread'.  Which is something that requires kludges throughout
the code, which is something I don't like to do...  

Anyways, I think the pick-and-read interface is only of interest to
hardened nn users, so I don't really feel like putting in much work on
it.  :-)  At least not at the moment.  

> LMI> I've now added a variable to control whether the summary buffer should
> LMI> disappear when you start reading the articles.  The summary buffer
> LMI> will be limited to the process-marked ("picked") articles first,
> LMI> though. 
> 
> How about making a numeric value for that variable mean: Add this
> number to the picked articles scores.  Then people who like to see the
> full summary can use e.g. `V m' or `,' to move among the picked
> messages.

That's also a definite possibility, although I think people prefer
hitting `SPC' to hitting `,'...

-- 
Home is where the cat is.

Re: Alternate realities

[Jack Vinson]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> I was wondering whether I should add a minor mode the people can use
LMI> in mail groups...  but I'm not sure.  In fact, I'm not sure whether
LMI> adding minor modes to the summary buffers is a good idea at all.
LMI> Isn't changing keymaps around on the user a bit naughty?  Even if the
LMI> user has requested it by switching the minor mode on?

It's a Bad Idea to change the keymaps on people.  I like reading my mail
just as if it were news.  This is part of the fun of a Unified Interface,
isn't it?  If I want Rmail, I should use Rmail.

-- 
   (      "Mmmmmm - coffee"               (   
   ))     Jack Vinson                     ))  
 C|~~|    jvinson@cheux.ecs.umass.edu   C|~~| 
  `--'                                   `--' 

Re: Alternate realities

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> The problem with using the process marks for that is that it would
LMI> make it more difficult to execute commands that normally react to the
LMI> process mark -- like saving articles, for instance.

One possible way around that would be that:

1) When you press `RET' to leave pick mode, all process marks get
   converted to another secondary mark (e.g. `I' for interesting).

2) Make `next-unread' prefer interesting articles.

LMI> I've now added a variable to control whether the summary buffer should
LMI> disappear when you start reading the articles.  The summary buffer
LMI> will be limited to the process-marked ("picked") articles first,
LMI> though. 

How about making a numeric value for that variable mean: Add this
number to the picked articles scores.  Then people who like to see the
full summary can use e.g. `V m' or `,' to move among the picked
messages.

LMI> Making Gnus more "mail-readerly", sort of.  But I don't
LMI> really like the idea, so I'm trying to be as unconvincing as
LMI> possible.  :-)

I'm firmly unconvinced!

LMI> Great!  I've really missed a function like that.  Will it be run on
LMI> all files automatically, or is it something I'll have to call
LMI> explicitly? 

Explicitly.  I guess if the user ask it to write a file to `LP1:',
Emacs shouldn't implicitly convert the name to `LP1_'.

Re: Alternate realities

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> LMI> Then you press `RET', the
> LMI> summary buffer disappears (after being limited to the articles you've
> LMI> chosen) and you do all reading from the article buffer.
> 
> I think I'd prefer to stay in the summary buffer.  One way to do that
> might be to make the `next-unread' commands always prefer articles
> with a process mark over unmarked articles.

The problem with using the process marks for that is that it would
make it more difficult to execute commands that normally react to the
process mark -- like saving articles, for instance.

I've now added a variable to control whether the summary buffer should
disappear when you start reading the articles.  The summary buffer
will be limited to the process-marked ("picked") articles first,
though. 

> LMI> I was wondering whether I should add a minor mode the people can use
> LMI> in mail groups...  but I'm not sure.  
> 
> Maybe if you told us what the mode should do?

Uhm... moving the `B' commands to one-key keystrokes.  `B DEL' -
`DEL', `B m' -> `m', etc.  Perhaps not marking mail as read when you
read it.  Making Gnus more "mail-readerly", sort of.  But I don't
really like the idea, so I'm trying to be as unconvincing as
possible.  :-)

> LMI> File name translation (":" -> "_") now works everywhere.
> 
> Emacs 19.31 will have a `convert-standard-filename' function.  If you
> use that instead (and provide a dummy when absent) you won't have to
> change anything for future Emacs ports.

Great!  I've really missed a function like that.  Will it be run on
all files automatically, or is it something I'll have to call
explicitly? 

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: Alternate realities

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> The first is an (I think) tin thingie -- you first pick the articles
LMI> you want to read, and then you start reading.  

I'm pretty sure this was pioneered by Kim Storm and his NN newsreader.

LMI> Then you press `RET', the
LMI> summary buffer disappears (after being limited to the articles you've
LMI> chosen) and you do all reading from the article buffer.

I think I'd prefer to stay in the summary buffer.  One way to do that
might be to make the `next-unread' commands always prefer articles
with a process mark over unmarked articles.

LMI> I was wondering whether I should add a minor mode the people can use
LMI> in mail groups...  but I'm not sure.  

Maybe if you told us what the mode should do?

LMI> In fact, I'm not sure whether
LMI> adding minor modes to the summary buffers is a good idea at all.
LMI> Isn't changing keymaps around on the user a bit naughty?  Even if the
LMI> user has requested it by switching the minor mode on?

Not if you use `minor-mode-map-alist'.  The user can always redefine
the keymap then.

LMI> File name translation (":" -> "_") now works everywhere.

Emacs 19.31 will have a `convert-standard-filename' function.  If you
use that instead (and provide a dummy when absent) you won't have to
change anything for future Emacs ports.

Alternate realities

[Lars Magne Ingebrigtsen]

I have written two new minor modes for the summary buffers.  

The first is an (I think) tin thingie -- you first pick the articles
you want to read, and then you start reading.  I've called it
`gnus-pick-mode'.  All it does is make process-mark commands become
one-key commands, so you have `t' to mark a thread, `r' to mark a
region and `SPC' to mark a single article.  Then you press `RET', the
summary buffer disappears (after being limited to the articles you've
chosen) and you do all reading from the article buffer.

The other is a minor mode for binary groups -- `gnus-binary-mode'.
All article selection commands (except `g') uudecode-and-view instead
of selecting articles the normal way.  So you just type `n' instead of
`X u', `n', `RET' to decode.

I was wondering whether I should add a minor mode the people can use
in mail groups...  but I'm not sure.  In fact, I'm not sure whether
adding minor modes to the summary buffers is a good idea at all.
Isn't changing keymaps around on the user a bit naughty?  Even if the
user has requested it by switching the minor mode on?

Let's see...  while I'm at it, I can summarize some of the other new
thingies:

nnml now accepts .gz files (and friends).  

A `0' prefix to `C-c C-c' in a *post-news* buffer will prompt the user
for a post method from the aviable select methods.

nnmail mail duplication has been changed to warn the user about
duplicated mail, if wanted.

nnvirtual allows caching articles, and you can now have auto-expirable
component groups.  And posting/mailing in virtual groups now works ok.
In fact, nnvirtual has been totally rewritten, and is now much slower.
:-) But articles from all component groups are now intermingled
instead of (as it was before) first listing articles from component
group a, then component group b, etc.

You can execute actions based on the nntp server type you connect to.

There's a new command for topicsifying all active groups.

You can gather loose threads by looking at articles that share common
Message-IDs in the References header.

`frame' now works in `gnus-buffer-configuration'.

File name translation (":" -> "_") now works everywhere.

`gnus-article-hide-boring-headers' -- new function.

nndoc understands ClariNet briefs.

And stuff.

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)