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

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