bug#81427: 30.2; 30.2; forward-thing returns nil/t instead of the leftover count when a forward-thing-provider-alist entry is used

Ping!  Dominik, would you please respond to Sean's suggestions?

> From: Sean Whitton <[email protected]>
> Cc: [email protected]
> Date: Mon, 27 Jul 2026 10:16:24 +0100
> 
> Dominik Schrempf [20/Jul 10:17am +02] wrote:
> > I had some time on the weekend and attach a patch that fixes the
> > inconsistent (albeit undocumented and undefined) return value of
> > `forward-thing`.
> >
> > Two comments:
> >
> > - This is a tiny bit slower for larger N, because the forward-op branch
> >   goes one at a time.
> >
> > - The behavior of `(forward-thing ... 0)` is now consistent (do not move
> >   point), but that is now different from the behavior of `(forward-line
> >   0)`, which moves point to the beginning of the line. I added a test
> >   exercising this expectation, but you may disagree with this behavioral
> >   change.
> >
> > Let me know, if I can improve the patch!
> >
> > Also, the Evil people didn't reply yet: https://github.com/emacs-evil/evil/issues/2027
> 
> Thanks for the clear description of the problem and some of the
> trade-offs.
> 
> I agree that the basic problem is a bug in Evil, but also that it might
> be okay to document returning this value and then make forward-thing do
> so consistently.
> 
> OTOH, the two comments you make both seem like potentially serious
> downsides.  People often reach for the thingatpt functions, because
> they're very ergonomic, even when they're writing performance-sensitive
> code.  So we might make a lot of people's code slow when it was usably
> speedy before.  Depends on how serious the slowdown is.  Does your patch
> mean the time complexity (big-O notation) changes?
> 
> Breaking the behaviour of (forward-thing ... 0) seems like it will
> definitely break some people's code.  We usually try to avoid any such
> changes if we possibly can.
> 
> So, I'd like us to analyse the broader problem of what Evil is trying to
> do here, and whether there might be an alternative way to get it the
> information it needs without breaking changes, before going ahead with
> this.
> 
> -- 
> Sean Whitton
>