Comments on 2019-12-14 Gnus IMAP issues

/ 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


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 :

(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


Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit this page if you need to fix typos. You can subscribe to updates by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO