yet more Gnus questions & problems

yet more Gnus questions & problems

[Joe Wells]

Hi, Gnus folks,

First, I have some more questions.  Then I have some minor problem
reports.

Questions:

1. In the group buffer, what can be supplied as the ADDRESS argument of
   "G m"?  An example would be helpful.

2. Can Gnus be made to work with a compressed mail folder via nnfolder?  I
   have a bunch of old mail archives that I would like to keep compressed
   at all times, but also access via Gnus.

3. Where (in what file) do I set the newgroup description for an nndir
   group?  For example, the group
   
     nndir+/ftp@ftp.hpc.uh.edu:/pub/emacs/ding-list-recent/:ding.recent

   which I use to read this mailing list.

4. This is a question about the representation of newsgroup information in
   memory.  Are all marks (tick, dormant, reply, expirable, etc.) kept as
   uncompressed lists in gnus-newsrc-alist?  Are they assumed to be in
   order?  I know they are stored as compressed, ordered sequences in the
   .newsrc.eld file.

   I want to write some code that manipulates these items and I need to
   know:

     a. What assumptions, if any, can I make about the data format of
        marks?  Can I assume the mark lists are always ordered with no
        duplicates?
   
     b. What data format must my code follow in order not to break other
        code?  For example, can I store a compressed sequence for one of
        the mark types?  (I think the answer is no to my example
        question.)

     c. Is is required and/or guaranteed that the ticked and/or dormant
        mark lists do not overlap with the list of read articles?  Are any
        of these sets guaranteed to be non-overlapping?

Minor problem reports for Gnus v5.1:

Gnus v5.1; nntp 4.0; nnml 1.0; nnmh 1.0; nndir 1.0; nndoc 1.0; nnfolder 1.0

1. "M-g" doesn't work inside a digest group.

2. In group buffer, "j foo RET" does not perform completion on "foo".
   Instead it just errors.

3. In summary buffer, if one #-marks part 1 of 2 of a uuencoded thingy,
   then "X u" doesn't fetch both parts.  It seems like it should.

4. In summary buffer, marking multiple articles with # and then doing "X v
   u" seems to decode all of them before starting the viewer for any of
   them.

5. In group buffer, "A k" does not display killed mail groups.  It only
   shows killed groups from the default nntp server.

6. Using nnml, the ~/Mail/newsgroups file needs every line prefixed with
   "nnml:" in order for Gnus to find a mail group's description.  This
   seems logically wrong since inside the backend newsgroups should not
   have the prefix.

7. In group buffer, "C-u C-c C-d" has the side effect of wiping out all
   descriptions for newsgroups from every other server.

-- 
Joe Wells <jbw@cs.bu.edu>

Re: yet more Gnus questions & problems

[Andy Eskilsson]

/ jbw@cs.bu.edu (Joe Wells) wrote:
| 
| 2. Can Gnus be made to work with a compressed mail folder via nnfolder?  I
|    have a bunch of old mail archives that I would like to keep compressed
|    at all times, but also access via Gnus.

I have also been looking for this for a while, I haven't found any
good solution though, using jka-aux might work. Hmm gonna test it
out..

Using normal jka-compr doesn't work because of Gnus doesn't check with
auto-mode-alist (or what it is called) when opening a
nnfolder.. (Would be nice if a folder opened i c++-mode eh ;-)

	/andy

Re: yet more Gnus questions & problems

[Lars Magne Ingebrigtsen]

jbw@cs.bu.edu (Joe Wells) writes:

> 1. In the group buffer, what can be supplied as the ADDRESS argument of
>    "G m"?  An example would be helpful.

It depends on what backend the address is for.  If it's nntp,
"news.uio.no" is a likely address.  If it's nndir
"/ftp@ftp.ifi.uio.no:/pub/emacs/gnus/ding/" is an example.  For
backends like nnml which uses the address for naming purposes only,
"private" or "my-mail" can be used.

> 2. Can Gnus be made to work with a compressed mail folder via nnfolder?  I
>    have a bunch of old mail archives that I would like to keep compressed
>    at all times, but also access via Gnus.

It's a tricky question, believe it or not.  If you have a folder
called "things.like.tex", you obviously don't want to open it in LaTeX
mode.  On the other hand, if you have a folder called "things.gz", you
do want it to be uncompressed, quite likely.  Breakage (on files that
happen to end with ".tex", ".c") is much worse than missing features,
so Gnus (and its backends) regards all files as simple modeless text
files.

There should be a separation in Emacs handling of these issues.  ".gz"
handling is something quite different than ".tex" handling, so there
shoul be a way to suppress the latter while keeping the first.

> 3. Where (in what file) do I set the newgroup description for an nndir
>    group?  For example, the group
>    
>      nndir+/ftp@ftp.hpc.uh.edu:/pub/emacs/ding-list-recent/:ding.recent
> 
>    which I use to read this mailing list.

nndir doesn't really support descriptions very well.

> 4. This is a question about the representation of newsgroup information in
>    memory.  Are all marks (tick, dormant, reply, expirable, etc.) kept as
>    uncompressed lists in gnus-newsrc-alist? 

They're kept as (compressed) ranges in Gnus 5.2.

>    I want to write some code that manipulates these items and I need to
>    know:
> 
>      a. What assumptions, if any, can I make about the data format of
>         marks?  Can I assume the mark lists are always ordered with no
>         duplicates?

`(gnus-info-marks (gnus-get-info "group"))' will return the marks
alist for "group".  Each element in this alist looks like:

(tick (1 . 3) 5 9 (14 . 16))

So it's a range with the mark type consed on.

>      c. Is is required and/or guaranteed that the ticked and/or dormant
>         mark lists do not overlap with the list of read articles?  Are any
>         of these sets guaranteed to be non-overlapping?

This has changed between Gnus 5.1 and Gnus 5.2.  In Gnus 5.1 they were
non-overlapping, which lead to a *lot* of extra work.  In Gnus 5.2
they are just simple marks lists like any other marks -- totally
independent of whether the articles are marked as read or not.  (A
ticked article is normally marked as read in the info, though.)

> 1. "M-g" doesn't work inside a digest group.

What's it supposed to do?  nndoc groups aren't supposed to change...

> 2. In group buffer, "j foo RET" does not perform completion on "foo".
>    Instead it just errors.

`TAB' for completion.  I don't think this is an error.

> 3. In summary buffer, if one #-marks part 1 of 2 of a uuencoded thingy,
>    then "X u" doesn't fetch both parts.  It seems like it should.

No -- when you process-mark an article, `X u' should just fetch that
article.  If you want to fetch a series, don't use `#' first -- just
use `X u' on one of the articles in the series.

> 4. In summary buffer, marking multiple articles with # and then doing "X v
>    u" seems to decode all of them before starting the viewer for any of
>    them.

Yup.  See `gnus-uu-grabbed-file-functions' if you want to change that.

> 5. In group buffer, "A k" does not display killed mail groups.  It only
>    shows killed groups from the default nntp server.

Yup.  Foreign groups aren't kept in the killed list.  It's a feature.
:-)  No, really.

> 6. Using nnml, the ~/Mail/newsgroups file needs every line prefixed with
>    "nnml:" in order for Gnus to find a mail group's description.  This
>    seems logically wrong since inside the backend newsgroups should not
>    have the prefix.

Yup.  Fix in Gnus v5.2.18.

> 7. In group buffer, "C-u C-c C-d" has the side effect of wiping out all
>    descriptions for newsgroups from every other server.

Ditto.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: yet more Gnus questions & problems

[Joe Wells]

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

  >> 4. This is a question about the representation of newsgroup
  >> information in memory.  Are all marks (tick, dormant, reply,
  >> expirable, etc.) kept as uncompressed lists in gnus-newsrc-alist?

  Lars> They're kept as (compressed) ranges in Gnus 5.2.

This changed from Gnus 5.1, right?  When I wrote the code to import the VM
repled marks for Gnus 5.1, I tried to use a compressed range but Gnus
raised an error on this.

  >> 1. "M-g" doesn't work inside a digest group.

  Lars> What's it supposed to do?  nndoc groups aren't supposed to
  Lars> change...

It seems to me that it should do the same as for any other group, i.e.,
exit and reenter the group.  (I was trying to use this to test the effect
of my hooks.)

  >> 3. In summary buffer, if one #-marks part 1 of 2 of a uuencoded
  >> thingy, then "X u" doesn't fetch both parts.  It seems like it
  >> should.

  Lars> No -- when you process-mark an article, `X u' should just fetch
  Lars> that article.  If you want to fetch a series, don't use `#' first
  Lars> -- just use `X u' on one of the articles in the series.

Suppose I want to fetch 5 series, each containing 25 articles.  Following
your advice, I should either type "X u" five times (once for each series)
or mark all 125 articles and then type "X u"?  The first method does not
let me take a coffee break while Gnus is processing and the second
requires me to mark lots of articles and fails if I miss one of them.

I would like to just mark 1 article from each series and type "X u" once
and have Gnus figure out which other articles need to be fetched.

  >> 4. In summary buffer, marking multiple articles with # and then doing
  >> "X v u" seems to decode all of them before starting the viewer for
  >> any of them.

  Lars> Yup.  See `gnus-uu-grabbed-file-functions' if you want to change
  Lars> that.

I looked at the documentation for that ("C-h v
gnus-uu-grabbed-file-functions RET") and it wasn't very clear.  It would
be nice if there was some setting of gnus-view-pseudo-asynchronously or
gnus-view-pseudos that worked.

  >> 5. In group buffer, "A k" does not display killed mail groups.  It
  >> only shows killed groups from the default nntp server.

  Lars> Yup.  Foreign groups aren't kept in the killed list.  It's a
  Lars> feature.  :-) No, really.

I'm confused by why you say this is a feature.  If I kill a mail group
with "C-k", why shouldn't I be able to look at it with "A k"?

-- 
Joe Wells <jbw@cs.bu.edu>

Re: yet more Gnus questions & problems

[Lars Magne Ingebrigtsen]

Joe Wells <jbw@cs.bu.edu> writes:

>   Lars> They're kept as (compressed) ranges in Gnus 5.2.
> 
> This changed from Gnus 5.1, right?

Yup.

>   >> 1. "M-g" doesn't work inside a digest group.
> 
>   Lars> What's it supposed to do?  nndoc groups aren't supposed to
>   Lars> change...
> 
> It seems to me that it should do the same as for any other group, i.e.,
> exit and reenter the group.  (I was trying to use this to test the effect
> of my hooks.)

In general, reentry into ephemeral groups is kinda tricky, so I've now
made Gnus check for that condition and beep the user if she tries to
do that.

> Suppose I want to fetch 5 series, each containing 25 articles.  Following
> your advice, I should either type "X u" five times (once for each series)
> or mark all 125 articles and then type "X u"?  The first method does not
> let me take a coffee break while Gnus is processing and the second
> requires me to mark lots of articles and fails if I miss one of them.
> 
> I would like to just mark 1 article from each series and type "X u" once
> and have Gnus figure out which other articles need to be fetched.

DO an `M P S' before `X u' to mark have Gnus process-mark all series
(in correct order) that have some articles process-marked.

>   Lars> Yup.  See `gnus-uu-grabbed-file-functions' if you want to change
>   Lars> that.
> 
> I looked at the documentation for that ("C-h v
> gnus-uu-grabbed-file-functions RET") and it wasn't very clear.  It would
> be nice if there was some setting of gnus-view-pseudo-asynchronously or
> gnus-view-pseudos that worked.

Those variables only affect pseudo article insertion/handling, not
actions taken while decoding.

>   Lars> Yup.  Foreign groups aren't kept in the killed list.  It's a
>   Lars> feature.  :-) No, really.
> 
> I'm confused by why you say this is a feature.  If I kill a mail group
> with "C-k", why shouldn't I be able to look at it with "A k"?

I know I had a very good reason for doing this, but I can't quite
remember it now.  Hm.  I think it had something to do with, uhm, group
creation and killed list stability.  Yes, that might have been it.  If
you don't save the killed list, it's re-created by looking at all
active groups and subtracting the (un)subscribed groups.  And that
would be inconsistant with having (some) killed foreign groups in the
list of killed groups.  Or something.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

article series (was: yet more Gnus questions & problems)

[Joe Wells]

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

  >> Suppose I want to fetch 5 series, each containing 25 articles.
  >> Following your advice, I should either type "X u" five times (once
  >> for each series) or mark all 125 articles and then type "X u"?  The
  >> first method does not let me take a coffee break while Gnus is
  >> processing and the second requires me to mark lots of articles and
  >> fails if I miss one of them.
  >> 
  >> I would like to just mark 1 article from each series and type "X u"
  >> once and have Gnus figure out which other articles need to be
  >> fetched.

  Lars> DO an `M P S' before `X u' to mark have Gnus process-mark all
  Lars> series (in correct order) that have some articles process-marked.

Thanks for telling me how to do this.

I think this action (the result of "M P S") should be done automatically
by "X u".  What good is it to try to uudecode one fragment of each series?

  Lars> Yup.  Foreign groups aren't kept in the killed list.  It's a
  Lars> feature.  :-) No, really.

  >>  I'm confused by why you say this is a feature.  If I kill a mail
  >> group with "C-k", why shouldn't I be able to look at it with "A k"?

  Lars> I know I had a very good reason for doing this, but I can't quite
  Lars> remember it now.  Hm.  I think it had something to do with, uhm,
  Lars> group creation and killed list stability.  Yes, that might have
  Lars> been it.  If you don't save the killed list, it's re-created by
  Lars> looking at all active groups and subtracting the (un)subscribed
  Lars> groups.  And that would be inconsistant with having (some) killed
  Lars> foreign groups in the list of killed groups.  Or something.

I read the above paragraph several times and it still doesn't make any
sense to me.  What does your reasoning have to do with whether to save
killed mail groups so that they can be inspected with "A k"?

-- 
Joe Wells <jbw@cs.bu.edu>

Re: article series (was: yet more Gnus questions & problems)

[Sudish Joseph]

Joe Wells <jbw@cs.bu.edu> writes:
> I read the above paragraph several times and it still doesn't make any
> sense to me.  What does your reasoning have to do with whether to save
> killed mail groups so that they can be inspected with "A k"?

Well, I remember being happy when they were taken off the killed
list...it was damned hard to get rid of them. :-) I had to edit the
eld file.  I did so because I was afraid of name clashes -- unlike
USENET, it is not guaranteed that the name of a killed mail group will
not show up as a new group.  Whether this is poisonous in itself is
known to God and Lars.

-Sudish 

Re: article series (was: yet more Gnus questions & problems)

[Yair Friedman]

Sudish Joseph <sudish@mindspring.com> writes:

> Well, I remember being happy when they were taken off the killed
> list...it was damned hard to get rid of them. :-) I had to edit the
> eld file.  I did so because I was afraid of name clashes -- unlike
> USENET, it is not guaranteed that the name of a killed mail group will
> not show up as a new group.  Whether this is poisonous in itself is
> known to God and Lars.
> 
> -Sudish 
> 

I see two solutions to this.  The first is to introduce a delete group
operation which will the backend to delete the group. much like B-DEL
does to articles, the other is to expand bogus groups deletion to
the mail backends so they will consider mail groups that does not have
the corresponding files as bogus groups, then you can use b to delete
unwanted mail groups.

--
Yair.

Re: article series (was: yet more Gnus questions & problems)

[Lars Magne Ingebrigtsen]

Yair Friedman <yfriedma@johnbryce.co.il> writes:

> I see two solutions to this.  The first is to introduce a delete group
> operation which will the backend to delete the group. 

`G DEL' deletes a mail group.  `C-k' should not delete anything.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: article series (was: yet more Gnus questions & problems)

[Lars Magne Ingebrigtsen]

Joe Wells <jbw@cs.bu.edu> writes:

> I think this action (the result of "M P S") should be done automatically
> by "X u".  What good is it to try to uudecode one fragment of each series?

Well, you and Gnus may disagree what the series is.  In that case,
doing an automatic `M P S' before the `X u' would be lethal.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: article series (was: yet more Gnus questions & problems)

[Per Abrahamsen]

>>>>> "JW" == Joe Wells <jbw@cs.bu.edu> writes:

JW> I think this action (the result of "M P S") should be done automatically
JW> by "X u".  What good is it to try to uudecode one fragment of each series?

Gnus use heuristics to determine which messages belongs to the same
series.  Sometimes the heuristics are wrong, in which case it is good
to have a way to manually specify the series. 

Re: article series (was: yet more Gnus questions & problems)

[Joe Wells]

    Joe> I think this action (the result of "M P S") should be done
    Joe> automatically by "X u".  What good is it to try to uudecode one
    Joe> fragment of each series?

  Per> Gnus use heuristics to determine which messages belongs to the same
  Per> series.  Sometimes the heuristics are wrong, in which case it is
  Per> good to have a way to manually specify the series.

  Lars> Well, you and Gnus may disagree what the series is.  In that case,
  Lars> doing an automatic `M P S' before the `X u' would be lethal.

I agree that there should be a way to specify things exactly.  99% of the
time there is no need for that.  The keystrokes that handle 99% of the
cases should be short and easy while the keystrokes necessary to handle
the complicated case may be long.

-- 
Joe Wells <jbw@cs.bu.edu>

Re: yet more Gnus questions & problems

[Luc Van Eycken]

Lars Magne Ingebrigtsen writes:
 > jbw@cs.bu.edu (Joe Wells) writes:
 > 
 > > 2. Can Gnus be made to work with a compressed mail folder via nnfolder?  I
 > >    have a bunch of old mail archives that I would like to keep compressed
 > >    at all times, but also access via Gnus.
 > 
 > It's a tricky question, believe it or not.  If you have a folder
 > called "things.like.tex", you obviously don't want to open it in LaTeX
 > mode.  On the other hand, if you have a folder called "things.gz", you
 > do want it to be uncompressed, quite likely.  Breakage (on files that
 > happen to end with ".tex", ".c") is much worse than missing features,
 > so Gnus (and its backends) regards all files as simple modeless text
 > files.
 > 
 > There should be a separation in Emacs handling of these issues.  ".gz"
 > handling is something quite different than ".tex" handling, so there
 > shoul be a way to suppress the latter while keeping the first.

Actually there is a difference in `auto-mode-alist'. Quoting from the
documentation:
> Alist of filename patterns vs corresponding major mode functions.
> Each element looks like (REGEXP . FUNCTION) or (REGEXP FUNCTION NON-NIL).
> (NON-NIL stands for anything that is not nil; the value does not matter.)
> Visiting a file whose name matches REGEXP specifies FUNCTION as the
> mode function to use.  FUNCTION will be called, unless it is nil.
> If the element has the form (REGEXP FUNCTION NON-NIL), then after
> calling FUNCTION (if it's not nil), we delete the suffix that matched
> REGEXP and search the list again for another match.

Modes to preprocess the contents (e.g. jka-compr) use the second form
"(REGEXP FUNCTION NON-NIL)" while ordinary modes (e.g. tex) use the first
form "(REGEXP . FUNCTION)", so you could use it to distinguish between
those two types of modes.

Best regards,

Luc

Re: yet more Gnus questions & problems

[Lars Magne Ingebrigtsen]

Luc Van Eycken <Luc.VanEycken@esat.kuleuven.ac.be> writes:

> Modes to preprocess the contents (e.g. jka-compr) use the second form
> "(REGEXP FUNCTION NON-NIL)" while ordinary modes (e.g. tex) use the first
> form "(REGEXP . FUNCTION)", so you could use it to distinguish between
> those two types of modes.

Good heavens.  Yes, this should work.  I've now added it to the Red
Gnus todo list.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: yet more Gnus questions & problems

[Andy Eskilsson]

/ Lars Magne Ingebrigtsen <larsi@ifi.uio.no> wrote:
| 
| Luc Van Eycken <Luc.VanEycken@esat.kuleuven.ac.be> writes:
| 
| > Modes to preprocess the contents (e.g. jka-compr) use the second form
| > "(REGEXP FUNCTION NON-NIL)" while ordinary modes (e.g. tex) use the first
| > form "(REGEXP . FUNCTION)", so you could use it to distinguish between
| > those two types of modes.
| 
| Good heavens.  Yes, this should work.  I've now added it to the Red
| Gnus todo list.

Hmm this means that it can be possible to use jka-compr in red gnus?
Yehaw!

	/Andy