GNU bug report logs -
#53352
29.0.50; IMAP INBOX not refreshing using `gnus-group-get-new-news'
Previous Next
Reported by: Michael Welsh Duggan <mwd <at> md5i.com>
Date: Tue, 18 Jan 2022 23:08:02 UTC
Severity: normal
Tags: moreinfo
Found in version 29.0.50
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53352 in the body.
You can then email your comments to 53352 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Tue, 18 Jan 2022 23:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Welsh Duggan <mwd <at> md5i.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 18 Jan 2022 23:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I have a gnus installation where the select method is as such:
;;; Select Method
(setq gnus-select-method
'(nnimap "localimap"
(nnimap-inbox "INBOX")
(nnimap-address "xxxxxxxx.xxx")))
The IMAP server is Dovecot 2.3.17.1. There's nothing special in the
group parameters for the INBOX folder, currently this:
((modseq . "6496")
(uidvalidity . "1374073954")
(active 1 . 2140)
(permanent-flags %Answered %Flagged %Deleted %Seen %Draft gnus-forward gnus-download %*))
The group activation level is 1.
Mail splitting is currently being handled by sieve, not by Gnus.
However, when sieve leaves a message in INBOX rather than sorting it to
another folder, it does not appear in INBOX using `g'
(gnus-group-get-new-news). Any mail that stays there does show up if I
use `M-g' (gnus-topic-get-new-news-this-topic) on the group. This only
happens for the INBOX folder. I don't believe INBOX should behave
differently from other folders in this regard.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
of 2022-01-12 built on miko
Repository revision: f2fcea2716405aac9a3a6013b284b6b7be634725
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Debian GNU/Linux bookworm/sid
Configured using:
'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
--with-native-compilation --with-xinput2'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF X11
XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Load-path shadows:
/home/md5i/.config/emacs/elpa/transient-20211105.100/transient hides /usr/local/share/emacs/29.0.50/lisp/transient
Features:
(shadow emacsbug dabbrev shr-color color sieve-mode org-element avl-tree
generator ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
ol-docview doc-view ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src
ob-comint org-pcomplete org-list org-faces org-entities noutline outline
org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol
org-keys oc org-compat advice org-macs org-loaddefs find-func cal-menu
calendar cal-loaddefs grep copyright time-stamp whitespace mailalias
smtpmail sendmail help-fns radix-tree magit-patch magit-subtree
magit-gitignore magit-ediff magit-extras calc-alg calc-ext calc-menu
calc calc-loaddefs rect calc-macs misearch multi-isearch tabify man
generic sh-script smie executable goto-addr vc-mtn vc-hg vc-bzr vc-src
vc-sccs vc-svn vc-cvs vc-rcs vc bug-reference face-remap thingatpt
vc-git vc-dispatcher flow-fill gnus-fun jka-compr image-mode exif
dired-aux mule-util sort gnus-cite mm-archive mail-extr qp gnus-async
gnus-bcklg gnus-ml disp-table gnus-topic cursor-sensor nndraft nnmh
nnfolder utf-7 epa-file network-stream gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime dig gnus-cache gnus-sum shr pixel-fill kinsoku svg gnus-demon nntp
gnus-group gnus-undo gnutls gnus-start gnus-dbus gnus-cloud gnus-spec
gnus-win flyspell ispell view pacproxy descr-text cus-edit pp cus-load
time sieve-manage sasl sasl-anonymous sasl-login sasl-plain rng-loc
rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util sgml-mode facemenu dom python tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat
parse-time iso8601 ls-lisp ps-print ps-print-loaddefs ps-def lpr picture
nm dbus xml magit-submodule magit-obsolete magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff diff-mode easy-mmode
git-commit log-edit pcvs-util add-log magit-core magit-autorevert
autorevert filenotify magit-margin magit-transient magit-process
with-editor shell pcomplete server magit-mode transient comp comp-cstr
warnings rx cl-extra edmacro kmacro help-mode format-spec magit-git
magit-section magit-utils crm dash nnimap nnmail gnus-int gnus-range
mail-source message yank-media rfc822 mml mml-sec epa mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader utf7 netrc nnoo gnus
wid-edit nnheader gnus-util time-date mail-utils gnus-o365-oauth2 oauth2
url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny plstore generated generic-x epg rfc6068
epg-config ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util dired-x dired dired-loaddefs compile
text-property-search comint ring ansi-color cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs derived
debian-el info package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map url-vars seq gv subr-x byte-opt
bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process native-compile emacs)
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Fri, 21 Jan 2022 10:30:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Michael Welsh Duggan <mwd <at> md5i.com> writes:
> I have a gnus installation where the select method is as such:
>
> ;;; Select Method
> (setq gnus-select-method
> '(nnimap "localimap"
> (nnimap-inbox "INBOX")
> (nnimap-address "xxxxxxxx.xxx")))
If you're not using Gnus to split the mail, wouldn't it make more sense
to leave nnimap-inbox as nil?
> Mail splitting is currently being handled by sieve, not by Gnus.
> However, when sieve leaves a message in INBOX rather than sorting it to
> another folder, it does not appear in INBOX using `g'
> (gnus-group-get-new-news). Any mail that stays there does show up if I
> use `M-g' (gnus-topic-get-new-news-this-topic) on the group. This only
> happens for the INBOX folder. I don't believe INBOX should behave
> differently from other folders in this regard.
I don't see any special handling of the folder called INBOX in nnimap.
Do you have the INBOX group on a too-high level? You said you're using
a group activation level of 1, but not what the level of the INBOX group
was.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 21 Jan 2022 10:30:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Sat, 22 Jan 2022 16:26:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>
>> I have a gnus installation where the select method is as such:
>>
>> ;;; Select Method
>> (setq gnus-select-method
>> '(nnimap "localimap"
>> (nnimap-inbox "INBOX")
>> (nnimap-address "xxxxxxxx.xxx")))
>
> If you're not using Gnus to split the mail, wouldn't it make more sense
> to leave nnimap-inbox as nil?
Likely. This is a leftover from when I was using Gnus to do splitting
instead of sieve. However, removing the `nnimap-inbox' clause and
restarting Gnus does not cause the unwanted behavior to change.
>> Mail splitting is currently being handled by sieve, not by Gnus.
>> However, when sieve leaves a message in INBOX rather than sorting it to
>> another folder, it does not appear in INBOX using `g'
>> (gnus-group-get-new-news). Any mail that stays there does show up if I
>> use `M-g' (gnus-topic-get-new-news-this-topic) on the group. This only
>> happens for the INBOX folder. I don't believe INBOX should behave
>> differently from other folders in this regard.
>
> I don't see any special handling of the folder called INBOX in nnimap.
> Do you have the INBOX group on a too-high level? You said you're using
> a group activation level of 1, but not what the level of the INBOX group
> was.
INBOX is at level 1.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Sun, 23 Jan 2022 12:59:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Michael Welsh Duggan <mwd <at> md5i.com> writes:
>> I don't see any special handling of the folder called INBOX in nnimap.
>> Do you have the INBOX group on a too-high level? You said you're using
>> a group activation level of 1, but not what the level of the INBOX group
>> was.
>
> INBOX is at level 1.
Could you try to (setq nnimap-record-commands t) and then `g' in Gnus
and then post the contents of the *imap log* buffer? That'll tell us
which commands we're sending to the IMAP server.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Sun, 23 Jan 2022 16:56:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>
>>> I don't see any special handling of the folder called INBOX in nnimap.
>>> Do you have the INBOX group on a too-high level? You said you're using
>>> a group activation level of 1, but not what the level of the INBOX group
>>> was.
>>
>> INBOX is at level 1.
>
> Could you try to (setq nnimap-record-commands t) and then `g' in Gnus
> and then post the contents of the *imap log* buffer? That'll tell us
> which commands we're sending to the IMAP server.
I'm not going to send the whole list unless you believe it's necessary.
The log (after `g') consists of 122 lines as follows:
11:42:43 [md5i.com] 91340 EXAMINE "mail.misc" (QRESYNC (1044651295 71865))
11:42:43 [md5i.com] 91341 EXAMINE "mail.junk" (QRESYNC (1162282036 126251))
(I removed the ^M at the end of log lines for this email.) This list
does not contain "INBOX". If you actually need the full list, I can
send it, but the line above is representative of them all.
`M-g' on the INBOX group elicits the following:
11:50:58 [md5i.com] 91840 EXAMINE "INBOX" (QRESYNC (1374073954 6508))
11:50:58 [md5i.com] 91841 SELECT "INBOX"
11:50:58 [md5i.com] 91842 UID FETCH 1:* FLAGS
11:50:58 [md5i.com] 91843 EXPUNGE
Entering the server buffer and typing `RET' on the IMAP server yields:
11:51:44 [md5i.com] 91844 LIST "" "*"
11:51:44 [md5i.com] 91845 EXAMINE "Archive"
... [122 elided lines]
11:51:44 [md5i.com] 91968 EXAMINE "INBOX"
And, in case it's important, yes, the last entry is "INBOX" in that
last log snippet.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 09:20:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Michael Welsh Duggan <mwd <at> md5i.com> writes:
> I'm not going to send the whole list unless you believe it's necessary.
> The log (after `g') consists of 122 lines as follows:
>
> 11:42:43 [md5i.com] 91340 EXAMINE "mail.misc" (QRESYNC (1044651295 71865))
> 11:42:43 [md5i.com] 91341 EXAMINE "mail.junk" (QRESYNC (1162282036 126251))
>
> (I removed the ^M at the end of log lines for this email.) This list
> does not contain "INBOX". If you actually need the full list, I can
> send it, but the line above is representative of them all.
When I try the same, I do get INBOX in the list of EXAMINES:
10:14:57 [quimby.gnus.org] 12526 EXAMINE "Sent" (QRESYNC (1457952636 8))
10:14:57 [quimby.gnus.org] 12527 EXAMINE "INBOX" (QRESYNC (1164213559 1225378))
So it sounds like somehow your Gnus is deciding not to activate the
INBOX group (because of some setting or other, I'd guess). I'm not sure
how you could debug that -- perhaps debug-on-entry on
nnimap-retrieve-group-data-early and see where the list of `infos' is
coming from, and see whether it includes INBOX and whether it's being
filtered out?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 16:16:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>
>> I'm not going to send the whole list unless you believe it's necessary.
>> The log (after `g') consists of 122 lines as follows:
>>
>> 11:42:43 [md5i.com] 91340 EXAMINE "mail.misc" (QRESYNC (1044651295 71865))
>> 11:42:43 [md5i.com] 91341 EXAMINE "mail.junk" (QRESYNC (1162282036 126251))
>>
>> (I removed the ^M at the end of log lines for this email.) This list
>> does not contain "INBOX". If you actually need the full list, I can
>> send it, but the line above is representative of them all.
>
> When I try the same, I do get INBOX in the list of EXAMINES:
>
> 10:14:57 [quimby.gnus.org] 12526 EXAMINE "Sent" (QRESYNC (1457952636 8))
> 10:14:57 [quimby.gnus.org] 12527 EXAMINE "INBOX" (QRESYNC (1164213559 1225378))
>
> So it sounds like somehow your Gnus is deciding not to activate the
> INBOX group (because of some setting or other, I'd guess). I'm not sure
> how you could debug that -- perhaps debug-on-entry on
> nnimap-retrieve-group-data-early and see where the list of `infos' is
> coming from, and see whether it includes INBOX and whether it's being
> filtered out?
This appears to be happening in `gnus-get-unread-articles' in the
initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
is explicitly set to the cdr of that list.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 16:35:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Michael Welsh Duggan <mwd <at> md5i.com> writes:
> This appears to be happening in `gnus-get-unread-articles' in the
> initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
> is explicitly set to the cdr of that list.
Oh! This must be a leftover from when `gnus-newsrc-alist' always had a
dummy first entry, but that was changed a while back. I think?
Eric, what's the status of the dummy.group that that used to be the
first element of gnus-newsrc-alist, but doesn't seem to be any more?
There's still a whole bunch of stuff in Gnus that skips the first
element because of that:
./lisp/gnus/gnus-sieve.el211: (let* ((newsrc (cdr gnus-newsrc-alist))
./lisp/gnus/gnus-kill.el653: (setq newsrc (cdr gnus-newsrc-alist))
./lisp/gnus/gnus-topic.el896: (cdr gnus-newsrc-alist)))
./lisp/gnus/gnus-cus.el1083: (cdr gnus-newsrc-alist)))
./lisp/gnus/gnus-cus.el1086: (cdr gnus-newsrc-alist))))))))
./lisp/gnus/gnus-group.el1942: (let ((alist (cdr gnus-newsrc-alist))
Do I misremember, or did you change this? At least there's no
dummy.group as the car of my (and Michaels) gnus-newsrc-alist-s
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 16:35:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On Jan 24 2022, Michael Welsh Duggan wrote:
> This appears to be happening in `gnus-get-unread-articles' in the
> initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
> is explicitly set to the cdr of that list.
The first element of gnus-newsrc-alist is supposed to be the
dummy.group, but that doesn't appear to be the case any more. Can this
be related to commit a09306d53b?
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 18:00:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 01/24/22 17:34 PM, Andreas Schwab wrote:
> On Jan 24 2022, Michael Welsh Duggan wrote:
>
>> This appears to be happening in `gnus-get-unread-articles' in the
>> initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
>> is explicitly set to the cdr of that list.
>
> The first element of gnus-newsrc-alist is supposed to be the
> dummy.group, but that doesn't appear to be the case any more. Can this
> be related to commit a09306d53b?
Yup, looks like that's the problem. After the first time you save Gnus,
`gnus-newsrc-alist' has been redefined to exclude "dummy.group". It
should be easy to fix -- I'll move the sorting and exclusion into the
`let', which will preserve the variable's original value.
I suppose the Emacs 28 ship has sailed? It would be nice to include this
fix in the release.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 18:07:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> On 01/24/22 17:34 PM, Andreas Schwab wrote:
>> On Jan 24 2022, Michael Welsh Duggan wrote:
>>
>>> This appears to be happening in `gnus-get-unread-articles' in the
>>> initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
>>> is explicitly set to the cdr of that list.
>>
>> The first element of gnus-newsrc-alist is supposed to be the
>> dummy.group, but that doesn't appear to be the case any more. Can this
>> be related to commit a09306d53b?
>
> Yup, looks like that's the problem. After the first time you save Gnus,
> `gnus-newsrc-alist' has been redefined to exclude "dummy.group". It
> should be easy to fix -- I'll move the sorting and exclusion into the
> `let', which will preserve the variable's original value.
To be clear, would this mean I need to add "dummy.group" to my
`gnus-newsrc-alist' after you make this change, or will the change
obviate the need for the dummy entry? If the former, would you please
verify the form I need to prepend to the alist? Is it just the
"dummy.group" string?
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 18:33:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> I suppose the Emacs 28 ship has sailed? It would be nice to include this
> fix in the release.
It's a regression from 27.2, so including a fix in Emacs 28 would be
appropriate (if it's simple enough). But we can run it on master for a
while before backporting.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 18:49:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 01/24/22 13:06 PM, Michael Welsh Duggan wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> On 01/24/22 17:34 PM, Andreas Schwab wrote:
>>> On Jan 24 2022, Michael Welsh Duggan wrote:
>>>
>>>> This appears to be happening in `gnus-get-unread-articles' in the
>>>> initial `let*'. "INBOX" is the car of `gnus-newsrc-alist', and `newsrc'
>>>> is explicitly set to the cdr of that list.
>>>
>>> The first element of gnus-newsrc-alist is supposed to be the
>>> dummy.group, but that doesn't appear to be the case any more. Can this
>>> be related to commit a09306d53b?
>>
>> Yup, looks like that's the problem. After the first time you save Gnus,
>> `gnus-newsrc-alist' has been redefined to exclude "dummy.group". It
>> should be easy to fix -- I'll move the sorting and exclusion into the
>> `let', which will preserve the variable's original value.
>
> To be clear, would this mean I need to add "dummy.group" to my
> `gnus-newsrc-alist' after you make this change, or will the change
> obviate the need for the dummy entry? If the former, would you please
> verify the form I need to prepend to the alist? Is it just the
> "dummy.group" string?
You won't have to do anything. With the code as it is, the dummy group
is present at Gnus startup, but gets deleted on first save. I'll put in
a fix that makes sure it doesn't get deleted. That should take care of
things.
There's no longer any need for a dummy group, and in the long run it
would be good to get rid of it. But I think in short term we still think
there's a significant amount of out-of-tree code that might be expecting
a dummy group.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 19:22:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 53352 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/24/22 19:31 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I suppose the Emacs 28 ship has sailed? It would be nice to include this
>> fix in the release.
>
> It's a regression from 27.2, so including a fix in Emacs 28 would be
> appropriate (if it's simple enough). But we can run it on master for a
> while before backporting.
Okay, good. I'm attaching the patch I'm using right now -- this appears
to fix it. I'll give it another day or two.
Eric
[preserve-gnus-newsrc-alist.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 21:17:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> On 01/24/22 19:31 PM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>>> I suppose the Emacs 28 ship has sailed? It would be nice to include this
>>> fix in the release.
>>
>> It's a regression from 27.2, so including a fix in Emacs 28 would be
>> appropriate (if it's simple enough). But we can run it on master for a
>> while before backporting.
>
> Okay, good. I'm attaching the patch I'm using right now -- this appears
> to fix it. I'll give it another day or two.
I can confirm that this solves the problem for me, at least for some
simple local testing. I'll run with this patch applied for a few days
as well.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 24 Jan 2022 22:19:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Michael Welsh Duggan <mwd <at> md5i.com> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> On 01/24/22 19:31 PM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>>
>>>> I suppose the Emacs 28 ship has sailed? It would be nice to include this
>>>> fix in the release.
>>>
>>> It's a regression from 27.2, so including a fix in Emacs 28 would be
>>> appropriate (if it's simple enough). But we can run it on master for a
>>> while before backporting.
>>
>> Okay, good. I'm attaching the patch I'm using right now -- this appears
>> to fix it. I'll give it another day or two.
>
> I can confirm that this solves the problem for me, at least for some
> simple local testing. I'll run with this patch applied for a few days
> as well.
Great, thank you! I'll aim to push on say Thursday, then we can let it
simmer on master for a bit, then backport to 28.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 31 Jan 2022 14:33:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>>> On 01/24/22 19:31 PM, Lars Ingebrigtsen wrote:
>>>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>>>
>>>>> I suppose the Emacs 28 ship has sailed? It would be nice to include this
>>>>> fix in the release.
>>>>
>>>> It's a regression from 27.2, so including a fix in Emacs 28 would be
>>>> appropriate (if it's simple enough). But we can run it on master for a
>>>> while before backporting.
>>>
>>> Okay, good. I'm attaching the patch I'm using right now -- this appears
>>> to fix it. I'll give it another day or two.
>>
>> I can confirm that this solves the problem for me, at least for some
>> simple local testing. I'll run with this patch applied for a few days
>> as well.
>
> Great, thank you! I'll aim to push on say Thursday, then we can let it
> simmer on master for a bit, then backport to 28.
Just a ping to make sure this didn't get forgotten.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Reply sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>:
You have taken responsibility.
(Mon, 31 Jan 2022 19:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Welsh Duggan <mwd <at> md5i.com>:
bug acknowledged by developer.
(Mon, 31 Jan 2022 19:28:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 53352-done <at> debbugs.gnu.org (full text, mbox):
On 01/31/22 09:32 AM, Michael Welsh Duggan wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>>
>>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>>
>>>> On 01/24/22 19:31 PM, Lars Ingebrigtsen wrote:
>>>>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>>>>
>>>>>> I suppose the Emacs 28 ship has sailed? It would be nice to include this
>>>>>> fix in the release.
>>>>>
>>>>> It's a regression from 27.2, so including a fix in Emacs 28 would be
>>>>> appropriate (if it's simple enough). But we can run it on master for a
>>>>> while before backporting.
>>>>
>>>> Okay, good. I'm attaching the patch I'm using right now -- this appears
>>>> to fix it. I'll give it another day or two.
>>>
>>> I can confirm that this solves the problem for me, at least for some
>>> simple local testing. I'll run with this patch applied for a few days
>>> as well.
>>
>> Great, thank you! I'll aim to push on say Thursday, then we can let it
>> simmer on master for a bit, then backport to 28.
>
> Just a ping to make sure this didn't get forgotten.
Not forgotten! But it was languishing in my local rebase pile, just
pushed.
I'm going to close this now, but please reopen if anything seems not to
be working as it should.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 10:50:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On Jan 24 2022, Eric Abrahamsen wrote:
> diff --git a/lisp/gnus/gnus-start.el b/lisp/gnus/gnus-start.el
> index 2cf11fb12f..dd9c277805 100644
> --- a/lisp/gnus/gnus-start.el
> +++ b/lisp/gnus/gnus-start.el
> @@ -2867,12 +2867,6 @@ gnus-gnus-to-quick-newsrc-format
> (princ "(setq gnus-newsrc-file-version ")
> (princ (gnus-prin1-to-string gnus-version))
> (princ ")\n"))
> - ;; Sort `gnus-newsrc-alist' according to order in
> - ;; `gnus-group-list'.
> - (setq gnus-newsrc-alist
> - (mapcar (lambda (g)
> - (nth 1 (gethash g gnus-newsrc-hashtb)))
> - (delete "dummy.group" gnus-group-list)))
But the sorting should still be permanent, shoudn't it?
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 16:51:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 02/07/22 11:49 AM, Andreas Schwab wrote:
> On Jan 24 2022, Eric Abrahamsen wrote:
>
>> diff --git a/lisp/gnus/gnus-start.el b/lisp/gnus/gnus-start.el
>> index 2cf11fb12f..dd9c277805 100644
>> --- a/lisp/gnus/gnus-start.el
>> +++ b/lisp/gnus/gnus-start.el
>> @@ -2867,12 +2867,6 @@ gnus-gnus-to-quick-newsrc-format
>> (princ "(setq gnus-newsrc-file-version ")
>> (princ (gnus-prin1-to-string gnus-version))
>> (princ ")\n"))
>> - ;; Sort `gnus-newsrc-alist' according to order in
>> - ;; `gnus-group-list'.
>> - (setq gnus-newsrc-alist
>> - (mapcar (lambda (g)
>> - (nth 1 (gethash g gnus-newsrc-hashtb)))
>> - (delete "dummy.group" gnus-group-list)))
>
> But the sorting should still be permanent, shoudn't it?
It really doesn't matter, at this point. `gnus-group-list' is the source
of authority on sorting (if the user isn't using topic mode), and
`gnus-newsrc-hashtb' is more and more just used for persisting to disk.
We want to save the sort order on shutdown, but during a Gnus session it
doesn't matter.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 17:43:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On Feb 07 2022, Eric Abrahamsen wrote:
> On 02/07/22 11:49 AM, Andreas Schwab wrote:
>> On Jan 24 2022, Eric Abrahamsen wrote:
>>
>>> diff --git a/lisp/gnus/gnus-start.el b/lisp/gnus/gnus-start.el
>>> index 2cf11fb12f..dd9c277805 100644
>>> --- a/lisp/gnus/gnus-start.el
>>> +++ b/lisp/gnus/gnus-start.el
>>> @@ -2867,12 +2867,6 @@ gnus-gnus-to-quick-newsrc-format
>>> (princ "(setq gnus-newsrc-file-version ")
>>> (princ (gnus-prin1-to-string gnus-version))
>>> (princ ")\n"))
>>> - ;; Sort `gnus-newsrc-alist' according to order in
>>> - ;; `gnus-group-list'.
>>> - (setq gnus-newsrc-alist
>>> - (mapcar (lambda (g)
>>> - (nth 1 (gethash g gnus-newsrc-hashtb)))
>>> - (delete "dummy.group" gnus-group-list)))
>>
>> But the sorting should still be permanent, shoudn't it?
>
> It really doesn't matter, at this point.
It doesn't? I get erroneous behaviour without this.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 21:18:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 02/07/22 18:42 PM, Andreas Schwab wrote:
> On Feb 07 2022, Eric Abrahamsen wrote:
>
>> On 02/07/22 11:49 AM, Andreas Schwab wrote:
>>> On Jan 24 2022, Eric Abrahamsen wrote:
>>>
>>>> diff --git a/lisp/gnus/gnus-start.el b/lisp/gnus/gnus-start.el
>>>> index 2cf11fb12f..dd9c277805 100644
>>>> --- a/lisp/gnus/gnus-start.el
>>>> +++ b/lisp/gnus/gnus-start.el
>>>> @@ -2867,12 +2867,6 @@ gnus-gnus-to-quick-newsrc-format
>>>> (princ "(setq gnus-newsrc-file-version ")
>>>> (princ (gnus-prin1-to-string gnus-version))
>>>> (princ ")\n"))
>>>> - ;; Sort `gnus-newsrc-alist' according to order in
>>>> - ;; `gnus-group-list'.
>>>> - (setq gnus-newsrc-alist
>>>> - (mapcar (lambda (g)
>>>> - (nth 1 (gethash g gnus-newsrc-hashtb)))
>>>> - (delete "dummy.group" gnus-group-list)))
>>>
>>> But the sorting should still be permanent, shoudn't it?
>>
>> It really doesn't matter, at this point.
>
> It doesn't? I get erroneous behaviour without this.
It shouldn't -- if you're not using topic mode, the group sorting is
drawn from `gnus-group-list'. And when you save->shutdown->restart Gnus,
`gnus-group-list' sorts `gnus-newsrc-alist', which gets written to file,
and on restart it is used to reconstruct the sort order for
`gnus-newsrc-alist'.
Can you tell me what the erroneous behaviour is, and also what "this"
refers to?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 21:35:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On Feb 07 2022, Eric Abrahamsen wrote:
> Can you tell me what the erroneous behaviour is,
Group rearrangements in *Group* are forgotten.
> and also what "this" refers to?
The hunk reverted with s/delete/remove/.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Mon, 07 Feb 2022 23:52:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 02/07/22 22:34 PM, Andreas Schwab wrote:
> On Feb 07 2022, Eric Abrahamsen wrote:
>
>> Can you tell me what the erroneous behaviour is,
>
> Group rearrangements in *Group* are forgotten.
`gnus-group-prepare-flat' (which I have to assume you're running) draws
its ordering from `gnus-group-list'. I'll try to reproduce your error.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Wed, 09 Feb 2022 04:39:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 53352 <at> debbugs.gnu.org (full text, mbox):
On 02/07/22 22:34 PM, Andreas Schwab wrote:
> On Feb 07 2022, Eric Abrahamsen wrote:
>
>> Can you tell me what the erroneous behaviour is,
>
> Group rearrangements in *Group* are forgotten.
So far I haven't been able to reproduce this:
1. Turn off topic-mode, if necessary.
2. Kill a group, and yank it somewhere else.
3. Re-list groups with "l": sort order doesn't change.
4. Save Gnus, re-list with "l": sort order doesn't change.
5. Shut Gnus down, restart: sort order is preserved.
And I tried the above using the sort commands instead of killing and
yanking groups.
Can you give me a recipe to produce the error?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Wed, 09 Feb 2022 08:46:03 GMT)
Full text and
rfc822 format available.
Message #84 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Try calling gnus-make-hashtable-from-newsrc-alist.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53352; Package
emacs.
(Thu, 10 Feb 2022 19:39:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 53352 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> Try calling gnus-make-hashtable-from-newsrc-alist.
Nope, still can't guess what you're talking about.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 11 Mar 2022 12:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 45 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.