GNU bug report logs - #71777
29.4; sexp-at-point in latex-mode when sexp contains ";"

Previous Next

Full log

View this message in rfc822 format

From: Gabriele Nicolardi <gabriele <at> medialab.sissa.it>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 71777 <at> debbugs.gnu.org
Subject: bug#71777: 29.4; sexp-at-point in latex-mode when sexp contains ";"
Date: Wed, 26 Jun 2024 21:43:34 +0200

From the previous responses, I have understood that the sexp-at-point 
function is not suitable for my purpose.
However, I suggest updating the documentation because the explanations 
you provided are not trivial, and the similarity in names with other 
functions (forward-sexp, etc.) creates misunderstandings.

Lastly, I would like to point out an issue on Stack Exchange:

https://emacs.stackexchange.com/q/81603/15606

where I asked for help with a function that fits my needs.

Thank you!

Gabriele

Il 26/06/24 15:46, Stefan Monnier ha scritto:
>>> $K(U_1, V_1, x_1; t_2, x_2)$
>>>
>>> If the pointer is located on the opened "(" and I run "forward-sexp" it
>>> works and the
>>> pointer goes after the closed ")".
>>>
>>> But if, again, the pointer is located on the opened "(" and I evaluate
>>> "(sexp-at-point)" it returns nil.
>>>
>>> If I remove the ";" symbol from the expression it works and returns the
>>> sexp-at-point:
>>>
>>> $K(U_1, V_1, x_1 t_2, x_2)$
>>>
>>> Is it a bug?
>> I don't think it's a bug.  forward-sexp moves across balanced
>> expressions, so it is not specific to Lisp.  By contrast,
>> sexp-at-point is specific to Lisp and Lisp-like syntax, and so it uses
>> the buffer's syntax.  Which is why ';' affects the result.
>>
>> Adding Stefan in case he has comments for this.
> AFAICT, `sexp-at-point` correctly finds the parenthesized thingy, but it
> is asked to return the Lisp object it represents rather than a string,
> so it `read`s, which inevitably obeys the ELisp syntax.
>
> IOW, I suspect you want (thing-at-point 'sexp) rather than
> (sexp-at-point).
>
>
>          Stefan
>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.