upgrade notes

upgrade notes

[Wes Hardaker]

So I moved from a quite old (f20fa68) to 647c178

My notes in doing so (after setting debug-on-error a bunch to figure out
what was going wrong):

+ I had (require 'gpg) in my config which I had to remove

+ I had an imap-shell-variable that had been customized that pushed a
  'ssh ... exec imapd' onto the stack.  I don't remember why I had that
  set up and don't need it any longer, but because the variable no
  longer existed it broke my config loading.

+ imap does seem faster, but not hugely so [I wasn't expecting it to
  necessarily; just a comment]

+ My folders no longer show which folders have new messages in them.
  [splitting is done via procmail on the server, and I know the new
  marks exist there since my running qmailcheck biff window displays
  properly "new" flagged messages, as did the older gnus version]

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Lars Ingebrigtsen]

Wes Hardaker <wes@hardakers.net> writes:

> + I had (require 'gpg) in my config which I had to remove
>
> + I had an imap-shell-variable that had been customized that pushed a
>   'ssh ... exec imapd' onto the stack.  I don't remember why I had that
>   set up and don't need it any longer, but because the variable no
>   longer existed it broke my config loading.

I'm not sure those can be helped...

> + My folders no longer show which folders have new messages in them.
>   [splitting is done via procmail on the server, and I know the new
>   marks exist there since my running qmailcheck biff window displays
>   properly "new" flagged messages, as did the older gnus version]

That's interesting.  Could you post output from `G E' on one of the
non-updating groups?  And then try `M-g' on the group, and then the `G
E' output again?

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

Re: upgrade notes

[Wes Hardaker]

>>>>> On Fri, 04 Feb 2011 09:04:40 -0800, Lars Ingebrigtsen <larsi@gnus.org> said:

>> + I had (require 'gpg) in my config which I had to remove
>> 
>> + I had an imap-shell-variable that had been customized that pushed a
>> 'ssh ... exec imapd' onto the stack.  I don't remember why I had that
>> set up and don't need it any longer, but because the variable no
>> longer existed it broke my config loading.

LI> I'm not sure those can be helped...

Well, you could do things like use empty variables and empty files to
ensure that existing config at least loads even if the contents no
longer work (and the imap-shell-variable would have a "obsolete"
variable in the variable document text).

But I'm not saying you need to do this, just offering suggestions.   I
work on a very very backwards compatible project elsewhere so these are
the types of things we try and do.

  gpg.el:
    (error "The gpg.el file is no longer needed; please stop requiring
    it.  In 2020 this file will be removed permanently")

>> + My folders no longer show which folders have new messages in them.

[btw, I meant the % mark in the group buffer; I may not have made that
clear]

>> [splitting is done via procmail on the server, and I know the new
>> marks exist there since my running qmailcheck biff window displays
>> properly "new" flagged messages, as did the older gnus version]

LI> That's interesting.  Could you post output from `G E' on one of the
LI> non-updating groups?  And then try `M-g' on the group, and then the `G
LI> E' output again?

Ok, here's a G E on one of my smaller folders (otherwise this message
was going to get very long!)

  ("nnimap+hardakers:imap.captured-on-earth" 3
   ((1 . 19)
    (22 . 33)
    (35 . 37)
    (40 . 49)
    (51 . 57)
    (59 . 81)
    (84 . 88)
    (90 . 155)
    (157 . 158)
    163)
   ((reply 20 62)
    (seen
     (1 . 120)
     (123 . 144)
     (149 . 163))
    (recent 163))
   "nnimap:hardakers"
   ((modseq . 366)
    (uidvalidity . "1228402789")
    (active 2 . 163)
    (permanent-flags %Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-forward %*)
    (imap-status . "164 2 163")))

After sending mail that arrived in the folder and updating via '3 g', it
shows:

  ("nnimap+hardakers:imap.captured-on-earth" 3
   ((1 . 19)
    (22 . 33)
    (35 . 37)
    (40 . 49)
    (51 . 57)
    (59 . 81)
    (84 . 88)
    (90 . 155)
    (157 . 158)
    163)
   ((reply 20 62)
    (seen
     (1 . 120)
     (123 . 144)
     (149 . 163))
    (recent 163))
   "nnimap:hardakers"
   ((modseq . 367)
    (uidvalidity . "1228402789")
    (active 2 . 164)
    (permanent-flags %Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-forward %*)
    (imap-status . "164 2 163")))

Which shows this via diff:

        (149 . 163))
       (recent 163))
      "nnimap:hardakers"
  -   ((modseq . 367)
  +   ((modseq . 366)
       (uidvalidity . "1228402789")
  -    (active 2 . 164)
  +    (active 2 . 163)
       (permanent-flags %Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-forward %*)
       (imap-status . "164 2 163")))

But the group buffer still doesn't have the % mark.

After a M-g on it:

  [content deleted as it's unchanged from the last set]

After a new message sent, and another '3 g':

  ("nnimap+hardakers:imap.captured-on-earth" 3
   ((1 . 19)
    (22 . 33)
    (35 . 37)
    (40 . 49)
    (51 . 57)
    (59 . 81)
    (84 . 88)
    (90 . 155)
    (157 . 158)
    163)
   ((reply 20 62)
    (seen
     (1 . 120)
     (123 . 144)
     (149 . 163))
    (recent 163))
   "nnimap:hardakers"
   ((modseq . 368)
    (uidvalidity . "1228402789")
    (active 2 . 165)
    (permanent-flags %Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-forward %*)
    (imap-status . "164 2 163")))

(which again updated the modseq and the active)

Important settings:

  (setq  gnus-group-topic-topics-only t
         gnus-topic-line-format "%i[ %(%{%n%}%) -- %g ]%v\n"

My gnus-group-line-format is unmodified and contains:

  "%L%m%S%P%5y: %(%-30G%) %6,6~(cut 2)d\n"

So it's the %m that doesn't seem to be working.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Lars Ingebrigtsen]

Wes Hardaker <wes@hardakers.net> writes:

> Well, you could do things like use empty variables and empty files to
> ensure that existing config at least loads even if the contents no
> longer work (and the imap-shell-variable would have a "obsolete"
> variable in the variable document text).

Yes...  reintroducing the imap-shell-variable as an obsolete variable
would make sense, but in my experience having non-used variables around
just confuses people even more.  But erroring out when starting up
certainly isn't nice, either.

>   gpg.el:
>     (error "The gpg.el file is no longer needed; please stop requiring
>     it.  In 2020 this file will be removed permanently")

I don't know what happened to gpg.el, exactly.  Anybody?

Anyway, we've removed a bazillion files (for some values of bazillion)
from Gnus in this cycle, which I think is the right thing to do.  People
shouldn't require files in that way.  :-)

>>> + My folders no longer show which folders have new messages in them.
>
> [btw, I meant the % mark in the group buffer; I may not have made that
> clear]

Oh, right.  Otherwise everything is OK?  It's showing the correct number
of messages and everything?

The % mark is something that I must admit I can't recall ever hearing
about, even though "git blame" claims that I added it in 1998.  So it's
supposed to appear on groups that have new mail after you do a `g'?
That sounds quite useful, actually.  :-)

Let's see...

Hm, it just looks up stuff in `nnmail-split-history', and that variable
is only filled when we're doing client-side splits, which explains why
it's never triggering for you.  Since you're not doing client-side
splits.  I wonder what the old nnimap did...

Ah:

		(when (> (or (imap-mailbox-get 'recent group
					       nnimap-server-buffer) 0)
			 0)
		  (push (list (cons group 0)) nnmail-split-history))

Whenever there's any messages marked as `recent' (which is the same as
unseen, in Gnus parlance), then it just pushes a dummy thing that
matches onto nnmail-split-history.

This is totally different from what other mail backends do -- the % mark
will only show up on groups that had new messages *this* `g', and not
show up on all groups that have unseen messages.

Is this correct?  The `%' would stay there over several `g' runs?  I may
be misreading the code.

The ?U spec shows the number of unseen messages.

So I don't know what the right fix here would be.

1) Ignore the issue.  "% is for client-side splits"

2) Have nnimap follow the semantics for the other mail backends, and add
a dummy thing to nnmail-split-history if a `g' registers new messages.
Simple enough to do.

3) Add a new ?W spec (or something) that would just show a "%" on all
groups with unseen messages.
                  
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: upgrade notes

[Wes Hardaker]

>>>>> On Fri, 04 Feb 2011 09:42:21 -0800, Lars Ingebrigtsen <larsi@gnus.org> said:

LI> Oh, right.  Otherwise everything is OK?  It's showing the correct number
LI> of messages and everything?

Yep.  The unread number gets updated.

LI> The % mark is something that I must admit I can't recall ever hearing
LI> about, even though "git blame" claims that I added it in 1998.  So it's
LI> supposed to appear on groups that have new mail after you do a `g'?
LI> That sounds quite useful, actually.  :-)

It is (err...  was)...

LI> Is this correct?  The `%' would stay there over several `g' runs?  I may
LI> be misreading the code.

Yep.  That's correct.  If I enter the group, but don't read anything,
and exit it would go away.

Functionally it was an "indication that new mail was in the group since
the last time I had been in it".

LI> 1) Ignore the issue.  "% is for client-side splits"

:-(

LI> 2) Have nnimap follow the semantics for the other mail backends, and add
LI> a dummy thing to nnmail-split-history if a `g' registers new messages.
LI> Simple enough to do.

That sounds like it would work.  I think.  Since I'm not familiar with
how splitting in gnus is done (I used it once back in like, um, 1960 I
think) I'm not sure if that sentence meets my functionality described
above or not.

LI> 3) Add a new ?W spec (or something) that would just show a "%" on
LI>    all groups with unseen messages.

I *think* that's right too.  I have lots of "unread" messages in groups
because I typically will go into a box, read something and then "unmark"
it again because I need to deal with it later (where read-marks are left
on stuff that is "don't delete yet, but it's not functionally a
todo-list item").

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Lars Ingebrigtsen]

Wes Hardaker <wes@hardakers.net> writes:

> Yep.  That's correct.  If I enter the group, but don't read anything,
> and exit it would go away.
>
> Functionally it was an "indication that new mail was in the group since
> the last time I had been in it".

Right.  I switched it on, and I misremembered slightly how it worked.
It's like a non-permanent "unseen" mark -- it'll stay there until you
visit the group, or you exit Gnus.

I've now implemented the same logic for nnimap.

> I *think* that's right too.  I have lots of "unread" messages in groups
> because I typically will go into a box, read something and then "unmark"
> it again because I need to deal with it later (where read-marks are left
> on stuff that is "don't delete yet, but it's not functionally a
> todo-list item").

I used to show %U instead of %R -- that is, only show how many unseen
articles there are in each group, because I'd also do that.  And that
works across Gnus sessions, too.  But if you never quit/restart Gnus,
then there isn't much difference between the two.  :-)  (Except that %R
works on NNTP groups, too.)

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

Re: upgrade notes

[Wes Hardaker]

>>>>> On Mon, 07 Feb 2011 02:25:30 -0800, Lars Ingebrigtsen <larsi@gnus.org> said:

LI> I've now implemented the same logic for nnimap.

Awesome, thanks.  I'll go pull right now as I've really missed it.

LI> I used to show %U instead of %R -- that is, only show how many unseen
LI> articles there are in each group, because I'd also do that.  And that
LI> works across Gnus sessions, too.

Huh.  I'll try that too.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Wes Hardaker]

>>>>> On Mon, 07 Feb 2011 08:43:46 -0800, Wes Hardaker <wes@hardakers.net> said:

LI> I used to show %U instead of %R -- that is, only show how many unseen
LI> articles there are in each group, because I'd also do that.  And that
LI> works across Gnus sessions, too.

WH> Huh.  I'll try that too.

I've finally changed the gnus-group-line-format away from the default (I
think it's probably one of the only main variables I've never changed).
I was actually thinking that by having %U in there that it might mean I
could drop the %l.  But no, the %l is definitely very very helpful
visually.  So now I have both!  (*and* %R, which I moved to the end of
the line).
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Eric S Fraga]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> On Mon, 07 Feb 2011 08:43:46 -0800, Wes Hardaker <wes@hardakers.net> said:
>
> LI> I used to show %U instead of %R -- that is, only show how many unseen
> LI> articles there are in each group, because I'd also do that.  And that
> LI> works across Gnus sessions, too.
>
> WH> Huh.  I'll try that too.
>
> I've finally changed the gnus-group-line-format away from the default (I
> think it's probably one of the only main variables I've never changed).
> I was actually thinking that by having %U in there that it might mean I
> could drop the %l.  But no, the %l is definitely very very helpful
> visually.  So now I have both!  (*and* %R, which I moved to the end of
> the line).

What does %l do?  I cannot find any reference to this in the docs or the
code?  (I'm always looking for interesting customisations)

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 + No Gnus v0.11

Re: upgrade notes

[Wes Hardaker]

>>>>> On Mon, 07 Feb 2011 20:42:57 +0000, Eric S Fraga <e.fraga@ucl.ac.uk> said:

ESF> What does %l do?  I cannot find any reference to this in the docs or the
ESF> code?  (I'm always looking for interesting customisations)

I meant %m, sorry...
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: upgrade notes

[Reiner Steib]

On Fri, Feb 04 2011, Lars Ingebrigtsen wrote:

> Wes Hardaker <wes@hardakers.net> writes:
>>   gpg.el:
>>     (error "The gpg.el file is no longer needed; please stop requiring
>>     it.  In 2020 this file will be removed permanently")
>
> I don't know what happened to gpg.el, exactly.  Anybody?

You removed it ... :-)

,----[ contrib/ChangeLog ]
| 2010-09-26  Lars Magne Ingebrigtsen  <larsi@gnus.org>
| 
| 	* gpg.el: Removed -- seems unused.
`----

gpg.el was obsoleted by PGG (which is now obsoleted by EasyPG).

Anyhow, (require 'gpg) only work is you have contrib/ in `load-path'
which is not a good idea in the first place:

,----[ contrib/README ]
| The files in this directory are not (yet) part of the Gnus
| distribution proper.  They may later become part of the
| distribution, or they may disappear altogether.
| 
| Please note that it is NOT good to just add this directory to
| `load-path': a number of files in this directory will become part of
| more recent Emacs versions, so that you might be running obsolete
| libraries with all kinds of ill effects
| (cf. `list-load-path-shadows').
`----

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

Re: upgrade notes

[Lars Ingebrigtsen]

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

> Anyhow, (require 'gpg) only work is you have contrib/ in `load-path'
> which is not a good idea in the first place:

Ah, OK.  You'd have to expect contrib/ stuff to come and go...

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

Re: upgrade notes

[Steinar Bang]

>>>>> Wes Hardaker <wes@hardakers.net>:

> + My folders no longer show which folders have new messages in them.
>   [splitting is done via procmail on the server, and I know the new
>   marks exist there since my running qmailcheck biff window displays
>   properly "new" flagged messages, as did the older gnus version]

Hm... similar to my setup.  procmail splitting into dovecot folders.

I have no problems right now, but I had a bit of a problem until I
did `M-g' on the troublesome nnimap groups for a couple of times.

BTW, which dovecot do you have?  Version number may say whether it
supports QRESYNC or not.

Re: upgrade notes

[Wes Hardaker]

SB> BTW, which dovecot do you have?  Version number may say whether it
SB> supports QRESYNC or not.

Well, I checked the headers instead which says it does do QRESYNC.  So
version 1.2.16 certainly does :-)

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/