--- Begin Message ---
Subject: |
27.0.50; Problems with nnimap groups with non-ASCII characters |
Date: |
Wed, 10 Apr 2019 15:15:34 +0200 |
This started showing up yesterday after recent changes in Gnus:
To reproduce: Create an nnimap group called "Tést". Restarting Gnus
will properly create the group "Tést", but Gnus will also say
nnimap read 12k from quimby.gnus.org (initial sync of 3 groups; please wait)
If you then quit Gnus and restart Gnus, this group will appear:
*: nnimap+quimby.gnus.org:T\351st
If you try to kill it, all the groups in the buffer will disappear.
So something went wrong during whatever the most recent group-related
changes were. :-)
In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
of 2019-04-09 built on stories
Repository revision: 44b306d3510e54432b76724583ea9405f1c90686
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 9 (stretch)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#35219: 27.0.50; Problems with nnimap groups with non-ASCII characters |
Date: |
Fri, 19 Apr 2019 09:14:54 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Katsumi Yamaoka <address@hidden> writes:
> On Thu, 18 Apr 2019 16:53:54 -0700, Eric Abrahamsen wrote:
>>>> Andy Moreton <address@hidden> writes:
>>>>> I see a similar symptom, but with a different recipe:
>>>>> - start Gnus
>>>>> - open the server buffer, select a server, and subscribe to a new group
>>>>> - quit the server buffer
>>>>> - in the group buffer, kill the group line for the new group
>>>>> At this point, emacs is busy but unresponsive. Breaking in with ^G
>>>>> results in emacs becoming responsive agin, but all of the group lines
>>>>> disappear from the group buffer.
> [...]
>>> After more testing, it seems that this wrong display depends on using
>>> topics in the group buffer. If I toggle topics off ('t' in the group
>>> buffer) then killing the newly added group appears to work normally.
> [...]
>
> I found what is happening then, too. At first such a new group
> is registered in only `gnus-newsrc-hashtb', not `gnus-active-hashtb'.
> When trying to kill the group in the group buffer of the topic mode,
> during the course of the procedures `gnus-group-change-level'
> deletes the group from `gnus-newsrc-hashtb', even so
> `gnus-group-goto-group' tries to go to the group, and fails.
>
> I also realized what `gnus-group-goto-group' does when the group
> is not found in the hash tables is nonsense.
>
> [...]
>> Yamaoka-san, this would revert some of your changes.
>
> Not revert but great improve. What is especially great is that
> making `g-g-g-g' needless to refer to the hash tables:
Yes, I like how this is simpler now.
>> - (let ((start (point))
>> - (active (and (or
>> - ;; Some kind of group may be only there.
>> - (gnus-active group)
>> - ;; All groups (but with exception) are there.
>> - (gnus-group-entry group))
>> - group)))
>> + (let ((start (point)))
> [...]
>> (gnus-text-property-search
>> - 'gnus-group active 'forward 'goto))
>> + 'gnus-group group 'forward 'goto))
[...]
>
> Anyway there is no other problem so far, so please push the patch.
Done! Thanks to both of you for testing.
Eric
--- End Message ---