RE: Fwd: Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING

[Drew Adams]

> > The first thing I'd like to ask is whether the suffix "-at-point" means
> > the same thing everywhere it appears. If `bounds-of-thing-at-point' is the
> > only place where it differs, it's worth thinking about.
> 
> completion-at-point is the same as thing-at-point in this regard, currently.

(Of course it is.  All completion defaulting cares about is getting
something _near_ point, not determining _whether there is_ something
at point, and if there is, getting that.  It doesn't care to be precise
about what's _at_ point.  On the contrary; it wants to maximize getting
something near point.)

The _character_ "at" point (which is what this comes down to) is not
usually how we talk about this.  Point, like any other buffer position,
is always _between_ chars (or is at bob or eob).  We have functions
such as `char-after' and `char-before'.  So the more precise way of
talking about this is the character after (i.e., just after) point.

But the point (!) of the thing-at-point functions is to pick up a
thing that is really "at" some position.  And the point of the bug
report is that a position means a _single_ position.

In order to be precise, and thus to be generally usable, including in
a repetitive way, progressing through a buffer etc., the thing-at-point
functions need to refer to a single position - whether that be chosen
by convention to be the position just before the character in question
or the position just after it.

See the opening salvos of the bug report for a discussion of why
thing-at-point really means thing just after point.  I don't want
to repeat everything here (dunno why this was moved out of the bug
thread, either).

The point (!) of the bug report is that the thing-at-point feature
cannot reasonably mean just give me EITHER a thing before point OR
a thing after point (even if it gives you the first of those that
it finds).

That would be OK if all you expect of the functions is to grab
something _near_ point in the buffer, to use as a default value
(e.g. for completion or input).  It is not OK when it comes to
really making use of the functions in a precise way, and in
particular, a repetitive way, to progressively deal with things
through a buffer.

What's needed for a real thing-at-point is what the (simple) bug
fix provides: unambiguously provide the thing just after point -
only.  More generally, the functions need to return a thing at
some ONE position, however that position is decided on.  And they
need to return nil when there is no thing at that position.

On the other hand, what's needed (it would be an improvement) for
the more loose uses of thing-at-point, such as getting a default
value, is thing-NEAR-point functions.  And the bug report points
to exactly such (existing) functions, even with user or code
control over how near "near" is, horizontally and vertically.

That kind of function is appropriate in contexts where all you
care about is _getting something near point_, and you in fact
want to maximize the ability to getsomething and you don't need
to determine _whether or not_ there really is a thing at a given
position.

In sum, both are useful:

* Functions that deal with a thing AT a given position, precisely.
* Functions that deal with a thing NEAR a given position.

Both are addressed in the bug thread.  But the purpose of the bug
report is to get the former fixed so it DTRT: returns a thing at
the char just after point, or returns nil if there is none such.