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

Previous Next

Full log

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

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

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

Previous Next

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