bug#52593: [External] : bug#52593: 28.0.90; (thing-at-point thing) has so much overhead since commit 7db376e560448e61485ba054def8c82b21f33d6a

[Drew Adams <drew.adams@oracle.com>]

> > Maybe an optional arg for thing-at-point is necessary to respect fields?
> > As I understand, it should be determined by the user of thing-at-point to
> > get what kind of thing at point. If the user knows or expects fields in
> > the text, he passes the optional arg. If the user just wants the "normal"
> > thing at the point whether there are fields or not, he calls it without
> > the opt arg as the old way.

That's right - or almost so.  It's definitely right
that thing-at-point functions should not, on their
own and systematically, limit their check/search to
a field that might be present.  That would be awful.

But I think it should not just be an argument to
thing-at-point functions that controls/decides this.

Users, not just Lisp code, should be able to control
whether thing-at-point functions limit checking to a
field at point (when a field is present).

That means either a user option or a defvar that
users and code can bind, to get the behavior they
want.  But this question of how/where to tell
a thing-at-point function what to do about fields
is a secondary question.
___

I disagree strongly with Lars that from now on all
code that uses thing-at-point functions should
have its behavior changed to always respect a field
at point.  That would not only break existing code;
it would be inflexible for no reason.

IIUC, this is essentially about wanting to add a
NEW feature, which is that thing-at-point functions
can BE ABLE to return a thing (of the given kind),
while limiting the check/search to a field at point.

There's nothing wrong with adding that possibility,
as an optional feature.  It would be terribly wrong
to just impose such (backward incompatible) behavior
going forward.

Again: IIUC.

> If a package uses fields to make the buffer more
> understandable, then other packages like symbol-overlay
> should use those fields automatically without having to
> be altered.

Other packages "should"?  No.  Other packages should
perhaps _be able_ to.  Let's not be draconian, please.

Just because one package uses fields to "make the
buffer more understandable", it does not follow that
all (or even any) other packages want or need to
take that particular understandability into account
when checking for a particular kind of thing at
point.  That doesn't follow at all.

You have no way of knowing what some arbitrary other
package might want to do.  Supposing that all packages
must want to respect fields that are provided by some
package (for all of their behavior no less!) is, well,
misguided.

> Ideally the way to make this work would be to change all the thingatp
> functions to do their normal thing, but then see whether there's any
> field separators in that area, and if so, recalculate the "thing".

No, definitely not.  Thing-at-point functions can be
made _able_ to "recalculate the thing".  They should
not do so systematically or generally.

> I think at this point, the way forward is to revert this change on
> emacs-28 to fix the performance regression, and then open a new bug
> report for this.  So I'll do both now.

The bug is not just a performance one (IIUC).  The
bug is in the misguided design that limitation to a
field is what thing-at-point functions should always,
or even generally or by default, do.

Adding the ability to respect a field at point makes
sense.  The fact that a buffer has been given fields
should not, by itself, control what thing-at-point
functions do.  It can reasonably _inform_ what they do.