GNU bug report logs - #35219
27.0.50; Problems with nnimap groups with non-ASCII characters

Previous Next

Full log

Message #29 received at 35219 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Andy Moreton <andrewjmoreton <at> gmail.com>, 35219 <at> debbugs.gnu.org
Subject: Re: bug#35219: 27.0.50;
 Problems with nnimap groups with non-ASCII characters
Date: Fri, 19 Apr 2019 14:48:38 +0900

On Thu, 18 Apr 2019 16:53:54 -0700, Eric Abrahamsen wrote:
>>> Andy Moreton <andrewjmoreton <at> gmail.com> 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:

> -    (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))

Yes, the existing group should be found but nonexistent one
should not be found.

> With the attached change, Gnus' original behavior is restored for me,
> including the fact that `gnus-group-jump-to-group' will jump to
> non-existent groups (creating them in the process).

Wow!  I don't remember it but Gnus in Emacs 26.2 surely does so.
It is probably the right behavior of `gnus-group-jump-to-group':

2011-01-31  Lars Ingebrigtsen  <larsi at gnus.org>

	* gnus-group.el (gnus-group-jump-to-group): Allow jumping to groups
	that Gnus doesn't know exists again.

2011-01-28  Julien Danjou  <julien at danjou.info>

	* gnus-group.el (gnus-group-jump-to-group): Set must match to t.


	Probably Lars or someone made it allow non-existent
	group unconditionally at some time.

	In No Gnus, (gnus-read-active-file-p) was used as the
	must-match flag.


2004-05-21  Lars Magne Ingebrigtsen  <larsi at gnus.org>

	* gnus-group.el (gnus-group-jump-to-group): Don't prompt for
	non-active groups.


Anyway there is no other problem so far, so please push the patch.

Thanks.
Regards,

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.