emacs-orgmode
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]