> From: Dale <d...@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?
