[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PAT
From: |
Drew Adams |
Subject: |
RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point) |
Date: |
Tue, 30 Apr 2024 21:10:41 +0000 |
> 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.
(Yes, technically point is between the chars.)
And with a block cursor the cursor is on the
second thing, not the first.
And `C-x =' describes the current "cursor
position" (aka point), and it describes - wait
for it - not the char before point but the char
after point, IOW, colloquially the char at point.
And `forward-sexp', `forward-word', `forward-thing',
etc. advance just _past_ the thing. The cursor
is then _not_ on the thing, and unless the thing
is immediately followed by another thing, there's
_no_ thing at point.
Unfortunately, Emacs maintainers decided that
thingatpt.el isn't useful for anything except
obtaining something to use as a default value for
user input. The opinion was that no one ever
wants/needs to get nil, telling them that there's
no thing at point. Better, they think, to always
try to get a thing at point OR at (1- point).
This awful Emacs behavior defeats the successive
use of functions that do something with the next
thing at point, in precisely the case you cited:
when the next thing butts up against the previous
thing.
In particular, these important use cases are
defeated by the behavior chosen for Emacs:
1. To find out _whether there is_, in fact,
a THING at point. AT POINT - not point OR
(point - 1).
2. IF there really is a THING at point, to
return it (or its bounds).
See bug #9300, " `bounds-of-thing-at-point'
does not return nil when just after THING".
___
Library thingatpt+.el fixes this, providing
more useful behavior for thing-at-point, and
making more use cases possible.
It also provides functions for picking up a
thing that's _near_ point (where "near" can
be specified).
That's what Emacs _should_ do for the only
use case it even cares about, which is trying
to get a thing for use as a default value for
input. Getting a thing near point is quite
different from getting a thing _at point_.
___
https://www.emacswiki.org/emacs/download/thingatpt%2b.el