[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when j

From: Dmitry Gutov
Subject: bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING
Date: Wed, 24 Feb 2016 02:52:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 02/23/2016 06:15 PM, Drew Adams wrote:

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.

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.

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.

The purpose of
thingatpt.el is not only to maximize finding a THING that is
_near_ point.  One purpose is to test whether there IS a THING
AT point.

We're a long way from maximizing it. To see something closer to the other end of the spectrum, see the definition of find-tag-default-bounds before http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=e72a26e00981a508569a0856125061310a3f64ac.

I see (in emacs-devel) that you are now looking into
picking up a name near point - but you are limiting that to the
same line.

Not at all, see above.

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. 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.

If we didn't need to be able to find a thing that ends just before point, 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.

reply via email to

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