Outstanding stuff?

Outstanding stuff?

[Lars Magne Ingebrigtsen]

I have a feeling that there was a couple of things that I said I was
going to look into, but I've forgotten what...

Any outstanding bugs or annoyances?

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

Re: Outstanding stuff?

[Steinar Bang]

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

> Any outstanding bugs or annoyances?

Sometimes the scrollbar indicates that the articles are much bigger than
they are, and when I hit space to see the rest of the article, instead I
skip  to the next unread article.

I haven't investigated closely, but I'm guessing this has to do with
multipart/alterntive messages with a text/plain and a text/html part,
and the scrollbar is sized up for the undecoded message, and what's
visible is only part of it.

Another annoyance is that nnimap and agent don't work well yet.
Sometimes I get NOV information instead of a downloaded message, in the
cached articles.

And I've set up agent to cache articles when they are read.  However,
the articles are only downloaded when they are read for the first time.
If an uncached ticked article is visited, nothing is downloaded.

This used to work earlier, at least I think so, because I've used it to
cache up ticked articles on the netbook before going offline somewhere.
(but I haven't actually verified with an old version)

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Sometimes the scrollbar indicates that the articles are much bigger than
> they are, and when I hit space to see the rest of the article, instead I
> skip  to the next unread article.
>
> I haven't investigated closely, but I'm guessing this has to do with
> multipart/alterntive messages with a text/plain and a text/html part,
> and the scrollbar is sized up for the undecoded message, and what's
> visible is only part of it.

No, this is just an Emacs/gtk scrollbar bug -- there's oodles of bug
reports about this in the Emacs data base.

> Another annoyance is that nnimap and agent don't work well yet.
> Sometimes I get NOV information instead of a downloaded message, in the
> cached articles.

Hm.  Do you have a recipe for how to reproduce this?

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

Re: Outstanding stuff?

[Steinar Bang]

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

> Steinar Bang <sb@dod.no> writes:

> No, this is just an Emacs/gtk scrollbar bug -- there's oodles of bug
> reports about this in the Emacs data base.

Ah, ok.  Quite possibly I've been told this before.

>> Another annoyance is that nnimap and agent don't work well yet.
>> Sometimes I get NOV information instead of a downloaded message, in the
>> cached articles.

> Hm.  Do you have a recipe for how to reproduce this?

The NOV stuff?  Not reliably.

You could try to delete an article to the agent cache, and then try to
make agent download it again.

Another thing that may be the cause of this is my agent-cache-on-read
setting: 
 (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)

Re: Outstanding stuff?

[Tibor Simko]

On Tue, 19 Oct 2010, Steinar Bang wrote:
> This used to work earlier, at least I think so, because I've used it to
> cache up ticked articles on the netbook before going offline somewhere.
> (but I haven't actually verified with an old version)

IIRC it did work like that indeed, but I have not re-verified either.
(BTW I'm running new nnimap without agent still.)

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Dan Christensen]

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

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...

I think you said that you were going to implement article editing in
nnimap, right? 

(I'm half-joking, because I thought I might implement it, but am too
swamped at the moment to even consider it.  Still, I think it should
be just a dozen or so lines of code...)

Dan

Re: Outstanding stuff?

[Ted Zlatanov]

On Tue, 19 Oct 2010 20:24:07 -0400 Dan Christensen <jdc@uwo.ca> wrote: 

DC> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> I have a feeling that there was a couple of things that I said I was
>> going to look into, but I've forgotten what...

DC> I think you said that you were going to implement article editing in
DC> nnimap, right? 

DC> (I'm half-joking, because I thought I might implement it, but am too
DC> swamped at the moment to even consider it.  Still, I think it should
DC> be just a dozen or so lines of code...)

This has my vote too.  Plus I'd get rid of drafts altogether (the code
that deals with them has caused many bug reports and has too many
special cases) and just use regular groups with a draft-mode parameter.

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> This has my vote too.  Plus I'd get rid of drafts altogether (the code
> that deals with them has caused many bug reports and has too many
> special cases) and just use regular groups with a draft-mode parameter.

Storing drafts locally seems quite useful to me.  It avoids network
problems and the like.

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

Re: Outstanding stuff?

[Ted Zlatanov]

On Wed, 20 Oct 2010 19:34:38 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> This has my vote too.  Plus I'd get rid of drafts altogether (the code
>> that deals with them has caused many bug reports and has too many
>> special cases) and just use regular groups with a draft-mode parameter.

LMI> Storing drafts locally seems quite useful to me.  It avoids network
LMI> problems and the like.

Drafts could still be stored in nnfolder or whatever, only they won't
require a special backend.

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Drafts could still be stored in nnfolder or whatever, only they won't
> require a special backend.

nndraft is based on nnmh, which is the simplest backend possible, and
allows auto-saving things without going through a lot of code, which is
important if Emacs crashes and the like.

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

Re: Outstanding stuff?

[Ted Zlatanov]

On Wed, 20 Oct 2010 20:03:27 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Drafts could still be stored in nnfolder or whatever, only they won't
>> require a special backend.

LMI> nndraft is based on nnmh, which is the simplest backend possible, and
LMI> allows auto-saving things without going through a lot of code, which is
LMI> important if Emacs crashes and the like.

OK.

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I think you said that you were going to implement article editing in
> nnimap, right? 

So the problem is that IMAP doesn't allow editing?  So we'd have to call
`-accept-article', delete the old, insert the new in the summary buffer?
Sounds doable...

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

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

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

> So the problem is that IMAP doesn't allow editing?  So we'd have to call
> `-accept-article', delete the old, insert the new in the summary buffer?
> Sounds doable...

Three hours later: ARGH!

It sort of works now.  Sort of.  If you don't have threading switched
on.  So you can now edit nnimap articles, but it'll error out if you
have threads.  And I'm just not able to find out why.

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

Re: Outstanding stuff?

[Dan Christensen]

[Just upgraded to git after a month when real life was too busy.]

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

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> So the problem is that IMAP doesn't allow editing?  So we'd have to call
>> `-accept-article', delete the old, insert the new in the summary buffer?
>> Sounds doable...
>
> Three hours later: ARGH!

Yikes, sorry to hear this.

> It sort of works now.  Sort of.  If you don't have threading switched
> on.  So you can now edit nnimap articles, but it'll error out if you
> have threads.  And I'm just not able to find out why.

I use threading, but am not getting errors.  However, point doesn't go
to the right article, and in general things seem a bit messed up in the
summary buffer.  E.g. `P' jumps to a strange article.  Some other
articles sometimes show up as deleted when I try to select them, but
then are there if I exit and reenter.  So it seems like some internal
data structure gets mangled.   This all happens even with threading
turned off...

I'm curious why this is much different from when a new article arrives
and we hit `/ N' to include it in the summary buffer.  My attempt to
code this up before (with the old nnimap) was pretty similar and
seemed to work a bit better:

(deffoo nnimap-request-replace-article (article group buffer)
  (and (with-current-buffer buffer
         (nnimap-request-accept-article group))

       (nnimap-possibly-change-group group)
       (imap-message-flags-add
        (imap-range-to-message-set (list article))
        "\\Deleted" 'silent nnimap-server-buffer)

       (set-buffer gnus-summary-buffer)
       (gnus-summary-goto-subject article)
       (gnus-summary-mark-article article gnus-canceled-mark)
       (gnus-summary-insert-new-articles)
       ;(gnus-summary-position-point)
       ;(gnus-set-mode-line 'summary)
))

But it still needed work:

- didn't copy marks
- didn't remove old article from summary
- didn't position point at new article

I also had a plan to re-use the code in gnus-summary-move-article, with
a global flag set so that it skips doing an internal move, and when it
accepts the new article, it takes it from the editing buffer instead of
from the old version of the article.  I couldn't get it to work, but it
seems like it should work in principle.

Being able to strip attachments is crucial to me, so if there's anything
I can do to help debug this, let me know.

Dan

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> So it seems like some internal data structure gets mangled.

Yup.

> This all happens even with threading turned off...

Huh.  I thought it kinda worked with threading off...

> I'm curious why this is much different from when a new article arrives
> and we hit `/ N' to include it in the summary buffer.

Mainly because the Message-ID remains the same, while `/ N' doesn't have
that problem.  I think.  Or I may just be thinking about this the wrong
way.  It's entirely possible.

>        (gnus-summary-insert-new-articles)

Hm...  perhaps I could give gnus-summary-insert-articles a try.

[tests]

Nope, didn't seem to work...

> Being able to strip attachments is crucial to me, so if there's anything
> I can do to help debug this, let me know.

Well, if you can find out why it doesn't work, that'd be great.  :-)

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

Re: Outstanding stuff?

[Dan Christensen]

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

>> I'm curious why this is much different from when a new article arrives
>> and we hit `/ N' to include it in the summary buffer.
>
> Mainly because the Message-ID remains the same, while `/ N' doesn't have
> that problem.  I think.  Or I may just be thinking about this the wrong
> way.  It's entirely possible.

If I `B c' an article from the current group to itself, then `/ N' seems
to have no trouble, even though there are duplicate message IDs.

>> Being able to strip attachments is crucial to me, so if there's anything
>> I can do to help debug this, let me know.
>
> Well, if you can find out why it doesn't work, that'd be great.  :-)

I wonder if the following is related:  in any nnimap group, select the
most recent article (which for me is at the bottom), then hit `N'.  When
I do this, point jumps to the oldest message, which is displayed as
cancelled, and I get the message:

  No such article (may have expired or been canceled)

After this, further pressing `N' jumps point around in what seems like
a random way.

Dan

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I wonder if the following is related:  in any nnimap group, select the
> most recent article (which for me is at the bottom), then hit `N'.  When
> I do this, point jumps to the oldest message, which is displayed as
> cancelled, and I get the message:
>
>   No such article (may have expired or been canceled)
>
> After this, further pressing `N' jumps point around in what seems like
> a random way.

Heh.  It's not just nnimap groups -- it's in all groups.  If you, say,
tick the second-to-last article in a group, and have all the rest read,
exit and enter the group, and then hit `N', then navigation afterwards
in the summary buffer is all weird.

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

Re: Outstanding stuff?

[Julien Danjou]

On Tue, Oct 19 2010, Lars Magne Ingebrigtsen wrote:

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...
>
> Any outstanding bugs or annoyances?

I just saw that (setq gnus-gcc-mark-as-read t) does not work with
nnimap.

On computer #1, where I sent the message from, I see no problem. But on
computer #2 or on a webmail, I really see the message in the sent
mailboxes as unread (they have no IMAP \Seen flags).

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> I just saw that (setq gnus-gcc-mark-as-read t) does not work with
> nnimap.

Could you try to debug why this is happening?  I've had a peek at the
code, and it kinda looks like it should work for all backends.

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

Re: Outstanding stuff?

[Julien Danjou]

On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:

> Could you try to debug why this is happening?  I've had a peek at the
> code, and it kinda looks like it should work for all backends.

I should be smart enough to, so I will!

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Dave Goldberg]

>>> I just saw that (setq gnus-gcc-mark-as-read t) does not work with
>>> nnimap.

I can say that I am not able to repeat this problem.  My gcc's are
properly marked as read on both my cyrus and exchange servers.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Outstanding stuff?

[Dan Christensen]

Dave Goldberg <david.goldberg6@verizon.net> writes:

>>>> I just saw that (setq gnus-gcc-mark-as-read t) does not work with
>>>> nnimap.
>
> I can say that I am not able to repeat this problem.  My gcc's are
> properly marked as read on both my cyrus and exchange servers.

And it works for me on dovecot.

Dan

Re: Outstanding stuff?

[Julien Danjou]

On Thu, Oct 21 2010, Julien Danjou wrote:

> I should be smart enough to, so I will!

I found the problem. It's subtle.

My Gcc folder was a folder I was not subscribed too. It was a mistake I
made, so now I subscribed to it and it "fixes" the problem.

How I found that it was that and why it did not work, it's because Gnus
fails here:

(defun gnus-group-make-articles-read (group articles)
  "Update the info of GROUP to say that ARTICLES are read."
  (let* ((num 0)
	 (entry (gnus-group-entry group))
	 (info (nth 2 entry))
	 (active (gnus-active group))
	 range)
    (when entry
    [...=

`entry' is nil because my gcc folder is not in hashtb. Therefore the
code does nothing and does not mark the message as read.

I don't know how that's fixable?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> My Gcc folder was a folder I was not subscribed too. It was a mistake I
> made, so now I subscribed to it and it "fixes" the problem.
>
> How I found that it was that and why it did not work, it's because Gnus
> fails here:

This is possibly fixed now.

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

Re: Outstanding stuff?

[Robert Pluim]

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

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...
>
> Any outstanding bugs or annoyances?

Imap annoyance: B-m issues 7 imap commands for every message it
moves, including setting the deleted flag and expunging the source
mailbox after every move, which makes it dog-slow. Would it be possible
to batch some of the commands up, or do the expunge only at the end?
From my imap log buffer:

11:17:04 115 SELECT "source"
11:17:04 116 UID FETCH 19837 BODY.PEEK[]
11:17:04 117 UID COPY 19837 "dest"
11:17:04 118 UID STORE 19837 +FLAGS.SILENT (\Deleted)
11:17:05 119 EXPUNGE
11:17:05 120 EXAMINE "dest"
11:17:05 121 UID SEARCH HEADER Message-Id "<number@myserver.foo>"

Actually, now that I've read the relevant section of the IMAP rfc for
the first time in my life, I'm more suspicious about the BODY.PEEK[]
thing, doesn't that download the entire message? Surely at most the
headers are required?

Thanks

Robert

Re: Outstanding stuff?

[Ted Zlatanov]

On Wed, 20 Oct 2010 11:34:00 +0200 Robert Pluim <rpluim@gmail.com> wrote: 

RP> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> I have a feeling that there was a couple of things that I said I was
>> going to look into, but I've forgotten what...
>> 
>> Any outstanding bugs or annoyances?

RP> Imap annoyance: B-m issues 7 imap commands for every message it
RP> moves, including setting the deleted flag and expunging the source
RP> mailbox after every move, which makes it dog-slow. Would it be possible
RP> to batch some of the commands up, or do the expunge only at the end?
RP> From my imap log buffer:

RP> 11:17:04 115 SELECT "source"
RP> 11:17:04 116 UID FETCH 19837 BODY.PEEK[]
RP> 11:17:04 117 UID COPY 19837 "dest"
RP> 11:17:04 118 UID STORE 19837 +FLAGS.SILENT (\Deleted)
RP> 11:17:05 119 EXPUNGE
RP> 11:17:05 120 EXAMINE "dest"
RP> 11:17:05 121 UID SEARCH HEADER Message-Id "<number@myserver.foo>"

RP> Actually, now that I've read the relevant section of the IMAP rfc for
RP> the first time in my life, I'm more suspicious about the BODY.PEEK[]
RP> thing, doesn't that download the entire message? Surely at most the
RP> headers are required?

On Wed, 20 Oct 2010 12:49:54 +0200 Steinar Bang <sb@dod.no> wrote: 

SB> Does nnimap move of articles between folders work reliably?

It works all right, but I'll second Robert's report.  Moving articles
with nnimap is really really slow for the reasons he described (all of
the ops are done once per article).

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Actually, now that I've read the relevant section of the IMAP rfc for
> the first time in my life, I'm more suspicious about the BODY.PEEK[]
> thing, doesn't that download the entire message? Surely at most the
> headers are required?

Yes, and I've now made that change, so I now get this pattern:

19:05:12 1086 SELECT "efn"
19:05:12 1087 UID FETCH 42 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
19:05:12 1088 UID COPY 42 "Test"
19:05:12 1089 UID STORE 42 +FLAGS.SILENT (\Deleted)
19:05:12 1090 EXPUNGE
19:05:12 1091 EXAMINE "Test"
19:05:12 1092 UID SEARCH HEADER Message-Id "<alpine.LRH.2.00.1009181734090.29309@luke.ifi.uio.no>"
19:05:12 1093 SELECT "Test"
19:05:12 1094 UID STORE 4 +FLAGS.SILENT (\Seen)
19:05:12 1095 SELECT "Test"
19:05:12 1096 UID FETCH 1:* FLAGS

Which is still way excessive, but let's examine it and consider what our
options are for speeding this up.

19:05:12 1086 SELECT "efn"

Can't be removed, but could (in theory) happen once.

19:05:12 1087 UID FETCH 42 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
19:05:12 1091 EXAMINE "Test"
19:05:12 1092 UID SEARCH HEADER Message-Id "<alpine.LRH.2.00.1009181734090.29309@luke.ifi.uio.no>"

We need the Message-ID of the message if we're going to return the
article number.  The question is: Do we need the article number, and the
answer is "kinda".  If the method is covered by the Agent, or the
message is cached, or whatever, then we need to know the new article
number so that we can do the right things there.  We also update the
marks in Gnus immediately, so we need the article number for that too,
although we could do without, since the next `g' will update Gnus
wrt. the target group anyway.  (If that group allows flags.)

So: If we want a sloppier not-quite-coherent update, we could get rid of
those.

19:05:12 1088 UID COPY 42 "Test"

Can't be removed.  :-)

19:05:12 1089 UID STORE 42 +FLAGS.SILENT (\Deleted)

Could be batched.

19:05:12 1090 EXPUNGE

Could easily be postponed until the last move.

19:05:12 1093 SELECT "Test"
19:05:12 1094 UID STORE 4 +FLAGS.SILENT (\Seen)

This is probably superfluous?  IMAP probably copies over all the marks
anyway? 

19:05:12 1095 SELECT "Test"
19:05:12 1096 UID FETCH 1:* FLAGS

I have no idea what's this is about.

Oh, it's this thing at the end:

    ;; Re-activate all groups that have been moved to.
    (with-current-buffer gnus-group-buffer
      (let ((gnus-group-marked to-groups))
	(gnus-group-get-new-news-this-group nil t)))

But that's only done once per move.        

So I'm not sure how much faster things could be without making things
kinda weird.

HOWEVER, we could just cheat and totally special-case things for
nnimap.  That is, a new interface function

(*-request-move-articles-internally articles from-group server to-group)

If it exists, and the move is internal (from one group on the same IMAP
server to another), this would just issue COPY + \Deleted + EXPUNGE, and
forget about all Gnus niceties with the cache/agent/etc.

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

Re: Outstanding stuff?

[Robert Pluim]

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

> 19:05:12 1088 UID COPY 42 "Test"
>
> Can't be removed.  :-)

But could be batched, no? That 42 there is allowed to be a sequence
specifier, I think.

> 19:05:12 1093 SELECT "Test"
> 19:05:12 1094 UID STORE 4 +FLAGS.SILENT (\Seen)
>
> This is probably superfluous?  IMAP probably copies over all the marks
> anyway? 

I'm not too fussed if it doesn't preserve marks.

> HOWEVER, we could just cheat and totally special-case things for
> nnimap.  That is, a new interface function
>
> (*-request-move-articles-internally articles from-group server to-group)
>
> If it exists, and the move is internal (from one group on the same IMAP
> server to another), this would just issue COPY + \Deleted + EXPUNGE, and
> forget about all Gnus niceties with the cache/agent/etc.

That would work for me. In this particular case speed is more important
to me than features :-)

Robert

Re: Outstanding stuff?

[Steinar Bang]

>>>>> Robert Pluim <rpluim@gmail.com>:

>> This is probably superfluous?  IMAP probably copies over all the
>> marks anyway?

> I'm not too fussed if it doesn't preserve marks.

If we're talking nnimap moves here: I am fuzzy about preserving marks.

Re: Outstanding stuff?

[Adam Sjøgren]

On Mon, 25 Oct 2010 19:12:42 +0200, Steinar wrote:

>>>>>> Robert Pluim <rpluim@gmail.com>:

>> I'm not too fussed if it doesn't preserve marks.

> If we're talking nnimap moves here: I am fuzzy about preserving marks.

Fuzzy¹ or fussy²?

The chirality makes quite a difference in this case.


  :-),

   Adam

¹ http://www.merriam-webster.com/dictionary/fussy
² http://www.merriam-webster.com/dictionary/fuzzy

-- 
 "The unavoidable price of reliability is simplicity"         Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Outstanding stuff?

[Steinar Bang]

>>>>> asjo@koldfront.dk (Adam Sjøgren):

> On Mon, 25 Oct 2010 19:12:42 +0200, Steinar wrote:
>>>>>>> Robert Pluim <rpluim@gmail.com>:

>>> I'm not too fussed if it doesn't preserve marks.

>> If we're talking nnimap moves here: I am fuzzy about preserving marks.

> Fuzzy¹ or fussy²?

> ¹ http://www.merriam-webster.com/dictionary/fussy
> ² http://www.merriam-webster.com/dictionary/fuzzy

Right.  That's Fussy¹ (I believe you misplaced the superscripts...?).

Specifically meaning 3a, I think...? (that's the closest match).

Re: Outstanding stuff?

[Adam Sjøgren]

On Mon, 25 Oct 2010 22:08:28 +0200, Steinar wrote:

> Right.  That's Fussy¹ (I believe you misplaced the superscripts...?).

(They were fuzzy ;-))

-- 
 "Écoutez la colere du peuple"                                Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Outstanding stuff?

[Steinar Bang]

>>>>> Robert Pluim <rpluim@gmail.com>:

>> HOWEVER, we could just cheat and totally special-case things for
>> nnimap.  That is, a new interface function
>> 
>> (*-request-move-articles-internally articles from-group server to-group)
>> 
>> If it exists, and the move is internal (from one group on the same IMAP
>> server to another), this would just issue COPY + \Deleted + EXPUNGE, and
>> forget about all Gnus niceties with the cache/agent/etc.

> That would work for me. In this particular case speed is more
> important to me than features :-)

What will it mean wrt. to uniformity for copies and moves across
backends?  Will it still be possible to split from nnimap to eg. nnml
folders? 

Re: Outstanding stuff?

[Robert Pluim]

Steinar Bang <sb@dod.no> writes:

>>>>>> Robert Pluim <rpluim@gmail.com>:
>
>>> HOWEVER, we could just cheat and totally special-case things for
>>> nnimap.  That is, a new interface function
>>> 
>>> (*-request-move-articles-internally articles from-group server to-group)
>>> 
>>> If it exists, and the move is internal (from one group on the same IMAP
>>> server to another), this would just issue COPY + \Deleted + EXPUNGE, and
>>> forget about all Gnus niceties with the cache/agent/etc.
>
>> That would work for me. In this particular case speed is more
>> important to me than features :-)
>
> What will it mean wrt. to uniformity for copies and moves across
> backends?  Will it still be possible to split from nnimap to eg. nnml
> folders? 

I don't think nnimap -> nnml would qualify for the 'on the same IMAP
server' statement Lars made there.

Robert

Re: Outstanding stuff?

[Steinar Bang]

>>>>> Robert Pluim <rpluim@gmail.com>:

> I don't think nnimap -> nnml would qualify for the 'on the same IMAP
> server' statement Lars made there.

Me neither (as in "don't think").  But I would like to hear it from the
horse's mouth, so to speak.

Specifically: will this harm the cross-backend interoperability, or is
this something that won't affect that, but will same-server nnimap
operations be faster? (which I'm all for, btw.  I'm a long time nnimap
user.  But I've also found cross-backend moves and copies useful over
the years...)

Re: Outstanding stuff?

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Me neither (as in "don't think").  But I would like to hear it from the
> horse's mouth, so to speak.

Hm,... that sounded like I was demanding an answer, and that wasn't how
I intended it to come out.

It's just that I think it would be good if backend transparency isn't
adversely impacted.

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Me neither (as in "don't think").  But I would like to hear it from the
> horse's mouth, so to speak.

*neigh*

> Specifically: will this harm the cross-backend interoperability, or is
> this something that won't affect that, but will same-server nnimap
> operations be faster?

The latter.

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

Re: Outstanding stuff?

[Ted Zlatanov]

On Sun, 24 Oct 2010 19:20:00 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> We need the Message-ID of the message if we're going to return the
LMI> article number.  The question is: Do we need the article number, and the
LMI> answer is "kinda".  If the method is covered by the Agent, or the
LMI> message is cached, or whatever, then we need to know the new article
LMI> number so that we can do the right things there.  We also update the
LMI> marks in Gnus immediately, so we need the article number for that too,
LMI> although we could do without, since the next `g' will update Gnus
LMI> wrt. the target group anyway.  (If that group allows flags.)

LMI> So: If we want a sloppier not-quite-coherent update, we could get rid of
LMI> those.

If Gnus (and Emacs) were multithreaded this would be a great place to
use it.  Do you think this can be done with async messages (IMAP allows
it, obviously, but Gnus would need to update things as replies arrive)?

Maybe the whole IMAP interaction should be designed as an async queue
(with the option to insert at either end) rather than a command-reply
serial stream.

LMI> HOWEVER, we could just cheat and totally special-case things for
LMI> nnimap.  That is, a new interface function

LMI> (*-request-move-articles-internally articles from-group server to-group)

LMI> If it exists, and the move is internal (from one group on the same IMAP
LMI> server to another), this would just issue COPY + \Deleted + EXPUNGE, and
LMI> forget about all Gnus niceties with the cache/agent/etc.

The Gnus registry should be updated, but it doesn't need the article
number.  For a move from A to B, it only needs to be told the message ID
is no longer in group A and is now in group B.  Right now it does that
with a hook that you will bypass with this special function.

I am suspicious of such special functions.  If there's a way to make
moves faster, shouldn't all backends benefit from it?

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Maybe the whole IMAP interaction should be designed as an async queue
> (with the option to insert at either end) rather than a command-reply
> serial stream.

I think we really need to wait until the moving has finished, so that we
can tell the user whether something failed or not.  And stuff.

> LMI> (*-request-move-articles-internally articles from-group server to-group)

[...]

> I am suspicious of such special functions.  If there's a way to make
> moves faster, shouldn't all backends benefit from it?

Any backends where this would make sense could implement the new
function.  But I don't really think this matters much for anything other
than IMAP.

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

Re: Outstanding stuff?

[Dan Christensen]

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

> HOWEVER, we could just cheat and totally special-case things for
> nnimap.  That is, a new interface function
>
> (*-request-move-articles-internally articles from-group server to-group)
>
> If it exists, and the move is internal (from one group on the same IMAP
> server to another), this would just issue COPY + \Deleted + EXPUNGE, and
> forget about all Gnus niceties with the cache/agent/etc.

I'm not sure this is a good idea.  I certainly don't find nnimap moves
too slow currently, and wouldn't have to lose features.

Maybe the best thing would be to try the speed improvements that I cut
out of the above (the ones that don't affect the features) first, to see
if they are sufficient for the people for whom speed is an issue.

Dan

Re: Outstanding stuff?

[Steinar Bang]

>>>>> Dan Christensen <jdc@uwo.ca>:

> I'm not sure this is a good idea.  I certainly don't find nnimap moves
> too slow currently, and wouldn't have to lose features.

On losing features: the problem for me personally, would be if this
messes up things with the agent.  I don't know what would happen?  Would
I get "ghosts" in the old group, because nothing cleans out the NOV
file?  (and ideally also deletes the downloaded article, though I don't
know that this happens today...?)

If it only means that the moved articles won't be cached, then that's
ok.  That's the current behaviour anyway.

> Maybe the best thing would be to try the speed improvements that I cut
> out of the above (the ones that don't affect the features) first, to
> see if they are sufficient for the people for whom speed is an issue.

Well, on the other hand, the biggest speed improvements you could get on
moves, would be to just tell the server to copy, delete the originals,
and expunge the originals, without downloading a single article...

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> On losing features: the problem for me personally, would be if this
> messes up things with the agent.  I don't know what would happen?

The fast move won't be done if the method is covered by the agent.

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

Re: Outstanding stuff?

[Steinar Bang]

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

> The fast move won't be done if the method is covered by the agent.

Hm... it feels like agent support is dwindling in the new era.

Granted, the agent isn't as important speedwise, as it used to be.

But it was nice to be able to read and respond to email offline.

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>> The fast move won't be done if the method is covered by the agent.
>
> Hm... it feels like agent support is dwindling in the new era.

You can still use the agent -- moves will be as slow as now, but... 

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

Re: Outstanding stuff?

[Steinar Bang]

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

> You can still use the agent -- moves will be as slow as now, but... 

Any chance of seeing any agent improvements while you're on this roll?

Agent improvements (was: Outstanding stuff?)

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Any chance of seeing any agent improvements while you're on this roll?

Anything in particular you have in mind?

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

Re: Agent improvements

[Steinar Bang]

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

> Steinar Bang <sb@dod.no> writes:

>> Any chance of seeing any agent improvements while you're on this roll?

> Anything in particular you have in mind?

In order of (my) priority:
 - Make the agent stash article when downloading stuff work again (I
   plan to do some edebug'ing on that... one of these days..)
 - Don't let nnimap+agent be a blocker to fast moves/copies when online
   during the move
 - Allow nnimap agent offline delete, copy, and move (synchronize when
   online, and it would be nice of the synchronization could use fast
   server side operations)
 - Keep agent synchronized during deletes, copies and moves done when
   online (it's only the deletes that are important actually, I can live
   with articles moved to a different folder not actually being
   downloaded until I take action to make it so.  That's the way it
   always has been, actually)
 - Make expire handle the agent cached article (should follow by the
   previous item's functionality)

Hm... these are all nnimap+agent requests, actually...

Re: Agent improvements

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> In order of (my) priority:
>  - Make the agent stash article when downloading stuff work again (I
>    plan to do some edebug'ing on that... one of these days..)

Please do.  :-)

>  - Don't let nnimap+agent be a blocker to fast moves/copies when online
>    during the move

Sure.

>  - Allow nnimap agent offline delete, copy, and move (synchronize when
>    online, and it would be nice of the synchronization could use fast
>    server side operations)

Yes, that would be useful.  But would that be something that would be
more properly implemented though the registry functions?

>  - Keep agent synchronized during deletes, copies and moves done when
>    online (it's only the deletes that are important actually, I can live
>    with articles moved to a different folder not actually being
>    downloaded until I take action to make it so.  That's the way it
>    always has been, actually)

Aren't `B DEL' deletes respected by the Agent now?

>  - Make expire handle the agent cached article (should follow by the
>    previous item's functionality)

Hm.  Doesn't expiry delete the agented articles too?  That doesn't seem
very complicated to implement...

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

Re: Agent improvements

[Steinar Bang]

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

> Aren't `B DEL' deletes respected by the Agent now?

Don't know.  Back when I started using agent delete/expiry there was
sort of a special thing (one command you ran that deleted everything
older than 14 days that wasn't ticked, or something).

And I haven't really picked up on any new behaviour, unless stuff had
started working...

> Hm.  Doesn't expiry delete the agented articles too?  That doesn't seem
> very complicated to implement...

Ditto on the new behaviour...

Re: Outstanding stuff?

[Steinar Bang]

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

> Any outstanding bugs or annoyances?

(I don't know that the questions below are outstanding bugs, I just
don't know the answer to the questions...)

Does nnimap expire to a different nnimap folder work with the new
nnimap?

I haven't dared expire read articles to the archive folders for a while
now... 

Does nnimap move of articles between folders work reliably?

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Does nnimap expire to a different nnimap folder work with the new
> nnimap?

I think so.

> Does nnimap move of articles between folders work reliably?

Yes.

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

Re: Outstanding stuff?

[Gijs Hillenius]

On 19 Oct 2010, Lars Magne Ingebrigtsen wrote:

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...
>
> Any outstanding bugs or annoyances?

How about nnimap and deleting email attachments? 


"gnus-mime-delete-part: The current group does not support deleting of
parts"

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Gijs Hillenius <gijs@hillenius.net> writes:

> How about nnimap and deleting email attachments? 

When nnimap editing works reliably (it kinda works now), that'll work
automatically.

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

Re: Outstanding stuff?

[Ted Zlatanov]

On Tue, 19 Oct 2010 21:53:30 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I have a feeling that there was a couple of things that I said I was
LMI> going to look into, but I've forgotten what...

LMI> Any outstanding bugs or annoyances?

So let's say theoretically I'm reading
gwene.com.feedburner.cheezburger.  Theoretically.  And I want to read
many articles but it's annoying to do:

`n'
...wait for fetch & display...
`n'
...wait for fetch & display...
...etc.

So I would prefer to prefetch all the images in all the articles in the
group.  Is that possible?

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So let's say theoretically I'm reading
> gwene.com.feedburner.cheezburger.  Theoretically.

Yeah.  That's the ticket.

> And I want to read
> many articles but it's annoying to do:
>
> `n'
> ...wait for fetch & display...
> `n'
> ...wait for fetch & display...
> ...etc.
>
> So I would prefer to prefetch all the images in all the articles in the
> group.  Is that possible?

The images are supposed to be prefetched automatically, depending on
your `gnus-blocked-images' settings...

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

Re: Outstanding stuff?

[Ted Zlatanov]

On Wed, 20 Oct 2010 18:30:21 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> And I want to read
>> many articles but it's annoying to do:
>> 
>> `n'
>> ...wait for fetch & display...
>> `n'
>> ...wait for fetch & display...
>> ...etc.
>> 
>> So I would prefer to prefetch all the images in all the articles in the
>> group.  Is that possible?

LMI> The images are supposed to be prefetched automatically, depending on
LMI> your `gnus-blocked-images' settings...

For the whole group?  I thought it was only the next article.

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> The images are supposed to be prefetched automatically, depending on
> LMI> your `gnus-blocked-images' settings...
>
> For the whole group?  I thought it was only the next article.

If you have Gnus async prefetch on (which is the default), it'll
prefetch images from the next 20-ish messages or so.

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

Re: Outstanding stuff?

[Julien Danjou]

On Tue, Oct 19 2010, Lars Magne Ingebrigtsen wrote:

> Any outstanding bugs or annoyances?

With partial fetching, buttonized part like a PDF file joined to an
email is not downloaded, therefore press 'e' on it does nothing. :(

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Julien Danjou]

On Wed, Oct 20 2010, Julien Danjou wrote:

> With partial fetching, buttonized part like a PDF file joined to an
> email is not downloaded, therefore press 'e' on it does nothing. :(

Same with everything that is inlined, like messages/rfc822 and cid
images, actually.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> With partial fetching, buttonized part like a PDF file joined to an
> email is not downloaded, therefore press 'e' on it does nothing. :(

Yes.  But fixing that is quite complicated, so I'm probably punting on
that... 

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

Re: Outstanding stuff?

[Julien Danjou]

On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:

> Yes.  But fixing that is quite complicated, so I'm probably punting on
> that... 

I spent some time understanding how it works, and I agree. :-(

But OTOH that make the partial things less useful. Well, that'd go in
the never ending todo. :-D

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Outstanding stuff?

[Ted Zlatanov]

On Tue, 19 Oct 2010 21:53:30 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Any outstanding bugs or annoyances?

I'd love to know if it's possible to split mail into other backends.
The gnus-registry split-with-parent could use that.

When we discussed it a while ago I had the idea of recording the message
IDs in the registry and then moving them later, but that seems like a
dumb hack.  Maybe it can be done natively.

Ted

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd love to know if it's possible to split mail into other backends.

The mail splitting code is (today) triggered by each specific backend,
and slurps email into themselves.  So doing so would require a big
rework of the code.

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

Re: Outstanding stuff?

[Tibor Simko]

On Tue, 19 Oct 2010, Lars Magne Ingebrigtsen wrote:
> Any outstanding bugs or annoyances?

One annoyance I'm experiencing with Exchange 2010 is that `g' sometimes
shows there are N new articles in a group while there are actually none
or less than N.  E.g. say I receive 10 new articles in the INBOX.  Upon
first `g' they are client-side-split into 5 nnimap groups, then I read
them all, the counts go to zero, then I press `g' again, and sometimes a
group shows 2 new articles even though when I visit it there are none.
Or sometimes the count shows there are 5 new articles in a group but
when I visit it there are actually only 3, and 2 seems to stand for ones
I read previously in that group few moments ago.  As if the unread count
gets sometimes `remembered' and added to next unread count upon pressing
next `g'.  Nothing gets lost or anything, it is just an annoyance.

(gnus 3bd993c as of 14-Oct-2010)

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> Nothing gets lost or anything, it is just an annoyance.
>
> (gnus 3bd993c as of 14-Oct-2010)

This has been fixed a few days ago.

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

Re: Outstanding stuff?

[Tibor Simko]

On Thu, 21 Oct 2010, Lars Magne Ingebrigtsen wrote:
> This has been fixed a few days ago.

I have updated to Gnus 7ecb6d3 (21-Oct-2010) and I can still reproduce
the problem in the following way:

- send yourself a test message from some other account, so that INBOX
  contains exactly 1 message

- `g' with client-side-splitting delivers it into a group called foo

- `C-u RET 1 RET' and `F' and `C-c C-c' to send a reply

- `q' to go back to the Group buffer which shows that foo has 0 unread
  messages; all is fine up to here

- but pressing `g' again will show that foo has 1 unread message (even
  though no new messages arrived in the meantime)

I'm seeing this only when I actually send the reply.  When the reply
goes into drafts `C-c C-d' then the unread count stays zero even after
the second `g', as expected.

Best regards
--
Tibor Simko

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> I'm seeing this only when I actually send the reply.  When the reply
> goes into drafts `C-c C-d' then the unread count stays zero even after
> the second `g', as expected.

This is really puzzling.  I can't really imagine what sending an email
would have with how nnimap responds to `g'.  Unless you're Gcc-ing to an
nnimap group?

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

Re: Outstanding stuff?

[Tibor Simko]

On Sun, 24 Oct 2010, Lars Magne Ingebrigtsen wrote:
>> I'm seeing this only when I actually send the reply.  When the reply
>> goes into drafts `C-c C-d' then the unread count stays zero even
>> after the second `g', as expected.
>
> This is really puzzling.  I can't really imagine what sending an email
> would have with how nnimap responds to `g'.  Unless you're Gcc-ing to
> an nnimap group?

Yes, precisely, to (another) nnimap group.  I was trying to provide a
simple recipe, and such a Gcc makes the unread count problem occur
consistently for me.  But the unread count problem exists naturally even
without sending out anything; it is sufficient to simply wait long
enough for a new batch of incoming mail, while reading and marking
articles and stuff; then pressing `g' with client-side splitting upon
this new batch of mails will cause the unread counts to go mad again.
Pressing `M-g' on affected groups will correct the counts.

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> But the unread count problem exists naturally even without sending out
> anything; it is sufficient to simply wait long enough for a new batch
> of incoming mail, while reading and marking articles and stuff; then
> pressing `g' with client-side splitting upon this new batch of mails
> will cause the unread counts to go mad again.

Knut Anders' patch didn't fix this for you?

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

Re: Outstanding stuff?

[Tibor Simko]

On Sat, 30 Oct 2010, Lars Magne Ingebrigtsen wrote:
> Knut Anders' patch didn't fix this for you?

Do you mean 9ac9be0?  It comes after a8b95f9 that caused AUTH troubles
for me (see parallel thread), so I was not running it.

I have now back-ported 9ac9be0, and so far so good, my test cases seem
fixed.  I'll report more real-life success/failure in a day or two after
more real-life mail traffic comes in.

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Tibor Simko]

On Sat, 30 Oct 2010, Tibor Simko wrote:
> I have now back-ported 9ac9be0, and so far so good, my test cases seem
> fixed.  I'll report more real-life success/failure in a day or two
> after more real-life mail traffic comes in.

Things work much better than before indeed, although I did experience
the wrong unread count situation occasionally still, once or twice in
two days.  I have not traced when/why.  Maybe there are a few more
places in the codebase when a fix similar to 9ac9be0 is needed?

E.g. one easily reproducible use case is when a new mail arrives to a
nnimap group and is read and marked for expiry and stuff, and then the
group parameters are edited via `G p' to add `(auto-expire . t)' for the
given group; then upon pressing next `g', the unread counts and marks go
wrong again for the given group.  (`M-g' fixes them.)

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> E.g. one easily reproducible use case is when a new mail arrives to a
> nnimap group and is read and marked for expiry and stuff, and then the
> group parameters are edited via `G p' to add `(auto-expire . t)' for the
> given group; then upon pressing next `g', the unread counts and marks go
> wrong again for the given group.  (`M-g' fixes them.)

I didn't think `G p' did anything with, well, anything...  Hm...  Oh,
there may be a synchronisation problem with the `G p' command,
actually.  This may be fixed now.

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

Re: Outstanding stuff?

[Tibor Simko]

On Mon, 01 Nov 2010, Lars Magne Ingebrigtsen wrote:
> I didn't think `G p' did anything with, well, anything...  Hm...  Oh,
> there may be a synchronisation problem with the `G p' command,
> actually.  This may be fixed now.

The `G p' induced count problem is still there for me, but it is a very
minor annoyance only.  The primary problem seems well fixed by 9ac9be0.

Best regards
-- 
Tibor Simko

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> The `G p' induced count problem is still there for me, but it is a very
> minor annoyance only.

But it might be the symptom of some deeper-lying problem...  However,
I'm unable to reproduce it.

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

Re: Outstanding stuff?

[Rémi Letot]

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

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...
>
> Any outstanding bugs or annoyances?

The way 'g' reacts when I subscribe to some specific groups on my
server?  

I'm already gone :-)

-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

>> Any outstanding bugs or annoyances?
>
> The way 'g' reacts when I subscribe to some specific groups on my
> server?  

Get debugging.  :-)

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>>> Any outstanding bugs or annoyances?
>>
>> The way 'g' reacts when I subscribe to some specific groups on my
>> server?  
>
> Get debugging.  :-)

Don't even know how to start, I don't know elisp nor imap :-(

Is there a way to "trace" and record what gnus does when I hit 'g' ?
That way I could record with and without a problematic group and try to
spot *the* difference ?

Thanks,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

> Don't even know how to start, I don't know elisp nor imap :-(

Oops.  :-)

> Is there a way to "trace" and record what gnus does when I hit 'g' ?
> That way I could record with and without a problematic group and try to
> spot *the* difference ?

Well, the "*nnimap <server> ...*" buffer has all the data you get from
the server.  You could do a `g', then copy the contents of that buffer,
then put the problematic group in, do `g' again, and copy the contents
again.  That should give us a pretty good basis for comparison.

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>> Don't even know how to start, I don't know elisp nor imap :-(
>
> Oops.  :-)
>
>> Is there a way to "trace" and record what gnus does when I hit 'g' ?
>> That way I could record with and without a problematic group and try to
>> spot *the* difference ?
>
> Well, the "*nnimap <server> ...*" buffer has all the data you get from
> the server.  You could do a `g', then copy the contents of that buffer,
> then put the problematic group in, do `g' again, and copy the contents
> again.  That should give us a pretty good basis for comparison.

I have several unsubscribed mailboxes, and just my inbox subscribed. In
this configuration, the "*nnimap..." buffer gets 1316 lines after a 'g'
(I don't paste them because it's long, just tell me if you need them).

When I subscribe to the problematic group (in addition to my inbox), I
only get 108 lines:

* 1 FETCH (UID 1 FLAGS (%Seen)).
* 2 FETCH (UID 2 FLAGS (%Seen)).
* 3 FETCH (UID 3 FLAGS (%Seen)).
* 4 FETCH (UID 4 FLAGS (%Seen)).
* 5 FETCH (UID 5 FLAGS (%Seen)).
* 6 FETCH (UID 6 FLAGS (%Seen)).
* 7 FETCH (UID 7 FLAGS (%Seen)).
* 8 FETCH (UID 8 FLAGS (%Seen)).
* 9 FETCH (UID 9 FLAGS (%Seen)).
* 10 FETCH (UID 10 FLAGS (%Seen)).
* 11 FETCH (UID 11 FLAGS (%Seen)).
* 12 FETCH (UID 12 FLAGS (%Seen)).
* 13 FETCH (UID 13 FLAGS (%Seen)).
* 14 FETCH (UID 14 FLAGS (%Seen)).
* 15 FETCH (UID 15 FLAGS (%Seen)).
* 16 FETCH (UID 16 FLAGS (%Seen)).
* 17 FETCH (UID 17 FLAGS (%Seen)).
* 18 FETCH (UID 18 FLAGS (%Seen)).
* 19 FETCH (UID 19 FLAGS (%Seen)).
* 20 FETCH (UID 20 FLAGS (%Seen)).
* 21 FETCH (UID 21 FLAGS (%Answered %Seen)).
* 22 FETCH (UID 22 FLAGS (%Seen)).
* 23 FETCH (UID 23 FLAGS (%Seen)).
* 24 FETCH (UID 24 FLAGS (%Seen)).
* 25 FETCH (UID 25 FLAGS (%Seen)).
* 26 FETCH (UID 26 FLAGS (%Seen)).
* 27 FETCH (UID 27 FLAGS (%Seen)).
* 28 FETCH (UID 28 FLAGS (%Seen)).
* 29 FETCH (UID 29 FLAGS (%Seen)).
* 30 FETCH (UID 30 FLAGS (%Seen)).
* 31 FETCH (UID 31 FLAGS (%Seen)).
* 32 FETCH (UID 32 FLAGS (%Seen)).
* 33 FETCH (UID 33 FLAGS (%Seen)).
* 34 FETCH (UID 34 FLAGS (%Seen)).
* 35 FETCH (UID 35 FLAGS (%Seen)).
* 36 FETCH (UID 36 FLAGS (%Answered %Seen)).
* 37 FETCH (UID 37 FLAGS (%Seen)).
* 38 FETCH (UID 38 FLAGS (%Seen)).
* 39 FETCH (UID 39 FLAGS (%Seen)).
* 40 FETCH (UID 40 FLAGS (%Seen)).
* 41 FETCH (UID 41 FLAGS (%Seen)).
* 42 FETCH (UID 42 FLAGS (%Seen)).
* 43 FETCH (UID 43 FLAGS (%Seen)).
* 44 FETCH (UID 44 FLAGS (%Seen)).
* 45 FETCH (UID 45 FLAGS (%Seen)).
* 46 FETCH (UID 46 FLAGS (%Seen)).
* 47 FETCH (UID 47 FLAGS (%Seen)).
* 48 FETCH (UID 48 FLAGS (%Seen)).
* 49 FETCH (UID 49 FLAGS (%Seen)).
* 50 FETCH (UID 50 FLAGS (%Seen)).
* 51 FETCH (UID 51 FLAGS (%Seen)).
* 52 FETCH (UID 52 FLAGS (%Seen)).
* 53 FETCH (UID 53 FLAGS (%Answered %Seen)).
* 54 FETCH (UID 54 FLAGS (%Seen)).
* 55 FETCH (UID 55 FLAGS (%Seen)).
* 56 FETCH (UID 56 FLAGS (%Answered %Seen)).
* 57 FETCH (UID 57 FLAGS (%Answered %Seen)).
* 58 FETCH (UID 58 FLAGS (%Answered %Seen)).
* 59 FETCH (UID 59 FLAGS (%Seen)).
* 60 FETCH (UID 60 FLAGS (%Answered %Seen)).
* 61 FETCH (UID 61 FLAGS (%Seen)).
* 62 FETCH (UID 62 FLAGS (%Seen)).
* 63 FETCH (UID 63 FLAGS (%Seen)).
* 64 FETCH (UID 64 FLAGS (%Seen)).
* 65 FETCH (UID 65 FLAGS (%Seen)).
* 66 FETCH (UID 66 FLAGS (%Seen)).
* 67 FETCH (UID 67 FLAGS (%Seen)).
* 68 FETCH (UID 68 FLAGS (%Seen)).
* 69 FETCH (UID 69 FLAGS (%Seen)).
* 70 FETCH (UID 70 FLAGS (%Seen)).
* 71 FETCH (UID 71 FLAGS (%Answered %Seen)).
* 72 FETCH (UID 72 FLAGS (%Answered %Seen)).
* 73 FETCH (UID 73 FLAGS (%Seen)).
* 74 FETCH (UID 74 FLAGS (%Seen)).
* 75 FETCH (UID 75 FLAGS (%Seen)).
* 76 FETCH (UID 76 FLAGS (%Seen)).
* 77 FETCH (UID 77 FLAGS (%Seen)).
* 78 FETCH (UID 78 FLAGS (%Seen)).
* 79 FETCH (UID 79 FLAGS (%Seen)).
* 80 FETCH (UID 80 FLAGS (%Seen)).
* 81 FETCH (UID 81 FLAGS (%Answered %Seen)).
* 82 FETCH (UID 82 FLAGS (%Answered %Seen)).
* 83 FETCH (UID 83 FLAGS (%Seen)).
* 84 FETCH (UID 84 FLAGS (%Seen)).
* 85 FETCH (UID 85 FLAGS (%Seen)).
* 86 FETCH (UID 86 FLAGS (%Seen)).
* 87 FETCH (UID 87 FLAGS (%Seen)).
* 88 FETCH (UID 88 FLAGS (%Seen)).
* 89 FETCH (UID 89 FLAGS (%Seen)).
* 90 FETCH (UID 90 FLAGS (%Seen)).
* 91 FETCH (UID 91 FLAGS (%Answered %Seen)).
* 92 FETCH (UID 92 FLAGS (%Answered %Seen)).
* 93 FETCH (UID 93 FLAGS (%Answered %Seen)).
* 94 FETCH (UID 94 FLAGS (%Seen)).
* 95 FETCH (UID 95 FLAGS (%Answered %Seen)).
* 96 FETCH (UID 96 FLAGS (%Answered %Seen)).
* 97 FETCH (UID 97 FLAGS (%Seen)).
2697 OK FETCH completed..
* FLAGS (%Draft %Answered %Flagged %Deleted %Seen %Recent).
* OK [PERMANENTFLAGS ()] No permanent flags permitted.
* 1 EXISTS.
* 0 RECENT.
* OK [UIDVALIDITY 1286920784] Ok.
* OK [MYRIGHTS "acdilrsw"] ACL.
2698 OK [READ-ONLY] Ok.
* 1 FETCH (UID 1 FLAGS (%Seen)).
2699 OK FETCH completed..

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

> When I subscribe to the problematic group (in addition to my inbox), I
> only get 108 lines:
>
> * 1 FETCH (UID 1 FLAGS (%Seen)).

That's the first line in the buffer when this happens?

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>> When I subscribe to the problematic group (in addition to my inbox), I
>> only get 108 lines:
>>
>> * 1 FETCH (UID 1 FLAGS (%Seen)).
>
> That's the first line in the buffer when this happens?

Yes, which is not the case when the problematic group is not subscribed.

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

> Yes, which is not the case when the problematic group is not subscribed.

What do you get in the buffer if only the problematic group is
subscribed?

Or, rather, eval the following:

(nnimap-retrieve-group-data-early
  "server-name" (gnus-get-info "nnimap+server.name:group.name"))

and look in that buffer.

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>> Yes, which is not the case when the problematic group is not subscribed.
>
> What do you get in the buffer if only the problematic group is
> subscribed?
>
> Or, rather, eval the following:
>
> (nnimap-retrieve-group-data-early
>   "server-name" (gnus-get-info "nnimap+server.name:group.name"))

I get an error:

eval-region: Wrong type argument: listp,
"nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"

But with only the problematic group subscribed, I get these after 'g':

* 1 FETCH (UID 1 FLAGS (%Seen)).
* 2 FETCH (UID 2 FLAGS (%Seen)).
* 3 FETCH (UID 3 FLAGS (%Seen)).
* 4 FETCH (UID 4 FLAGS (%Seen)).
* 5 FETCH (UID 5 FLAGS (%Seen)).
* 6 FETCH (UID 6 FLAGS (%Seen)).
* 7 FETCH (UID 7 FLAGS (%Seen)).
* 8 FETCH (UID 8 FLAGS (%Seen)).
* 9 FETCH (UID 9 FLAGS (%Seen)).
* 10 FETCH (UID 10 FLAGS (%Seen)).
* 11 FETCH (UID 11 FLAGS (%Seen)).
* 12 FETCH (UID 12 FLAGS (%Seen)).
* 13 FETCH (UID 13 FLAGS (%Seen)).
* 14 FETCH (UID 14 FLAGS (%Seen)).
* 15 FETCH (UID 15 FLAGS (%Seen)).
* 16 FETCH (UID 16 FLAGS (%Seen)).
* 17 FETCH (UID 17 FLAGS (%Seen)).
* 18 FETCH (UID 18 FLAGS (%Seen)).
* 19 FETCH (UID 19 FLAGS (%Seen)).
* 20 FETCH (UID 20 FLAGS (%Seen)).
* 21 FETCH (UID 21 FLAGS (%Answered %Seen)).
* 22 FETCH (UID 22 FLAGS (%Seen)).
* 23 FETCH (UID 23 FLAGS (%Seen)).
* 24 FETCH (UID 24 FLAGS (%Seen)).
* 25 FETCH (UID 25 FLAGS (%Seen)).
* 26 FETCH (UID 26 FLAGS (%Seen)).
* 27 FETCH (UID 27 FLAGS (%Seen)).
* 28 FETCH (UID 28 FLAGS (%Seen)).
* 29 FETCH (UID 29 FLAGS (%Seen)).
* 30 FETCH (UID 30 FLAGS (%Seen)).
* 31 FETCH (UID 31 FLAGS (%Seen)).
* 32 FETCH (UID 32 FLAGS (%Seen)).
* 33 FETCH (UID 33 FLAGS (%Seen)).
* 34 FETCH (UID 34 FLAGS (%Seen)).
* 35 FETCH (UID 35 FLAGS (%Seen)).
* 36 FETCH (UID 36 FLAGS (%Answered %Seen)).
* 37 FETCH (UID 37 FLAGS (%Seen)).
* 38 FETCH (UID 38 FLAGS (%Seen)).
* 39 FETCH (UID 39 FLAGS (%Seen)).
* 40 FETCH (UID 40 FLAGS (%Seen)).
* 41 FETCH (UID 41 FLAGS (%Seen)).
* 42 FETCH (UID 42 FLAGS (%Seen)).
* 43 FETCH (UID 43 FLAGS (%Seen)).
* 44 FETCH (UID 44 FLAGS (%Seen)).
* 45 FETCH (UID 45 FLAGS (%Seen)).
* 46 FETCH (UID 46 FLAGS (%Seen)).
* 47 FETCH (UID 47 FLAGS (%Seen)).
* 48 FETCH (UID 48 FLAGS (%Seen)).
* 49 FETCH (UID 49 FLAGS (%Seen)).
* 50 FETCH (UID 50 FLAGS (%Seen)).
* 51 FETCH (UID 51 FLAGS (%Seen)).
* 52 FETCH (UID 52 FLAGS (%Seen)).
* 53 FETCH (UID 53 FLAGS (%Answered %Seen)).
* 54 FETCH (UID 54 FLAGS (%Seen)).
* 55 FETCH (UID 55 FLAGS (%Seen)).
* 56 FETCH (UID 56 FLAGS (%Answered %Seen)).
* 57 FETCH (UID 57 FLAGS (%Answered %Seen)).
* 58 FETCH (UID 58 FLAGS (%Answered %Seen)).
* 59 FETCH (UID 59 FLAGS (%Seen)).
* 60 FETCH (UID 60 FLAGS (%Answered %Seen)).
* 61 FETCH (UID 61 FLAGS (%Seen)).
* 62 FETCH (UID 62 FLAGS (%Seen)).
* 63 FETCH (UID 63 FLAGS (%Seen)).
* 64 FETCH (UID 64 FLAGS (%Seen)).
* 65 FETCH (UID 65 FLAGS (%Seen)).
* 66 FETCH (UID 66 FLAGS (%Seen)).
* 67 FETCH (UID 67 FLAGS (%Seen)).
* 68 FETCH (UID 68 FLAGS (%Seen)).
* 69 FETCH (UID 69 FLAGS (%Seen)).
* 70 FETCH (UID 70 FLAGS (%Seen)).
* 71 FETCH (UID 71 FLAGS (%Answered %Seen)).
* 72 FETCH (UID 72 FLAGS (%Answered %Seen)).
* 73 FETCH (UID 73 FLAGS (%Seen)).
* 74 FETCH (UID 74 FLAGS (%Seen)).
* 75 FETCH (UID 75 FLAGS (%Seen)).
* 76 FETCH (UID 76 FLAGS (%Seen)).
* 77 FETCH (UID 77 FLAGS (%Seen)).
* 78 FETCH (UID 78 FLAGS (%Seen)).
* 79 FETCH (UID 79 FLAGS (%Seen)).
* 80 FETCH (UID 80 FLAGS (%Seen)).
* 81 FETCH (UID 81 FLAGS (%Answered %Seen)).
* 82 FETCH (UID 82 FLAGS (%Answered %Seen)).
* 83 FETCH (UID 83 FLAGS (%Seen)).
* 84 FETCH (UID 84 FLAGS (%Seen)).
* 85 FETCH (UID 85 FLAGS (%Seen)).
* 86 FETCH (UID 86 FLAGS (%Seen)).
* 87 FETCH (UID 87 FLAGS (%Seen)).
* 88 FETCH (UID 88 FLAGS (%Seen)).
* 89 FETCH (UID 89 FLAGS (%Seen)).
* 90 FETCH (UID 90 FLAGS (%Seen)).
* 91 FETCH (UID 91 FLAGS (%Answered %Seen)).
* 92 FETCH (UID 92 FLAGS (%Answered %Seen)).
* 93 FETCH (UID 93 FLAGS (%Answered %Seen)).
* 94 FETCH (UID 94 FLAGS (%Seen)).
* 95 FETCH (UID 95 FLAGS (%Answered %Seen)).
* 96 FETCH (UID 96 FLAGS (%Answered %Seen)).
* 97 FETCH (UID 97 FLAGS (%Seen)).
3164 OK FETCH completed..
* FLAGS (%Draft %Answered %Flagged %Deleted %Seen %Recent).
* OK [PERMANENTFLAGS ()] No permanent flags permitted.
* 1 EXISTS.
* 0 RECENT.
* OK [UIDVALIDITY 1286920784] Ok.
* OK [MYRIGHTS "acdilrsw"] ACL.
3165 OK [READ-ONLY] Ok.
* 1 FETCH (UID 1 FLAGS (%Seen)).
3166 OK FETCH completed..


Which looks very much like what I get when my inbox is subscribed too...

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

>> (nnimap-retrieve-group-data-early
>>   "server-name" (gnus-get-info "nnimap+server.name:group.name"))
>
> I get an error:
>
> eval-region: Wrong type argument: listp,
> "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"

So you evaled this?

(nnimap-retrieve-group-data-early
 "swoog" (gnus-get-info "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"))

And the group is subscribed?   

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>>> (nnimap-retrieve-group-data-early
>>>   "server-name" (gnus-get-info "nnimap+server.name:group.name"))
>>
>> I get an error:
>>
>> eval-region: Wrong type argument: listp,
>> "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"
>
> So you evaled this?
>
> (nnimap-retrieve-group-data-early
>  "swoog" (gnus-get-info
>  "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"))

except I replaced the first "swoog" with the real FQDN of that server
(swoog is a historical name, it's still the name in my group buffer, but
it's not the real one)

> And the group is subscribed?   

Yep

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

>> (nnimap-retrieve-group-data-early
>>  "swoog" (gnus-get-info
>>  "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"))
>
> except I replaced the first "swoog" with the real FQDN of that server
> (swoog is a historical name, it's still the name in my group buffer, but
> it's not the real one)

So what happens when you eval this?

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>>> (nnimap-retrieve-group-data-early
>>>  "swoog" (gnus-get-info
>>>  "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"))
>>
>> except I replaced the first "swoog" with the real FQDN of that server
>> (swoog is a historical name, it's still the name in my group buffer, but
>> it's not the real one)
>
> So what happens when you eval this?

Same error:

wrong-type-argument listp
"nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"

Here is the backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles")
  nnimap-retrieve-group-data-early("swoog" ("nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles" 3 (1) ((seen 1)) (nnimap "swoog") ((modseq) (uidvalidity . "1286920784") (active 1 . 1) (permanent-flags . t) (imap-status . "2 1 1"))))
  eval((nnimap-retrieve-group-data-early "swoog" (gnus-get-info "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles")))
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)


HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

> wrong-type-argument listp
> "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"

Oh, that should be:

(nnimap-retrieve-group-data-early
 "swoog" (list (gnus-get-info
                "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles")))

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>> wrong-type-argument listp
>> "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles"
>
> Oh, that should be:
>
> (nnimap-retrieve-group-data-early
>  "swoog" (list (gnus-get-info
>                 "nnimap+swoog:INBOX.1_GTD.PROJETS.services-domiciles")))

Here it is:

* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent).
* OK [PERMANENTFLAGS ()] No permanent flags permitted.
* 1 EXISTS.
* 0 RECENT.
* OK [UIDVALIDITY 1286920784] Ok.
* OK [MYRIGHTS "acdilrsw"] ACL.
301 OK [READ-ONLY] Ok.
* 1 FETCH (UID 1 FLAGS (\Seen)).
302 OK FETCH completed..

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

hobbes@poukram.net (Rémi Letot) writes:

> Here it is:
>
> * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent).
> * OK [PERMANENTFLAGS ()] No permanent flags permitted.
> * 1 EXISTS.
> * 0 RECENT.
> * OK [UIDVALIDITY 1286920784] Ok.
> * OK [MYRIGHTS "acdilrsw"] ACL.
> 301 OK [READ-ONLY] Ok.
> * 1 FETCH (UID 1 FLAGS (\Seen)).
> 302 OK FETCH completed..

Well, that looks totally 100% normal.

I have no idea what could be going on.

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

Re: Outstanding stuff?

[Rémi Letot]

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

> hobbes@poukram.net (Rémi Letot) writes:
>
>> Here it is:
>>
>> * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent).
>> * OK [PERMANENTFLAGS ()] No permanent flags permitted.
>> * 1 EXISTS.
>> * 0 RECENT.
>> * OK [UIDVALIDITY 1286920784] Ok.
>> * OK [MYRIGHTS "acdilrsw"] ACL.
>> 301 OK [READ-ONLY] Ok.
>> * 1 FETCH (UID 1 FLAGS (\Seen)).
>> 302 OK FETCH completed..
>
> Well, that looks totally 100% normal.
>
> I have no idea what could be going on.

One more thing: I unsubscribed everything again, except that problematic
group. Now when I start gnus, I get these in *Messages*:

Reading /home/hobbes/.newsrc.eld...
Reading active file from news.gmane.org via nntp...
Reading active file from swoog via nnimap...
Opening nnimap server on swoog...
Opening connection to my.server.net via starttls...
Opening TLS connection to `my.server.net'...
Opening TLS connection with `openssl s_client -connect my.server.net:imap -no_ssl2 -ign_eof -starttls imap'...done
Opening TLS connection to `my.server.net'...done
Opening nnimap server on swoog...done
Reading active file from swoog via nnimap...done
Reading active file from archive via nnfolder...
Opening nnfolder server on archive...done
Reading active file from archive via nnfolder...done
No new newsgroups
Checking new news...
nnimap read 0k [4288 times]
Reading active file from archive via nnfolder...done
Opening connection to my.server.net via starttls...
Opening TLS connection to `my.server.net'...
Opening TLS connection with `openssl s_client -connect my.server.net:imap -no_ssl2 -ign_eof -starttls imap'...done
Opening TLS connection to `my.server.net'...done
nnimap read 0k [301 times]
Reading active file via nndraft...done
Checking new news...done
Mark set


Note the "nnimap read 0k [4288 times]", it's only 4288 because I C-g,
otherwise I thing it would go on forever. And I need to C-g a second
time (the second "nnimap read 0k..." line) to get gnus to display the
group buffer (and I have only one imap subscribed group).

This happens again at each 'g', until I M-g the problematic group. After
that, 'g' doesn't hang anymore.

HTH,
-- 
Rémi

Re: Outstanding stuff?

[Robert Pluim]

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

> I have a feeling that there was a couple of things that I said I was
> going to look into, but I've forgotten what...
>
> Any outstanding bugs or annoyances?

Here's a minor annoyance I've just noticed:

My nnimap server is covered by the agent
My nntp server is not
If I hit J-u on an nntp group, it starts downloading articles from
there. I'd expect it to error out or do nothing. (J-s only downloads
from the nnimap server).

Regards

Robert

Re: Outstanding stuff?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> My nnimap server is covered by the agent
> My nntp server is not
> If I hit J-u on an nntp group, it starts downloading articles from
> there. I'd expect it to error out or do nothing. (J-s only downloads
> from the nnimap server).

Ok; fixed.

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

Re: Outstanding stuff?

[Mario Peter]

On Oct 19 2010, 21:53, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Any outstanding bugs or annoyances?

is there a way to attach one or more articles as an rfs822 mime
attachment to a mail?

I know the way via digest and mail, but this can be done only from the
same group and I would like to do this seperately - maybe reading the
article, command to capture this article, go to message buffer, insert
capured mail in a mml section.

This is just a suggestion - maybe others have better ways for doing
this?!?

Mario
-- 
Mario Peter
de,pl,en
http://www.mpeter.de

Forwarding rfc822 messages (was: Outstanding stuff?)

[Lars Magne Ingebrigtsen]

Mario Peter <empee0@googlemail.com> writes:

> I know the way via digest and mail, but this can be done only from the
> same group and I would like to do this seperately - maybe reading the
> article, command to capture this article, go to message buffer, insert
> capured mail in a mml section.

It seems like `S o m' is a pretty easy option -- I mean, after getting
the Message buffer, you can just edit out any of the stuff you don't
want, can't you?

I'm not really seeing a use case here, so perhaps I'm misunderstanding
what you mean...

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

Re: Forwarding rfc822 messages

[Dave Goldberg]

> Mario Peter <empee0@googlemail.com> writes:
>> I know the way via digest and mail, but this can be done only from the
>> same group and I would like to do this seperately - maybe reading the
>> article, command to capture this article, go to message buffer, insert
>> capured mail in a mml section.

> It seems like `S o m' is a pretty easy option -- I mean, after getting
> the Message buffer, you can just edit out any of the stuff you don't
> want, can't you?

> I'm not really seeing a use case here, so perhaps I'm misunderstanding
> what you mean...

I'm not sure I'm following the OP either, but here's my use case and solution for something that I think is akin to this request.

At work, where I manage a group of sysadmins, we use a trouble ticket system (RT) that allows many in my group to handle tickets entirely through email.  Our users are not aware of this and often sent replies with CCs directly to particular admins, resulting in several copies of messages,  some of which lack the necessary CC to keep a message tracked by RT falls off the list.  When it happens with me (I do use the web interface so I can tell if a message in my inbox has not been included) I want to get the message into the ticket - perhaps it contains troubleshooting data that we've asked the user to provide.  Simple forwarding can be a pain because then I'd have to fill in the Subject in a particular way.  Easier for me is to start a reply on a proper email in the ticket and then attach t
 he other message as part of the composition.  So my summary line format includes the message number and I've written this simple function, bound to C-c C-m C-m.

(defun dsg-message-attach-article (group message)
  (interactive
   (list (completing-read
	  "Group: " gnus-active-hashtb nil
	  (gnus-read-active-file-p)
	  nil
	  'gnus-group-history)
	 (read-number "Message: " t)))
  (let ((tmp (get-buffer-create (generate-new-buffer-name "*MSGTMP*"))))
    (save-excursion
      (set-buffer tmp)
      (gnus-request-article-this-buffer message group))
    (mml-attach-buffer (buffer-name tmp) "message/rfc822")))


-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Forwarding rfc822 messages

[Mario Peter]

On Nov 01 2010, 04:51, Dave Goldberg <david.goldberg6@verizon.net> wrote:
> At work, where I manage a group of sysadmins, we use a trouble ticket
> system (RT) that allows many in my group to handle tickets entirely
> through email.  Our users are not aware of this and often sent replies
> with CCs directly to particular admins, resulting in several copies of
> messages, some of which lack the necessary CC to keep a message
> tracked by RT falls off the list.  When it happens with me (I do use
> the web interface so I can tell if a message in my inbox has not been
> included) I want to get the message into the ticket - perhaps it
> contains troubleshooting data that we've asked the user to provide.
> Simple forwarding can be a pain because then I'd have to fill in the
> Subject in a particular way.  Easier for me is to start a reply on a
> proper email in the ticket and then attach the other message as part
> of the composition.  So my summary line format includes the message
> number and I've written this simple function, bound to C-c C-m C-m.
>
> (defun dsg-message-attach-article (group message)
>   (interactive
>    (list (completing-read
> 	  "Group: " gnus-active-hashtb nil
> 	  (gnus-read-active-file-p)
> 	  nil
> 	  'gnus-group-history)
> 	 (read-number "Message: " t)))
>   (let ((tmp (get-buffer-create (generate-new-buffer-name "*MSGTMP*"))))
>     (save-excursion
>       (set-buffer tmp)
>       (gnus-request-article-this-buffer message group))
>     (mml-attach-buffer (buffer-name tmp) "message/rfc822")))

I tried this out today at work, it's a cool solution and I got used to
it quickly.  I made a little change to be able to attach more than one
article:

(defun dsg-message-attach-article (group message)
  (interactive
   (list (completing-read
	  "Group: " gnus-active-hashtb nil
	  (gnus-read-active-file-p)
	  nil
	  'gnus-group-history)
	 (read-number "Message: ")))
  (let ((tmp (get-buffer-create
              (generate-new-buffer-name
               (concat "*MSGTMP-" (number-to-string message) "*")))))
    (save-excursion
      (set-buffer tmp)
      (gnus-request-article-this-buffer message group))
    (mml-attach-buffer (buffer-name tmp) "message/rfc822")))


Thanks for this!! I did not get used to the article number in the
summary line though ;-) so I get the number now with a little helper.

The solution using the kill-ring as Lars proposed has charme too - you don't have
to remember a number...  hmmm

Mario
-- 
Mario Peter
de,pl,en
http://www.mpeter.de

Re: Forwarding rfc822 messages

[Mario Peter]

On Oct 31 2010, 23:34, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Mario Peter <empee0@googlemail.com> writes:
>
>> I know the way via digest and mail, but this can be done only from the
>> same group and I would like to do this seperately - maybe reading the
>> article, command to capture this article, go to message buffer, insert
>> capured mail in a mml section.
>
> It seems like `S o m' is a pretty easy option -- I mean, after getting
> the Message buffer, you can just edit out any of the stuff you don't
> want, can't you?
>
> I'm not really seeing a use case here, so perhaps I'm misunderstanding
> what you mean...

the point is you have to decide and look for the articles _before_
creating your message, in case you already created it and you get the
need to attach the mail afterwards (as you do it with most of file
attachments actually...) then this can be tricky ( my workaround is to
create a second message buffer with the forwarded mail (C-c C-f) , copy
the mml stuff and yank it to the primary message...)

AFAIK one cannot digest mails from different groups as well. So my idea
was to provide some kind of capture function which does at least my
workaround above... ;-)

Mario
-- 
Mario Peter
de,pl,en
http://www.mpeter.de

Re: Forwarding rfc822 messages

[Lars Magne Ingebrigtsen]

Mario Peter <empee0@googlemail.com> writes:

> the point is you have to decide and look for the articles _before_
> creating your message, in case you already created it and you get the
> need to attach the mail afterwards (as you do it with most of file
> attachments actually...) then this can be tricky ( my workaround is to
> create a second message buffer with the forwarded mail (C-c C-f) , copy
> the mml stuff and yank it to the primary message...)

So you want to have a command from inside Message mode that would query
you for a group and an article, and then include that message?  It
sounds quite awkward.

If, instead, you have a message buffer, and then root around in the
groups, I think the method you have today for doing that (i.e., your
workaround) probably won't be significantly more keystrokes than, well,
anything else that's convenient...  I think.

So -- we'd have one summary mode command that would be
`copy-article-to-kill-buffer'?  And a new message command that would be,
er, `C-c C-m C-r' to insert an mml section with the yanked message as
the contents..  Hm...

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

Re: Forwarding rfc822 messages

[Mario Peter]

On Nov 01 2010, 19:16, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Mario Peter <empee0@googlemail.com> writes:
>
>> the point is you have to decide and look for the articles _before_
>> creating your message, in case you already created it and you get the
>> need to attach the mail afterwards (as you do it with most of file
>> attachments actually...) then this can be tricky ( my workaround is to
>> create a second message buffer with the forwarded mail (C-c C-f) , copy
>> the mml stuff and yank it to the primary message...)

[...]

> So -- we'd have one summary mode command that would be
> `copy-article-to-kill-buffer'?  And a new message command that would be,
> er, `C-c C-m C-r' to insert an mml section with the yanked message as
> the contents..  Hm...

this sounds really cool. With the kill ring one would be able to attach 
more than one mail ... Yes it would be great to have this.

Mario
-- 
Mario Peter
de,pl,en
http://www.mpeter.de

Re: Forwarding rfc822 messages

[Reiner Steib]

On Mon, Nov 01 2010, Lars Magne Ingebrigtsen wrote:

> If, instead, you have a message buffer, and then root around in the
> groups, I think the method you have today for doing that (i.e., your
> workaround) probably won't be significantly more keystrokes than, well,
> anything else that's convenient...  I think.
>
> So -- we'd have one summary mode command that would be
> `copy-article-to-kill-buffer'?  And a new message command that would be,
> er, `C-c C-m C-r' to insert an mml section with the yanked message as
> the contents..  Hm...

Maybe similar to `gnus-dired-attach' ...

,----[ (info "(gnus)Other modes") ]
| `C-c C-m C-a'
|      Send dired's marked files as an attachment (`gnus-dired-attach').
|      You will be prompted for a message buffer.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Forwarding rfc822 messages

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> So -- we'd have one summary mode command that would be
>> `copy-article-to-kill-buffer'?  And a new message command that would be,
>> er, `C-c C-m C-r' to insert an mml section with the yanked message as
>> the contents..  Hm...
>
> Maybe similar to `gnus-dired-attach' ...
>
> ,----[ (info "(gnus)Other modes") ]
> | `C-c C-m C-a'
> |      Send dired's marked files as an attachment (`gnus-dired-attach').
> |      You will be prompted for a message buffer.
> `----

Yes, doing it that way would also make sense...

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

Re: Outstanding stuff?

[Steinar Bang]

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

> Any outstanding bugs or annoyances?

Here's one: make it easy to set the sender when doing resend.

Right now resend of a message from my netbook makes the sender be
sb@localhost6.localdomain6, and my own mail relay refuses to accept a
message from this, because it is an unroutable address.

I'm using smtpmail-send-it for outgoing mail.

Sender header (was: Outstanding stuff?)

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Here's one: make it easy to set the sender when doing resend.
>
> Right now resend of a message from my netbook makes the sender be
> sb@localhost6.localdomain6, and my own mail relay refuses to accept a
> message from this, because it is an unroutable address.
>
> I'm using smtpmail-send-it for outgoing mail.

Hm.  I didn't think Message inserted Sender at all, but I now see that
it does...

If the From header isn't vaguely like what the Sender header would have
been, Message inserts a Sender header.  Which explains why you're seeing
this when resending, since then the From header definitely doesn't match
what the Sender would have been.

But is there any reason to insert a Sender header at all?  This code is
from the mid-nineties, and I don't remember anything about it.  Anybody?

As a workaround, you can

(setq message-syntax-checks '((sender . disabled)))

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

Re: Sender header

[Byung-Hee HWANG]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> 쓰시길:

> Steinar Bang <sb@dod.no> writes:
>
>> Here's one: make it easy to set the sender when doing resend.
>>
>> Right now resend of a message from my netbook makes the sender be
>> sb@localhost6.localdomain6, [...]

Me to: bh@betla.home

> Hm.  I didn't think Message inserted Sender at all, but I now see that
> it does...
>
> If the From header isn't vaguely like what the Sender header would have
> been, Message inserts a Sender header.  Which explains why you're seeing
> this when resending, since then the From header definitely doesn't match
> what the Sender would have been.
>
> But is there any reason to insert a Sender header at all?  This code is
> from the mid-nineties, and I don't remember anything about it.  Anybody?
>
> As a workaround, you can
>
> (setq message-syntax-checks '((sender . disabled)))

A few hours ago, i did check that, so now it's alright, thanks!

-- 
소여물 황병희(黃炳熙) | .. 출항 15분전..

"Thank you for the dinner and a pleasant evening."
		-- Tom Hagen, "Chapter 1", page 62

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

Re: Sender header

[Steinar Bang]

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

> But is there any reason to insert a Sender header at all? 

No, actually I would prefer that it didn't.
But if it had to be there, the From address, or a fixed routable address
I could set up, would be to live with.

> This code is from the mid-nineties, and I don't remember anything
> about it.  Anybody?

> As a workaround, you can

> (setq message-syntax-checks '((sender . disabled)))

`C-h v message-syntax-checks RET' reveals:
 message-syntax-checks is a variable defined in `message.el'.
 Its value is 
 ((sender . disabled))

But I see the issue, so apparently this doesn't work for me. :-(

The setting is in .gnus.el:
 ;; Avoid setting the sender header, and by this use the From: address
 ;; as the envelope address
 (add-to-list 'message-syntax-checks '(sender . disabled))


According to annotate/blame, it has been there since the initial version
of the file in svn 2002-03-12 (the actual file history is older than
this, but this was the point in time when I started version controlling
it).

Re: Sender header

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> `C-h v message-syntax-checks RET' reveals:
>  message-syntax-checks is a variable defined in `message.el'.
>  Its value is 
>  ((sender . disabled))
>
> But I see the issue, so apparently this doesn't work for me. :-(

Does 

(message-check-element 'sender)

eval to t for you?  Then Sender shouldn't be inserted by Message.
Perhaps it's smtpmail that's doing it?

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

Re: Sender header

[Lars Magne Ingebrigtsen]

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

> Perhaps it's smtpmail that's doing it?

Your news messages don't have a Sender header, so that points to
smtpmail.el, I think...

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

Re: Sender header

[Steinar Bang]

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

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

>> Does 

>> (message-check-element 'sender)

>> eval to t for you?

Yes.

>> Then Sender shouldn't be inserted by Message.  Perhaps it's smtpmail
>> that's doing it?

> Your news messages don't have a Sender header, so that points to
> smtpmail.el, I think...

Maybe, but then the sender issue should be the case for all sent
messages...?

The problem occurs only on resends.

I've had this problem with resends even using sendmail to send messages,
or so I think... hm...
  http://thread.gmane.org/gmane.emacs.gnus.general/56106

It _could_ be that resent headers are put on the message, and are picked
up by smtpmail? 

I remember having debugged into the smtpmail code earlier without
becoming very much the wiser.  Maybe I should try again with edebug?
	

Re: Sender header

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> It _could_ be that resent headers are put on the message, and are picked
> up by smtpmail? 

It may be setting it if other stuff isn't, er, set.

I can't really see anywhere where smtpmail is setting Sender, but it's
setting MAIL FROM (which the MTA may translate into Sender) like this:

        ;; `smtpmail-mail-address' should be set to the appropriate
        ;; buffer-local value by the caller, but in case not:
        (envelope-from (or smtpmail-mail-address
                           (and mail-specify-envelope-from
                                (mail-envelope-from))
                           user-mail-address))

> I remember having debugged into the smtpmail code earlier without
> becoming very much the wiser.  Maybe I should try again with edebug?

Yes.  But check upon entry to `smtpmail-send-it' whether the Sender
header is present or not.  Then we'll know whether it's Message or
smtpmail that's doing it.

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

Re: Sender header

[Steinar Bang]

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

> I can't really see anywhere where smtpmail is setting Sender, but it's
> setting MAIL FROM (which the MTA may translate into Sender)

Well, yeah.  Maybe I was unclear in my report.  The address I listed I
had from a wireshark trace of the SMTP dialogue.

So we're talking about the envelope address, rather than something in a
header. 

(but that only occurs for resent messages)

> like this:

>         ;; `smtpmail-mail-address' should be set to the appropriate
>         ;; buffer-local value by the caller, but in case not:
>         (envelope-from (or smtpmail-mail-address
>                            (and mail-specify-envelope-from
>                                 (mail-envelope-from))
>                            user-mail-address))

Hm... yes this looks familiar.  I have been debugging in here before.

> Yes.  But check upon entry to `smtpmail-send-it' whether the Sender
> header is present or not.  Then we'll know whether it's Message or
> smtpmail that's doing it.

Right.

But if it isn't the header at all, but a bogus envelope sender, where do
I look then?

Ah, it's debug time, I guess...:-)

Re: Sender header

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> But if it isn't the header at all, but a bogus envelope sender, where do
> I look then?

Just a bit further down below:

	      (smtpmail-send-command process (format "MAIL FROM:<%s>%s%s"
                                                     envelope-from
						     size-part
						     body-part))

And envelope-from is:
                                                     
        (envelope-from (or smtpmail-mail-address
                           (and mail-specify-envelope-from
                                (mail-envelope-from))
                           user-mail-address))


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

Re: Sender header

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

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

>> like this:

>>         ;; `smtpmail-mail-address' should be set to the appropriate
>>         ;; buffer-local value by the caller, but in case not:
>>         (envelope-from (or smtpmail-mail-address
>>                            (and mail-specify-envelope-from
>>                                 (mail-envelope-from))
>>                            user-mail-address))

Yeah, it was actually pretty simple.  The above ended up setting
envelope-from to user-mail-address, which was...
"sb@localhost6.localdomain6".

This was set in startup.el with the following code:
(defcustom user-mail-address (if command-line-processed
				 (or (getenv "EMAIL")
				     (concat (user-login-name) "@"
					     (or mail-host-address
						 (system-name))))
			       ;; Empty string means "not set yet".
			       "")
  "*Full mailing address of this user.
This is initialized with environment variable `EMAIL' or, as a
fallback, using `mail-host-address'. This is done after your
init file is read, in case it sets `mail-host-address'."
  :type 'string
  :group 'mail)

And since this was customizable I could just set it to sb@dod.no, and I
could forward.

That was easy, and not gnus-related at all.

Oh well!