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

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

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Hi John,

suggesting a poll WRT this question.  While siding with Drew, there might also be reasons for the opposite.

Cheers,

Andreas


-------- Forwarded Message --------
Subject: 	Re: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not 
return nil when just after THING
Date: 	Tue, 21 Jun 2016 15:50:11 +0300
From: 	Eli Zaretskii <eliz@gnu.org>
Reply-To: 	Eli Zaretskii <eliz@gnu.org>
To: 	Andreas Röhler <andreas.roehler@easy-emacs.de>
CC: 	9300@debbugs.gnu.org



> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> Date: Tue, 21 Jun 2016 08:14:22 +0200
>
> On 20.06.2016 22:04, Eli Zaretskii wrote:
> >> Date: Mon, 20 Jun 2016 10:50:27 -0700 (PDT)
> >> From: Drew Adams <drew.adams@oracle.com>
> >> Cc: f92capac@gmail.com, 9300@debbugs.gnu.org, dgutov@yandex.ru
> >>
> >>> FWIW, I agree with Dmitry: this has been a de-facto behavior long
> >>> enough to consider it the correct one. If documentation is confusing
> >>> in that it says otherwise, we should fix the documentation.
> >> I couldn't disagree more.
> >>
> >> It is wrong to consider the current behavior "the correct one",
> >> regardless of how long it has been in place.  It is wrong because
> >> you cannot use it in a general and precise way.  It is just broken.
> >> It has been broken for a long time, but it is broken nevertheless.
> > That's immaterial.  It is being used in many places, and it's
> > obviously useful.
>
> It is useful, but not in the way of the lemma "at-point". At-point means
> at cursor-position.

Yes, the de-facto behavior is actually "at or around point".


[-- Attachment #2: Type: text/html, Size: 3938 bytes --]

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

[John Wiegley]

>>>>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> suggesting a poll WRT this question. While siding with Drew, there might also
> be reasons for the opposite.

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.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Dmitry Gutov]

On 07/07/2016 12:21 AM, John Wiegley 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.

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.

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

[Andreas Röhler]

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.