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

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

On 07.07.2016 01:31, Drew Adams wrote:
>>> 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.

+1

(defun foo())(defun bar())

(length "(defun foo())") => 13

The opening paren of "bar" is at pos 14.
I.e. at-point 14 belongs the definition of bar.

However, when copying "foo", it needs
(buffer-substring-no-properties 1 14) => "(defun foo())"

Think of at-point as of visibility of cursor in buffer.