Thanks for your reply, Jim. > On 4/30/2024 2:10 PM, Drew Adams wrote: > >> I've also fixed a bug in EWW and bug-reference-mode > >> where it would return nil for (thing-at-point 'url) > >> if point was at the *end* of a URL. > > > > By "at the end" I assume you really mean just > > _after_ a URL, i.e., no longer on/at the URL. > > > > FWIW, that's actually _superior_ behavior. > > > > Unfortunately however, Emacs has chosen the > > behavior you describe here: > > > >> It's now consistent with how 'thing-at-point' > >> works by default. > > > >> (If you have two consecutive URLs and point > >> is between them...it'll prefer the second one.) > > > > Which is better! It's what "at point" means. > > > [snip] > > > > See bug #9300, " `bounds-of-thing-at-point' > > does not return nil when just after THING". > > I agree overall that your proposed behavior is more correct, and it's > probably how I'd have implemented 'thing-at-point' if I were doing it > from scratch. However, I think an even worse outcome than > "thing-at-point looks at point or before-point" is "sometimes > thing-at-point just looks at point, and other times it looks at point or > before-point" (which is what it does today).
Yes, such inconsistency is arguably worse than consistent bad behavior. Arguably worse - and arguably better. (That's in the nature of inconsistency - some will see a glass half full; others half empty.) > I'd even be open to something like a 'thing-at-point-is-strict' defvar > that people could let-bind as wanted, but I'm not going to *argue* for > that myself. > > Ultimately though, this patch is really just about providing the > necessary defcustoms for org-mode to be able to use 'thing-at-point' > (and for Ihor to feel ok about it ;)). Changing 'thing-at-point's > behavior should probably be handled separately, especially since there'd > be an uphill battle to revisit the decision in bug#9300. I hear you. The behavior should be changed so that, in general, bounds-of-thing-at-point etc. return nil when there is _no thing at point_, including when point is after, including just after, a thing but not on such a thing. There can be commands (and noncommand fns) that return things _near_ point, not only at point. And "near" can be configurable with an argument. In particular, they can do what the vanilla fns currently do: return a thing at OR just before point. But the "-at-point" functions shouldn't do that. They should do what their names say. It's important to have such functions. It's not just about arguing that strictly at-point is better than at-or-just-after-point. The point (sic) is that currently there's _no way to determine whether_ there's a thing at point. That's the real problem - no test for a thing at a given position. That means that a whole slew of possible applications of the feature are impossible to realize. ___ Along with the fix for this bug, there could also be a defvar, or even an option, that fuses the two behaviors (at OR just before), i.e., that gives the current, misguided behavior, to allow existing code or habits compatibility. It's not hard for Emacs to still DTRT. It just takes a decision and admission that the behavior was misguided and unnecessarily limiting (BIG time).
