GNU bug report logs - #72995
31.0.50; widget-move fails when widget starts at the second character in the buffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dale <dale <at> codefu.org>, Stephen Berman <stephen.berman <at> gmx.net>
Cc: 72995 <at> debbugs.gnu.org
Subject: bug#72995: 31.0.50; widget-move fails when widget starts at the second character in the buffer
Date: Tue, 03 Sep 2024 15:35:29 +0300

> From: Dale <dale <at> codefu.org>
> Date: Mon, 2 Sep 2024 23:36:35 -0500
> 
> I think changes in commit 94dec95 (bug#69943) broke `widget-move' in a customize buffer when trying to move to the first widget in a buffer when that first widget starts at the second character in the buffer.  Here's some code to reproduce (tested in IELM):
> 
> (let* ((first-wid (progn (widget-forward 1) (point))))
>   (print (format "First widget at %S" first-wid))
>   (cl-assert (and (numberp first-wid) (>= first-wid 1)))
>   (with-current-buffer (customize-group 'editing)
>     (narrow-to-region (1- first-wid) (point-max))
>     (goto-char (point-min))
>     (widget-forward 1)
>     (print (format "Expected to be at %S, point=%S" first-wid (point)))))
> 
> On my Emacs I get:
> 
> "First widget at 33"
> 
> "Expected to be at 33, point=32"
> 
> I think this happens because of this code near the end of `widget-move' (which is called by `widget-forward'):
> 
>     (let ((new (widget-tabable-at)))
>       (while (and (eq (widget-tabable-at) new) (not (bobp)))
> 	(backward-char)))
>     (unless (bobp) (forward-char)))
> 
> In my test case, as we enter the while loop point is at the start of the first widget (AKA "new").  We are not yet at beginning of buffer, so it moves point back one character.  Now we are at beginning of buffer, but that doesn't matter: the `eq' test fails first, and the loop ends.
> 
> However, the `forward-char' never runs because we are indeed at beginning of buffer now.  I think this `forward-char' should have been run to put point back on the start of the widget.
> 
> Bug#70594 also recently modified code around here, but I don't *think* that's relevant.
> 
> In case you're wondering, this comes up because I use link-hint[1], which narrows a customize buffer in exactly the way shown above.
> 
> [1]: https://github.com/noctuid/link-hint.el
> 
> Please let me know if I can provide any more information!
> 
> Best regards,
> Dale

Stephen, could you please look into this?

Previous Next

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