> 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
