nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Karl Kleinpaste]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

I changed my environment so that nnml is my primary select method.
This has made a bad interaction between gnus-message-archive-group and
gnus-inews-mark-as-read.

My gnus-message-archive-group consists of (MATCH . GROUP) pairs.  The
interpretation of the GROUP in the absence of a method prefix assumes
that nnarchive will be used, but I want to Gcc right into my nnml
groups, which don't normally have a prefix because they're primary
method groups.  Nonetheless, I can put an "nnml:" prefix on them
anyway, so the storing of articles works as I intended.

However, because of the slight difference in the perception of the
method (implicit method normally, with an exceptional case to avoid
nnarchive interpretation in g-m-a-g), the call to
gnus-group-mark-article-read fails to achieve the marking-as-read
result desired.

I would like to make the following small change in order to get around
this problem, but I'm not sure it won't break something else in the
(probably much more typical) case where the mail backend used for Gcc
is a secondary method.  What's needed is to ensure that, ultimately,
the group is referred to in its most "natural" way, which is to say,
with the implicit method of primary groups.

Could this be reviewed and applied if it's safe?  If it's not safe, is
there an alternative solution?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Gcc mark-as-read fix --]
[-- Type: text/x-patch, Size: 433 bytes --]

--- gnus-msg.el.~1~	Thu Jul 26 01:05:45 2001
+++ gnus-msg.el	Thu Aug  2 11:21:27 2001
@@ -1243,7 +1243,7 @@
 			      group (gnus-status-message method))
 		(sit-for 2))
 	      (when (and group-art gnus-inews-mark-gcc-as-read)
-		(gnus-group-mark-article-read group (cdr group-art)))
+		(gnus-group-mark-article-read (car group-art) (cdr group-art)))
 	      (kill-buffer (current-buffer)))))))))
 
 (defun gnus-inews-insert-gcc ()

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Kai Großjohann]

On Thu, 02 Aug 2001, Karl Kleinpaste wrote:

> My gnus-message-archive-group consists of (MATCH . GROUP) pairs.
> The interpretation of the GROUP in the absence of a method prefix
> assumes that nnarchive will be used, but I want to Gcc right into my
> nnml groups, which don't normally have a prefix because they're
> primary method groups.

What happens if you (setq gnus-message-archive-method gnus-select-method)?

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

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Karl Kleinpaste]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> What happens if you (setq gnus-message-archive-method gnus-select-method)?

Very interesting.  I had never noticed that variable before.

I have to observe that its doc string is very ominous sounding,
suggesting that changing the variable is useless, requiring use of the
server buffer in order to edit the method after the 1st time Gnus is
run.  By itself, that would make the variable's very existence seem
rather useless, because I can't think of anyone who would have thought
to look at this variable before they ever ran Gnus for the 1st time.

The doc string's dark warning notwithstanding, I put a setq into .gnus
and seem to have gotten the result I expect.  I no longer have an
nnarchive server opened at all, and Gcc is being generated without an
explicit method.

And having experimented with the old definition of the function, it
seems to be doing the correct thing now.

Thank you, Kai.  Please disregard the patch.

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Kai Großjohann]

On Thu, 02 Aug 2001, Karl Kleinpaste wrote:

> I have to observe that its doc string is very ominous sounding,

Indeed.  Curious.

How about adding something more practical to this variable?  For
example:

(setq gnus-message-archive-method (gnus-server-to-method "nnimap:"))

This probably does something useful.  Right?

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

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Lars Magne Ingebrigtsen]

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

>> I have to observe that its doc string is very ominous sounding,
>
> Indeed.  Curious.

I think what I meant was that, er, setting the slot values of the
archive server isn't very useful since that won't really do anything.

gnus-message-archive-method's value is 
(nnfolder "archive"
	  (nnfolder-directory "~/Mail/archive")
	  (nnfolder-active-file "~/Mail/archive/active")
	  (nnfolder-get-new-mail nil)
	  (nnfolder-inhibit-expiry t))

Setting `nnfolder-directory' won't do much to alter the archive
server -- you have to edit the server in the server buffer.

But you can set `gnus-message-archive-method' to something completely
different, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But you can set `gnus-message-archive-method' to something completely
> different, though.

How about (setq gnus-message-archive-method "nnfolder:archive") as the
default value?  And then Gnus could create a foreign server like this
with some default values if required.  And then people can frob the
server parameters from the server buffer.

Thoughts?

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

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Lars Magne Ingebrigtsen]

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

> How about (setq gnus-message-archive-method "nnfolder:archive") as the
> default value?  And then Gnus could create a foreign server like this
> with some default values if required.  And then people can frob the
> server parameters from the server buffer.
>
> Thoughts?

Hm...  Sounds like a good idea.

I've made it so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Nevin Kapur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> gnus-message-archive-method's value is 
> (nnfolder "archive"
> 	  (nnfolder-directory "~/Mail/archive")
> 	  (nnfolder-active-file "~/Mail/archive/active")
> 	  (nnfolder-get-new-mail nil)
> 	  (nnfolder-inhibit-expiry t))

My manual does not have nnfolder-inhibit-expiry as virtual server
setting for the nnfolder backend. 

I think the doc string of virtual server parameters should identify
them as such. If I do a `C-h v nnfolder-directory', I see

`nnfolder-directory' is a variable declared in Lisp.
  -- loaded from "nnfolder"

Value: "~/mail/"

Documentation:
The name of the nnfolder directory.

which doesn't give me a clue that I'm not supposed to

(setq nnfolder-directory "~/some-other-dir")

Or am I missing something?

-- 
Nevin

Re: nnml as primary select method /vs/ gnus-inews-mark-gcc-as-read

[Lars Magne Ingebrigtsen]

Nevin Kapur <nevin@jhu.edu> writes:

> I think the doc string of virtual server parameters should identify
> them as such. If I do a `C-h v nnfolder-directory', I see
>
> `nnfolder-directory' is a variable declared in Lisp.
>   -- loaded from "nnfolder"

Sure.  Anybody want to go through the backend variable doc strings and
add a second line saying:

This variable is a virtual server slot.  See the Gnus manual for details.

Or something like that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Doc strings for virtual server params (was Re: nnml as ...)

[Nevin Kapur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Nevin Kapur <nevin@jhu.edu> writes:
>
>> I think the doc string of virtual server parameters should identify
>> them as such. If I do a `C-h v nnfolder-directory', I see
>>
>> `nnfolder-directory' is a variable declared in Lisp.
>>   -- loaded from "nnfolder"
>
> Sure.  Anybody want to go through the backend variable doc strings and
> add a second line saying:
>
> This variable is a virtual server slot.  See the Gnus manual for details.
>
> Or something like that?

Sounds good. I volunteer. Patch coming soon.

-- 
Nevin

Re: Doc strings for virtual server params (was Re: nnml as ...)

[Lars Magne Ingebrigtsen]

Nevin Kapur <nevin@jhu.edu> writes:

> Sounds good. I volunteer. Patch coming soon.

Great!

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen