GNU bug report logs - #67526
30.0.50; Regression: gnus-group-prev-group fails to move to first group

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Simon Leinen <simon.leinen <at> switch.ch>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67526 <at> debbugs.gnu.org
Subject: bug#67526: 30.0.50; Regression: gnus-group-prev-group fails to move to first group
Date: Sun, 03 Dec 2023 06:55:36 -0800

Simon Leinen <simon.leinen <at> switch.ch> writes:

>> I do note that the issue goes away when I revert a bit of your
>> change, as follows.  I haven't found out *why* that is necessary to
>> get the old behavior back...
>
> OK, I think I know now.  It was a mistake to add the "(if backward
> (bobp) ...)" branch.  Probably the intent was to restore symmetry for
> the backward-moving case.  But the pre-existing (eobp) test will
> succeed only when the cursor is *beyond* the last newsgroup line -
> because the end of the buffer is not at the end of the last newsgroup
> line, but on an empty line *after* that last newsgroup line.  Testing
> for (bobp) in the backwards case is not equivalent, because (at least
> in my case) the beginning of the buffer position is very much *on* a
> valid/eligible newsgroup line.  Maybe this is not the case for Eric,
> because he uses topic mode? Anyway in my limited testing, the old
> logic works fine for that case too.
>
> So I suggest to revert that part of Eric's change, as per the patch
> I'm resending here with a correction - I had written ENDP instead of
> EOBP, sorry about the confusion.
>
> diff --git a/lisp/gnus/gnus-group.el b/lisp/gnus/gnus-group.el
> index 9a1a6f9b27d..f2258026eca 100644
> --- a/lisp/gnus/gnus-group.el
> +++ b/lisp/gnus/gnus-group.el
> @@ -1758,7 +1758,7 @@ gnus-group-search-forward
>      (unless first-too
>        (forward-line way))
>      (while (and
> -	    (not (if backward (bobp) (eobp)))
> +	    (not (eobp))
>  	    (not (setq
>  		  found
>  		  (and
>
> If you're worried - and I haven't thought through whether this should
> be of any concern - that the (eobp) check should not be done in the
> backwards case, then a suitable alternate clause could be
>
>           (or backward (not (eobp)))

Well that's weird -- I'm not sure how I boffed my testing, but I'd
boffed it, and now I'm seeing the same result as you. Thanks for doing
the extra work.

I'm just going to revert to the original logic, with the obvious fix to
the progn sexp. I should know better than to start stomping off across
unfamiliar code...

Previous Next

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