GNU bug report logs - #72525
31.0.50; Forward sexp inconsistency issue c++-ts-mode

Previous Next

Full log

Message #11 received at 72525 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ergus <spacibba <at> aol.com>, 72525 <at> debbugs.gnu.org
Subject: Re: bug#72525: 31.0.50; Forward sexp inconsistency issue c++-ts-mode
Date: Sat, 10 Aug 2024 22:10:01 -0700

> On Aug 10, 2024, at 12:56 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Date: Thu, 08 Aug 2024 16:45:42 +0200
>> From:  Ergus via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> Hi:
>> 
>> Using this code:
>> 
>> ```
>> int main()
>> {
>>  abort(); /* 1 */
>>  abort(); /* 1 */
>> }
>> ```
>> 
>> There is an inconsistency in the c++-ts-mode behavior of `forward-sexp`.
>> 
>> When there is a comment at the end of the line, if I do `mark-sexp`
>> (C-M-SPC) consecutively I get this selected regions:
>> 
>> -----------------------------
>> 1.
>> abort();
>> 
>> 2.
>> abort(); /* 1 */
>> 
>> 3.
>> abort(); /* 1 */
>> abort
>> 
>> 4.
>> abort(); /* 1 */
>> abort()
>> 
>> 5.
>> abort(); /* 1 */
>> abort();
>> 
>> 6.
>> abort(); /* 1 */
>> abort(); /* 1 */
>> 
>> -------------------------------
>> 
>> 
>> 
>> But when there is NOT trailing comment
>> 
>> ```
>> int main()
>> {
>>  abort();
>>  abort();
>> }
>> ```
>> 
>> -------------------------------
>> 1.
>> abort();
>> 
>> 2.
>> abort();
>> abort();
>> -------------------------------
>> 
>> 
>> It looks like in the fist example after 3 the sexp definition is more fine
>> grained (similar to the previous c++-mode behavior) and it selects
>> separately:
>> the function name,
>> the arguments
>> the semicolon
>> the comment
>> 
>> But if there is no comment at the end, it always considers the complete
>> line as a sexp (including the ;).
>> 
>> For my use case I would prefer the old behavior because it is consistent
>> with the current sexp definition in all emacs (with maybe the exception
>> of python-mode).  Because it is easier to copy function names or
>> function calls with a few movements.
>> 
>> However, if it is too difficult to reproduce the old behavior; then the
>> new one may be implemented consistently.
> 
> Yuan, any comments or suggestions?
> 
> FWIW, I'm not sure this is a bug: what constitutes a "sexp" in C++
> source code is not well-defined.

Yeah I’ll look into this. And yeah there were some discussion around how should we define sexp in c++-ts-mode but there wasn’t a concrete conclusion (I don’t think it’s possible to come up with a concrete one anyway.) Still, if it can be made more convenient for common use-cases I’m more than happy to improve it. Just be aware that I’ll be super busy next week (and I still haven’t done the parse string feature) so it might take me a while to get back.

Yuan

Previous Next

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