thing-at-point's meaning of current sexp vs. up-list's: which is correct?

thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Kelly Dean]

If point is on a closing delimiter, then thing-at-point says the delimiter is part of the current sexp, but up-list says the delimiter is part of the sexp that contains the current sexp.
The result is that kill-backward-up-list, which assumes that thing-at-point and up-list have the same meaning for current sexp, fails when point is on a closing delimiter: type "((a))" and put point on the first closing parenthesis, then do kill-backward-up-list, and it reinserts the same sexp that it kills, leaving the text unchanged.
I'll file a bug report, but should I file it for thing-at-point, or for up-list? Surely not for kill-backward-up-list.

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Kelly Dean]

Forgot to say, I meant in 24.3. In trunk, (thing-at-point 'sexp) returns nil, so kill-backward-up-list still doesn't work, but reports "Not at a sexp". I guess that answers the question: the bug is in thing-at-point.

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Davis Herring]

> If point is on a closing delimiter, then thing-at-point says the delimiter is part of the current sexp, but up-list says the delimiter is part of the sexp that contains the current sexp.

Point isn't on a character, but between them; the box cursor is drawn on
the character following point. Therefore when the cursor is on a ),
point is definitely inside the parentheses.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Kelly Dean]

Davis Herring wrote:
>Point isn't on a character, but between them; the box cursor is drawn on
>the character following point. Therefore when the cursor is on a ),
>point is definitely inside the parentheses.

I switched to Emacs almost six months ago; I'm surprised I missed something this basic until now.
The docstring for (point) says "Beginning of buffer is position (point-min)", so point is at, not between, "positions".
If there's one character in a buffer, then point can be at position 1 or 2. Which position is the character at? Or are characters not at positions, but _between_ positions? That seems weird. I always thought both point and characters were at positions.

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Stephen Berman]

On Wed, 12 Jun 2013 18:40:58 -0700 (PDT) Kelly Dean <kellydeanch@yahoo.com> wrote:

> Davis Herring wrote:
>>Point isn't on a character, but between them; the box cursor is drawn on
>>the character following point. Therefore when the cursor is on a ),
>>point is definitely inside the parentheses.
>
> I switched to Emacs almost six months ago; I'm surprised I missed something
> this basic until now.
> The docstring for (point) says "Beginning of buffer is position (point-min)",
> so point is at, not between, "positions".
> If there's one character in a buffer, then point can be at position 1 or
> 2. Which position is the character at? Or are characters not at positions, but
> _between_ positions? That seems weird. I always thought both point and
> characters were at positions.

See (elisp)Positions:

   A "position" is the index of a character in the text of a buffer.  More
   precisely, a position identifies the place between two characters (or
   before the first character, or after the last character), so we can
   speak of the character before or after a given position.  However, we
   often speak of the character "at" a position, meaning the character
   after that position.

Steve Berman

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Stefan Monnier]

> I'll file a bug report, but should I file it for thing-at-point, or for
> up-list? Surely not for kill-backward-up-list.

I think the bug is in kill-backward-up-list.  `up-list' is definitely
behaving correctly here, and thing-at-point is basically free to return
anything it feels like (it's a very ad-hoc function which tries to
DWIM).


        Stefan

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Kelly Dean]

Stefan Monnier wrote:
>I think the bug is in kill-backward-up-list.  `up-list' is definitely
>behaving correctly here, and thing-at-point is basically free to return
>anything it feels like (it's a very ad-hoc function which tries to
>DWIM).

forward-sexp and er/expand-region agree with up-list's meaning, and it does look like the right meaning. If thing-at-point is ad-hoc DWIM anyway, then I don't see the advantage of it using a different meaning than the standard for other functions. Wouldn't it be better to change thing-at-point? Besides this, in trunk, thing-at-point returns nil in the case I described, even though there certainly is a sexp at point, so that bug might as well be fixed in a way that makes thing-at-point compatible with the other functions.
And kill-backward-up-list's implementation is short and elegant; dealing with thing-at-point's different meaning would make it longer and ugly.

Re: thing-at-point's meaning of current sexp vs. up-list's: which is correct?

[Stefan Monnier]

> forward-sexp and er/expand-region agree with up-list's meaning, and it does
> look like the right meaning. If thing-at-point is ad-hoc DWIM anyway, then
> I don't see the advantage of it using a different meaning than the standard
> for other functions.

Because thing-at-point is dwimish: if you're right before a closing
paren (and hence you block cursor is drawn on top of the closing paren),
it's pretty clear that by "the sexp at point" you want to mean "the sexp
that ends with the paren after point".

> And kill-backward-up-list's implementation is short and elegant; dealing
> with thing-at-point's different meaning would make it longer and ugly.

DWIM basically means that it only makes sense for the user to call it,
but not for Elisp code, because the dwimness tries to guess what a user
would want, but what a piece of code would want is generally
very different.


        Stefan