wrong unread count after INBOX change

wrong unread count after INBOX change

[Alan Schmitt]

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

Hello,

As I modified my dovecot configuration, I had to change where the INBOX
is stored. It should have been transparent to gnus (I access my mail
locally through dovecot) but for some reason it confused it and gnus now
believe I have 3900 unread message in this INBOX, although there is
none. I tried doing 'g' and 'M-g' on it but it does not change anything.
If I hit 'ret' I get an error "Can't select group", and if I it 'C-u
ret' I see the expected 27 read messages.

How can I convince gnus to reset its unread count for this mailbox?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> As I modified my dovecot configuration, I had to change where the INBOX
> is stored. It should have been transparent to gnus (I access my mail
> locally through dovecot) but for some reason it confused it and gnus now
> believe I have 3900 unread message in this INBOX, although there is
> none. I tried doing 'g' and 'M-g' on it but it does not change anything.
> If I hit 'ret' I get an error "Can't select group", and if I it 'C-u
> ret' I see the expected 27 read messages.
>
> How can I convince gnus to reset its unread count for this mailbox?

The sure-fire rip-cord solution for this sort of situation is to edit
the group parameters for that group, completely delete the (active .
XXXX) sexp, finish the edits, then M-g on the group again.

Works most every time, for me!

Of course, I can't currently confirm this, because editing a group in
the Group buffer currently gives me:

gnus-group-edit-group: Symbol’s function definition is void:
gnus-format-message

:(

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> Hello,
>>
>> As I modified my dovecot configuration, I had to change where the INBOX
>> is stored. It should have been transparent to gnus (I access my mail
>> locally through dovecot) but for some reason it confused it and gnus now
>> believe I have 3900 unread message in this INBOX, although there is
>> none. I tried doing 'g' and 'M-g' on it but it does not change anything.
>> If I hit 'ret' I get an error "Can't select group", and if I it 'C-u
>> ret' I see the expected 27 read messages.
>>
>> How can I convince gnus to reset its unread count for this mailbox?
>
> The sure-fire rip-cord solution for this sort of situation is to edit
> the group parameters for that group, completely delete the (active .
> XXXX) sexp, finish the edits, then M-g on the group again.
>
> Works most every time, for me!
>
> Of course, I can't currently confirm this, because editing a group in
> the Group buffer currently gives me:
>
> gnus-group-edit-group: Symbol’s function definition is void:
> gnus-format-message

`gnus-format-message' is now a defalias in gnus-util.el:

(defalias 'gnus-format-message
  (if (fboundp 'format-message) 'format-message
    ;; for Emacs < 25, and XEmacs, don't worry about quote translation.
    'format))

But even running (require 'gnus-util) doesn't cause this to be loaded, I
have to go and C-x C-e on it. Which I find very weird!

Re: wrong unread count after INBOX change

[Alan Schmitt]

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

On 2016-01-05 17:18, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> Hello,
>>
>> As I modified my dovecot configuration, I had to change where the INBOX
>> is stored. It should have been transparent to gnus (I access my mail
>> locally through dovecot) but for some reason it confused it and gnus now
>> believe I have 3900 unread message in this INBOX, although there is
>> none. I tried doing 'g' and 'M-g' on it but it does not change anything.
>> If I hit 'ret' I get an error "Can't select group", and if I it 'C-u
>> ret' I see the expected 27 read messages.
>>
>> How can I convince gnus to reset its unread count for this mailbox?
>
> The sure-fire rip-cord solution for this sort of situation is to edit
> the group parameters for that group, completely delete the (active .
> XXXX) sexp, finish the edits, then M-g on the group again.
>
> Works most every time, for me!
>
> Of course, I can't currently confirm this, because editing a group in
> the Group buffer currently gives me:
>
> gnus-group-edit-group: Symbol’s function definition is void:
> gnus-format-message

I'm seeing the same thing, but I can still edit using 'G c' (edit
through customize interface). Unfortunately it does not change anything:
as soon as I 'M-g' on it I get back the same active sexp.

I also tried removing the "modseq" sexp, to no avail.

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2016-01-05 17:18, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>>
>>> Hello,
>>>
>>> As I modified my dovecot configuration, I had to change where the INBOX
>>> is stored. It should have been transparent to gnus (I access my mail
>>> locally through dovecot) but for some reason it confused it and gnus now
>>> believe I have 3900 unread message in this INBOX, although there is
>>> none. I tried doing 'g' and 'M-g' on it but it does not change anything.
>>> If I hit 'ret' I get an error "Can't select group", and if I it 'C-u
>>> ret' I see the expected 27 read messages.
>>>
>>> How can I convince gnus to reset its unread count for this mailbox?
>>
>> The sure-fire rip-cord solution for this sort of situation is to edit
>> the group parameters for that group, completely delete the (active .
>> XXXX) sexp, finish the edits, then M-g on the group again.
>>
>> Works most every time, for me!
>>
>> Of course, I can't currently confirm this, because editing a group in
>> the Group buffer currently gives me:
>>
>> gnus-group-edit-group: Symbol’s function definition is void:
>> gnus-format-message
>
> I'm seeing the same thing, but I can still edit using 'G c' (edit
> through customize interface). Unfortunately it does not change anything:
> as soon as I 'M-g' on it I get back the same active sexp.
>
> I also tried removing the "modseq" sexp, to no avail.

Oops, that was the only weapon in my arsenal. I suppose you might
consider just removing the server and re-adding it. I don't know what
else can be done.

Re: wrong unread count after INBOX change

[Alan Schmitt]

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

On 2016-01-05 17:55, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>>> The sure-fire rip-cord solution for this sort of situation is to edit
>>> the group parameters for that group, completely delete the (active .
>>> XXXX) sexp, finish the edits, then M-g on the group again.
>>>
>>> Works most every time, for me!
>>>
>>> Of course, I can't currently confirm this, because editing a group in
>>> the Group buffer currently gives me:
>>>
>>> gnus-group-edit-group: Symbol’s function definition is void:
>>> gnus-format-message
>>
>> I'm seeing the same thing, but I can still edit using 'G c' (edit
>> through customize interface). Unfortunately it does not change anything:
>> as soon as I 'M-g' on it I get back the same active sexp.
>>
>> I also tried removing the "modseq" sexp, to no avail.
>
> Oops, that was the only weapon in my arsenal. I suppose you might
> consider just removing the server and re-adding it. I don't know what
> else can be done.

Even this does not work: there is some data cached somewhere, and gnus
is using it.

What I did:
- replace the select-method by nnnil
- relaunch emacs and gnus
- put back the select-method

and all is back as it was before.

How can I really remove a server from gnus (as in, get rid of all the
cached data for that server)? Is this when I delete .newsrc?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: wrong unread count after INBOX change

[CHENG Gao]

*On Tue, 05 Jan 2016 11:32:48 +0100
* Also sprach Alan Schmitt <alan.schmitt@polytechnique.org>:

> On 2016-01-05 17:55, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>>> The sure-fire rip-cord solution for this sort of situation is to edit
>>>> the group parameters for that group, completely delete the (active .
>>>> XXXX) sexp, finish the edits, then M-g on the group again.
>>>>
>>>> Works most every time, for me!
>>>>
>>>> Of course, I can't currently confirm this, because editing a group in
>>>> the Group buffer currently gives me:
>>>>
>>>> gnus-group-edit-group: Symbol’s function definition is void:
>>>> gnus-format-message
>>>
>>> I'm seeing the same thing, but I can still edit using 'G c' (edit
>>> through customize interface). Unfortunately it does not change anything:
>>> as soon as I 'M-g' on it I get back the same active sexp.
>>>
>>> I also tried removing the "modseq" sexp, to no avail.
>>
>> Oops, that was the only weapon in my arsenal. I suppose you might
>> consider just removing the server and re-adding it. I don't know what
>> else can be done.
>
> Even this does not work: there is some data cached somewhere, and gnus
> is using it.
>
> What I did:
> - replace the select-method by nnnil
> - relaunch emacs and gnus
> - put back the select-method
>
> and all is back as it was before.
>
> How can I really remove a server from gnus (as in, get rid of all the
> cached data for that server)? Is this when I delete .newsrc?
>
> Thanks,
>
> Alan

Is it related to Gnus agent? Do you use unplugged mode?

And maybe you can just leave gnus-select-method as nnnil, and put all
into gnus-secondary-select-methods to see for some time if it works.

I am a little suspicious of gnus-select-method, though I can not prove.

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2016-01-05 17:55, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>>> The sure-fire rip-cord solution for this sort of situation is to edit
>>>> the group parameters for that group, completely delete the (active .
>>>> XXXX) sexp, finish the edits, then M-g on the group again.
>>>>
>>>> Works most every time, for me!
>>>>
>>>> Of course, I can't currently confirm this, because editing a group in
>>>> the Group buffer currently gives me:
>>>>
>>>> gnus-group-edit-group: Symbol’s function definition is void:
>>>> gnus-format-message
>>>
>>> I'm seeing the same thing, but I can still edit using 'G c' (edit
>>> through customize interface). Unfortunately it does not change anything:
>>> as soon as I 'M-g' on it I get back the same active sexp.
>>>
>>> I also tried removing the "modseq" sexp, to no avail.
>>
>> Oops, that was the only weapon in my arsenal. I suppose you might
>> consider just removing the server and re-adding it. I don't know what
>> else can be done.
>
> Even this does not work: there is some data cached somewhere, and gnus
> is using it.
>
> What I did:
> - replace the select-method by nnnil
> - relaunch emacs and gnus
> - put back the select-method
>
> and all is back as it was before.
>
> How can I really remove a server from gnus (as in, get rid of all the
> cached data for that server)? Is this when I delete .newsrc?

Oh man, I don't think you should ever delete .newsrc -- you mean
.newsrc.eld, right? That will wipe out all the data for all your
servers. And your IMAP server settings probably aren't kept in the other
.newsrc file at all. You might open .newsrc.eld and look in
`gnus-newsrc-alist', and just see if the deleted server is still in
there somewhere. But even then I would go editing that file.

Was the IMAP server agentized? I suppose that could result in some data
being cached...

Re: wrong unread count after INBOX change

[Alan Schmitt]

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

On 2016-01-05 19:02, CHENG Gao <chenggao@royau.me> writes:

>> How can I really remove a server from gnus (as in, get rid of all the
>> cached data for that server)? Is this when I delete .newsrc?
>>
>> Thanks,
>>
>> Alan
>
> Is it related to Gnus agent? Do you use unplugged mode?
>
> And maybe you can just leave gnus-select-method as nnnil, and put all
> into gnus-secondary-select-methods to see for some time if it works.
>
> I am a little suspicious of gnus-select-method, though I can not prove.

I ended up moving the group to a secondary method and changing its name.
It's back to sane now.

I've tried using the agent in the past but I have not done much with it…
I should try to disable it if I don't use it more.

Thanks for the suggestions,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: wrong unread count after INBOX change

[Alan Schmitt]

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

On 2016-01-05 19:08, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> How can I really remove a server from gnus (as in, get rid of all the
>> cached data for that server)? Is this when I delete .newsrc?
>
> Oh man, I don't think you should ever delete .newsrc -- you mean
> .newsrc.eld, right? That will wipe out all the data for all your
> servers. And your IMAP server settings probably aren't kept in the other
> .newsrc file at all. You might open .newsrc.eld and look in
> `gnus-newsrc-alist', and just see if the deleted server is still in
> there somewhere. But even then I would go editing that file.
>
> Was the IMAP server agentized? I suppose that could result in some data
> being cached...

I ended up changing the server name, so gnus thought it was another one.
Thanks for the help (gnus can be intimidating sometimes…)!

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2016-01-05 19:08, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> How can I really remove a server from gnus (as in, get rid of all the
>>> cached data for that server)? Is this when I delete .newsrc?
>>
>> Oh man, I don't think you should ever delete .newsrc -- you mean
>> .newsrc.eld, right? That will wipe out all the data for all your
>> servers. And your IMAP server settings probably aren't kept in the other
>> .newsrc file at all. You might open .newsrc.eld and look in
>> `gnus-newsrc-alist', and just see if the deleted server is still in
>> there somewhere. But even then I would go editing that file.
>>
>> Was the IMAP server agentized? I suppose that could result in some data
>> being cached...
>
> I ended up changing the server name, so gnus thought it was another one.
> Thanks for the help (gnus can be intimidating sometimes…)!

No kidding...

Re: wrong unread count after INBOX change

[Dave Goldberg]

>
> But even running (require 'gnus-util) doesn't cause this to be loaded, I
> have to go and C-x C-e on it. Which I find very weird!

Most likely that's because a different gnus-util is already loaded.  Perhaps you've got a load-path shadow assuming you run gnus from git in a directory different from the gnus provided with your emacs distribution.

At one point probably two or three years ago (you can find my ranting about it on this list's archives if you care ;-)) Fedora's emacs distribution included a site-start configuration that caused gnus-util to be loaded at start up.  Perhaps that's what's happening in your case?  If you do an "emacs -q" does (featurep 'gnus-util) return t?  If that's the case you can overrule it by loading (not requiring) gnus-util explicitly somewhere in your .emacs.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

david.goldberg6@verizon.net (Dave Goldberg) writes:

>>
>> But even running (require 'gnus-util) doesn't cause this to be loaded, I
>> have to go and C-x C-e on it. Which I find very weird!
>
> Most likely that's because a different gnus-util is already loaded.
> Perhaps you've got a load-path shadow assuming you run gnus from git
> in a directory different from the gnus provided with your emacs
> distribution.
>
> At one point probably two or three years ago (you can find my ranting
> about it on this list's archives if you care ;-)) Fedora's emacs
> distribution included a site-start configuration that caused gnus-util
> to be loaded at start up. Perhaps that's what's happening in your
> case? If you do an "emacs -q" does (featurep 'gnus-util) return t? If
> that's the case you can overrule it by loading (not requiring)
> gnus-util explicitly somewhere in your .emacs.

No, I'm pretty sure it's the code itself -- I never had this problem
before, and emacs -q cannot find the gnus-util feature, and... reverting
9b59bbc fixes the problem!

I don't know why having the defalias at top level would prevent it from
working, but apparently it does...

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> david.goldberg6@verizon.net (Dave Goldberg) writes:
>
>>>
>>> But even running (require 'gnus-util) doesn't cause this to be loaded, I
>>> have to go and C-x C-e on it. Which I find very weird!
>>
>> Most likely that's because a different gnus-util is already loaded.
>> Perhaps you've got a load-path shadow assuming you run gnus from git
>> in a directory different from the gnus provided with your emacs
>> distribution.
>>
>> At one point probably two or three years ago (you can find my ranting
>> about it on this list's archives if you care ;-)) Fedora's emacs
>> distribution included a site-start configuration that caused gnus-util
>> to be loaded at start up. Perhaps that's what's happening in your
>> case? If you do an "emacs -q" does (featurep 'gnus-util) return t? If
>> that's the case you can overrule it by loading (not requiring)
>> gnus-util explicitly somewhere in your .emacs.
>
> No, I'm pretty sure it's the code itself -- I never had this problem
> before, and emacs -q cannot find the gnus-util feature, and... reverting
> 9b59bbc fixes the problem!
>
> I don't know why having the defalias at top level would prevent it from
> working, but apparently it does...

Hmm, there may be more going on than I realized. It looks like I really
am loading the gnus-util.el that comes with Emacs, not from the Gnus git
repo. But then why did reverting that commit seem to fix it? I'll try a
few more times...

Re: wrong unread count after INBOX change

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> david.goldberg6@verizon.net (Dave Goldberg) writes:
>>
>>>>
>>>> But even running (require 'gnus-util) doesn't cause this to be loaded, I
>>>> have to go and C-x C-e on it. Which I find very weird!
>>>
>>> Most likely that's because a different gnus-util is already loaded.
>>> Perhaps you've got a load-path shadow assuming you run gnus from git
>>> in a directory different from the gnus provided with your emacs
>>> distribution.
>>>
>>> At one point probably two or three years ago (you can find my ranting
>>> about it on this list's archives if you care ;-)) Fedora's emacs
>>> distribution included a site-start configuration that caused gnus-util
>>> to be loaded at start up. Perhaps that's what's happening in your
>>> case? If you do an "emacs -q" does (featurep 'gnus-util) return t? If
>>> that's the case you can overrule it by loading (not requiring)
>>> gnus-util explicitly somewhere in your .emacs.
>>
>> No, I'm pretty sure it's the code itself -- I never had this problem
>> before, and emacs -q cannot find the gnus-util feature, and... reverting
>> 9b59bbc fixes the problem!
>>
>> I don't know why having the defalias at top level would prevent it from
>> working, but apparently it does...
>
> Hmm, there may be more going on than I realized. It looks like I really
> am loading the gnus-util.el that comes with Emacs, not from the Gnus git
> repo. But then why did reverting that commit seem to fix it? I'll try a
> few more times...

Well I'm not any closer to making sense of this. I do seem to be loading
the gnus-util that comes with Emacs, no matter what. And yet,
reverting/replacing that commit pretty clearly breaks (or fixes) whether
I'm able to use gnus-format-message. I'm stumped!