all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>, 9300@debbugs.gnu.org
Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING
Date: Tue, 23 Feb 2016 17:31:02 -0800 (PST)	[thread overview]
Message-ID: <6635cd58-2d42-46fe-85b4-287f1e0eb05d@default> (raw)
In-Reply-To: <27990eb0-3d4e-62c7-257d-7ea7a8204e2d@yandex.ru>

> > Yes, it should return nil, as there is NO symbol at point.
> 
> If we ask the users, I'm guessing we'll get mixed answers on that, at
> least as a result of this long-standing thing-at-point behavior.

You might get opinions, but the fact is that there is no thing at
point in that case.

"At point" can only mean, since point is between characters, either
before point or after point.  It cannot mean both.  Not and keep
a possibility of recursive/iterative use.  Moving forward over a
thing puts point after the thing.  It does not keep point on/at
the thing.

The design must pick one or the other meaning of "at": a character
that belongs to the THING at point is either after or before point.
It cannot reasonably be both.

IMO, and all of the code confirms this (apart from this bug): "at"
in "thing at point" means after point, not before point.

> > It is your expectation that is wrong.  There are plenty of uses
> > of thing-at-point that go far beyond just looking for a default
> > value of a name near point or trying to complete a name before
> > (not at) point.
> 
> What I'm saying is, "fixing" it will most likely break code in the wild.
> Not just mine.

The fix to your code and theirs is trivial.

Bit if you must, rename the current, bugged implementation of
`bounds-of-thing-at-point' to `bounds-of-thing-at-or-after-point'.
Tell such folks to use that.  Likewise, add `thing-at-or-after-point',
if necessary, for any code that current depends on the broken
`thing-at-point'.

If you must, do that plus deprecate the (perfectly good, but not
for this broken code) name `bounds-of-thing-at-point', so any such
3rd-party code makes the change.

And add a function `bounds-of-thing-at-point-strict' that does
what `bounds-of-thing-at-point' should do (= the bug fix).  Change
the Emacs code that uses the broken `bounds-of-thing-at-point' to
use `bounds-of-thing-at-point-strict'.

IOW, wean any code from the broken implementation and use the
fixed implementation.

This is if you are convinced that there are zillions of uses of
the bugged `bounds-of-thing-at-point' that depend on the bugged
behavior.  I'm not convinced of that.

I'd say bite the bullet: fix the bug properly, and when anyone
complains tell them to use `bounds-of-thing-at-or-after-point'
if they really want the bugged behavior.  Better: tell them
to use the fixed `bounds-of-thing-at-point' after backing up
so point is actually on the THING instead of after it.

> > Those other uses include the need to test whether or not there
> > IS a given THING at point.  The design itself depends on this
> > difference: Is there a THING at point or not?
> 
> They can call (bounds-of-thing-at-point 'foo), and then compare
> the cdr with the value of point.

You are missing the point.  I won't repeat myself.  See what
I wrote about use cases.  See the code I referenced, if needed.

> >>> This is the design of the thingatpt code, and the reason why
> >>> `<=' instead of `<' is a bug:
> >>>
> >>>    the function that is (get THING 'end-op) moves PAST the THING,
> >>>    so that point is not on the THING.  This is true generally, no
> >>>    matter the type of THING.
> >>
> >> That's not a quote from thingatpt.el.
> >
> > It is nevertheless the design (intention), clear from the code.
> 
> I'm not so clear on that.

That much is clear.

> The following comment tells me the opposite
> (the position where a substring ends is normally the one _after_ its
> last character):
> 
>      ;; Try a second time, moving backward first and then forward,
>      ;; so that we can find a thing that ends at ORIG.

ORIG is the original position.  A thing that ends at that position
is at point.  A thing that ends before that position is not a thing
at point.

Look at `goto-char' or any other char-counting functions.  If you
move point "to" character 2, point = 2.  The char "at" point is the
char after point - point is before the char that has the same number
as point.  When point = 2 the cursor position (aka point) is between
chars 1 and 2, and we say point is "at" (or "looking at") char 2.

> If we didn't need to be able to find a thing that ends just before
> point,

Before is not at (= after).  Ends at ORIG does not mean ends before
ORIG.

> I don't think the implementation would need the "Try a second
> time" branch at all: when point if before the last character of a
> symbol, (forward-symbol) still works.

Believe me, I've walked through that particular code a hundred
times, in the debugger and without.  The code you are referring
to is needed, and it is not about finding a thing that ends before
point.

But I think you either try to see or you don't.  I cannot make
you see.





  reply	other threads:[~2016-02-24  1:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<B1052724B2D446C59E233FC1BD437723@us.oracle.com>
2015-07-29  1:44 ` bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING Drew Adams
2016-01-15 13:33   ` Drew Adams
2016-02-23  1:01     ` Dmitry Gutov
2016-02-23  6:37       ` Drew Adams
2016-02-23  7:59         ` Andreas Röhler
2016-02-23 10:22         ` Dmitry Gutov
2016-02-23 16:15           ` Drew Adams
2016-02-24  0:52             ` Dmitry Gutov
2016-02-24  1:31               ` Drew Adams [this message]
2016-02-26  1:03                 ` Dmitry Gutov
2016-02-26  1:44                   ` Drew Adams
2016-02-26 10:15                     ` Dmitry Gutov
2016-02-26 14:39                       ` Drew Adams
2016-02-26 15:25                         ` Dmitry Gutov
2016-02-26 17:00                           ` Drew Adams
2022-04-28 11:24       ` Lars Ingebrigtsen
2022-04-28 15:49         ` Drew Adams
2011-08-14 22:36 Drew Adams
2016-06-20  9:21 ` Tino Calancha
2016-06-20 12:53   ` Dmitry Gutov
2016-06-20 13:11     ` Tino Calancha
2016-06-20 14:48   ` Eli Zaretskii
2016-06-21  3:01     ` Tino Calancha
     [not found]   ` <<8337o79arh.fsf@gnu.org>
2016-06-20 17:50     ` Drew Adams
2016-06-20 18:38       ` Andreas Röhler
2016-06-20 20:04       ` Eli Zaretskii
2016-06-21  6:14         ` Andreas Röhler
2016-06-21 12:50           ` Eli Zaretskii
2016-06-21 13:07             ` Andreas Röhler
2016-06-21 15:13               ` Eli Zaretskii
2016-06-21 13:31             ` Drew Adams
2016-06-21 15:16               ` Eli Zaretskii
2016-06-22  5:23             ` Fwd: " Andreas Röhler
2016-07-06 21:21               ` John Wiegley
2016-07-06 21:51                 ` Dmitry Gutov
2016-07-06 23:31                   ` Drew Adams
2016-07-07  8:00                     ` Andreas Röhler
2016-06-21 13:25           ` Drew Adams
     [not found]   ` <<<8337o79arh.fsf@gnu.org>
     [not found]     ` <<0e2c9c67-12a2-4712-92d2-e3c204f46838@default>
     [not found]       ` <<83twgn7hjx.fsf@gnu.org>
2016-06-20 23:34         ` Drew Adams
2016-06-20 23:59           ` Noam Postavsky
2016-06-21  0:47             ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6635cd58-2d42-46fe-85b4-287f1e0eb05d@default \
    --to=drew.adams@oracle.com \
    --cc=9300@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.