2019-12-14 Gnus IMAP issues

I’ve started using Gnus again in recent weeks and months. One problem I have is that I enter the INBOX group using `C-u RET` or issue `/ o` inside the group to see *all* the mail in my INBOX, read and unread, but all I get are 17 mails. I know some are missing.

When I use the Server Buffer via `^` and enter the INBOX, I get 50 mails. This includes all the missing mails.

I sometimes suspect that it has to do with me reading mails on the phone, too.

Do you understand what’s going on? Many years ago I had decided that the Gnus Agent was a problem and disable it setting `gnus-agent` to `nil`. (My entire Gnus config is available online.)

Gnus config

​#Gnus ​#Emacs ​#IMAP

Comments

(Please contact me if you want to remove your comment.)

`/ w` runs the command gnus-summary-pop-limit

– gijs 2019-12-15 08:37 UTC

---

I don’t think this is a question of limits. When entering a group, read mail is not shown by default. When I then press `/ w`, nothing happens. When I press `/ o`, read mail is shown in the buffer. My problem is that not *all* read mail is shown in the buffer.

– Alex Schroeder 2019-12-15 10:04 UTC

---

I find Gnus nnimap is great,it practically runs itself, when imap is used as intended - keep it on the server. There is really no need to download everything. This is great for work email.

The .newsrc* files are not really needed, everything is on the imap server. They just make reading email faster. One can just delete them and start where the left, it will just take longer to sync.

I have a few comments on your gnus config:

1. For nnimap gnus-secondary-select-methods the group names are formatted as “nnimap+server:Groupname”. The “server” part should be the method label and not the nnimap-address. So for your archive, spam or trash groups, should use for example “nnimap+notifications:Archive”. To my understanding, the “server” string is more of the method label to distinguish from the other methods.

2. You must have your reasons for setting both the gnus-select-method and the gnus-secondary-select-method “notifications” to the same imap server (imap.migadu.com). This may be a source of confusion to gnus. The issues you are experiencing may come from a bad interaction between the two methods. From your config, it is not clear what distinguishes the two methods. May I suggest keeping only one and see if the issues persist ? I find gnus-select-method to be archaic, as it no longer makes any sense to treat any method as special. Setting gnus-select-method to ’(nnnil nil) and moving all method definition to gnus-secondary-select-methods gives the best experience IMV.

Btw, I’m a big fan of your work. Thank you for all the code contributions, post and of ourse the emacswiki work !! Amazing.

– DEUS MAX 2019-12-15 10:50 UTC

---

The reason I had done this was that for a while I had two mail accounts on the same server (`alex@alexschroeder.ch` and `notifications@alexschroeder.ch`). How do you set that up correctly, without delivering all the mails to a single account?

– Alex Schroeder 2019-12-15 12:07 UTC

---

No idea why Gnus is so popular! It’s OK for NNTP but not for e-mail. Ditch Gnus and user Wanderlust! 🙂

– zapata 2019-12-15 12:23 UTC

---

But I’ve been using Gnus for twenty years! I’ve got code in Gnus. I got the mug!

But yeah, perhaps one day I’ll do it.

– Alex Schroeder 2019-12-15 14:40 UTC

---

Setting up some stuff... starting `M-x wl`...

`condition-case: Wrong type argument: arrayp, nil`

This is not a good omen. 😐🔥🔥

`M-x toggle-debug-on-error` and then:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  signal(wrong-type-argument (arrayp nil))
  (condition-case obj (progn (if check (progn (message "Checking environment...") (wl-check-environment arg) (message "Checking environment...done") (message "Checking type of variables...") (wl-check-variables) (wl-check-variables-2) (message "Checking type of variables...done"))) (let ((inhibit-quit t)) (wl-plugged-init (wl-folder))) (if arg nil (run-hooks 'wl-auto-check-folder-pre-hook) (wl-folder-auto-check) (run-hooks 'wl-auto-check-folder-hook))) (error (if (buffer-live-p demo-buf) (kill-buffer demo-buf)) (signal (car obj) (cdr obj))) (quit))
  (let (demo-buf check) (if wl-init nil (if wl-demo (setq demo-buf (wl-demo))) (setq check t)) (wl-init) (condition-case obj (progn (if check (progn (message "Checking environment...") (wl-check-environment arg) (message "Checking environment...done") (message "Checking type of variables...") (wl-check-variables) (wl-check-variables-2) (message "Checking type of variables...done"))) (let ((inhibit-quit t)) (wl-plugged-init (wl-folder))) (if arg nil (run-hooks 'wl-auto-check-folder-pre-hook) (wl-folder-auto-check) (run-hooks 'wl-auto-check-folder-hook))) (error (if (buffer-live-p demo-buf) (kill-buffer demo-buf)) (signal (car obj) (cdr obj))) (quit)) (if wl-biff-check-folder-list (progn (if arg nil (wl-biff-check-folders)) (wl-biff-start))) (if (buffer-live-p demo-buf) (kill-buffer demo-buf)))
  wl(nil)

The problem appears to be this, when running `edebug` on `wl-check-environment`:

`(wl-folder-get-elmo-folder "+draft")`

And that’s even though `(wl-folder-get-elmo-folder "+queue")` returns nil, no error.

That’s because `(wl-folder-make-elmo-folder wl-draft-folder)` returns nil in `wl-draft-get-folder`.

I was debugging somewhere in the depths of `elmo-make-folder` when I decided to give and return to Gnus.

– Alex Schroeder 2019-12-15 19:39 UTC

---

As DEUX MAX said, you definitely shouldn’t configure the same email account several times.

I’ve switched to setting gnus-select-method to nnnil, and configuring everything in gnus-secondary-select-methods, to avoid confusing myself with the special status of the single account configured in gnus-select-method. I recommend that for everybody.

You can name methods in Gnus, so you can easily have multiple accounts on the same mail server:

(setq gnus-select-method '(nnnil))
(setq gnus-secondary-select-methods
   `(
        (nnimap "one" (nnimap-address "your.mailserver.example.org"))
        (nnimap "two" (nnimap-address "your.mailserver.example.org"))
         ...))

and then in your `.authinfo.gpg` you’d have something like:

machine one login yourlogin1 password ***** force yes port imaps
machine two login yourlogin2 password ***** force yes port imaps

Or something to that effect.

Your groups will then show up as `nnimap+one:blabla`, `nnimap+two:INBOX` etc.

– Adam 2019-12-18 19:58 UTC

Adam

---

Thanks! Will try that.

– Alex Schroeder 2019-12-18 21:44 UTC

---

I agree with Adam. It is best to ditch the gnus-select-method and move everything (configuration wise) in gnus-secondary-select-methods.

Treating an arbitrary method as special (primary) is bad holdover.

So yes, do use the The Empty backend :

The Empty backend

`(setq gnus-select-method '(nnnil ""))`

Alternative configuration, for using two accounts on the same imap server, can be:

(setq gnus-secondary-select-methods
  '((nnimap "one" (nnimap-address "imap.mailserver.org")(nnimap-user "user1")...)
    (nnimap "two" (nnimap-address "imap.mailserver.org")(nnimap-user "user2")...)
    ...))

and the .authinfo.gpg file:

`machine imap.mailserver.org login user1 password user1secret ....`

`machine imap.mailserver.org login user2 password user2secret ....`

This way, accounts get selected by the different user-names.

The strings “one” and “two” become just server labels, that can be conveniently chosen to provide for good looking gnus group names (`nnimap+serverlabel:Groupname`) that display nicely in the Group Buffer.

– DEUS MAX 2019-12-20 01:04 UTC

---

Thank you both.

– Alex Schroeder 2019-12-20 10:05 UTC

---

When you’re in the 17-mail inbox, what does `C-h v gnus-newsgroup-name` say? What does `M-: (length gnus-newsgroup-headers)` say?

When you’re in the 50-mail inbox, same questions.

– dickmao 2019-12-20 14:28 UTC

---

Somebody convinced me to simply go ahead and delete the `~/.newsrc*` files. As my setup was simple and I didn’t have much marked, it was no problem at all ­– and currently the two look alike again.

I’ll remember to do that, next time this happens though.

– Alex Schroeder 2019-12-20 20:20 UTC

---

Yes, `~/.newsrc*` state more than occasionally gets corrupted when gnus gets confused. Glad you’re back on track.

– dickmao 2019-12-21 16:02 UTC

---

The problem hast reappeared.

Here are the two last emails in my inbox:

... (16 other mails)
O    2020-02-18 [   7: xxxxxxxxx      ] über amazon data
O    2020-02-19 [   5: xxxxxxxxx      ] BBC - Travel - Japan’s perfectly imperfect garden

`gnus-newsgroup-name` → `"nnimap+migadu:INBOX"`

`(length gnus-newsgroup-headers)` → 18 (which is what I see)

When I got to the server buffer, I see the IMAP server:

     {nnimap:migadu} (opened)

When I browse it, it looks just fine:

      89: Archive
       7: Drafts
    1317: INBOX
    9954: Junk
       4: Notes
      75: Sent
    1162: Trash

When I try to enter the `INBOX`, however (using both `RET` and `C-u RET`):

Group nnimap+migadu:INBOX contains no messages
gnus-browse-read-group: Couldn’t enter nnimap+migadu:INBOX

And on the iPhone, the last four messages are:

So, I can see two emails on the phone that Gnus isn’t showing, and this time around the server setup is broken in some way.

So...

Am I going to delete the `~/.newsrc*` files again? Probably.

Is this making me distrust Gnus? Definitely.

– Alex Schroeder 2020-02-23 10:45 UTC

---

Actually, a new development. I entered the group and used `Z G` to rescan the group, then `/ o` to show the old messages – and now I have more messages in the summary buffer!

– Alex Schroeder 2020-02-24 00:16 CET

---

Dear Alex, I had the same problem for a long time – also trying to reuse Gnus after having stopped for 3, 4 years now.

Your solution Z G does work for me. Thanks a lot!!!

Side questions:

– Fab Rice 2020-11-15 17:16 UTC

---

Sadly, I don’t know the answers to your questions... and I have since stopped using Gnus again! 😭 These days I use aerc in the terminal and Evolution when I need to look at fancy stuff.

– 2020-11-15 19:25 UTC

---

Sad ! You have code, you have the mug...

– Deus Max 2020-11-16 22:02 UTC

---

Yeah, I just stopped trusting it and that’s the end for a mail client. 😟

– Alex Schroeder 2020-11-16 22:18 UTC