Re: tree-sitter: conceptional problem solvable at Emacs' level?

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On Sat, 2023-02-11 at 09:41 +0100, Theodor Thornhill wrote:
> 
> 
> On 11 February 2023 09:22:06 CET, Konstantin Kharlamov <hi-angel@yandex.ru>
> wrote:
> > On Sat, 2023-02-11 at 10:11 +0300, Konstantin Kharlamov wrote:
> > > On Sat, 2023-02-11 at 07:51 +0100, Theodor Thornhill wrote:
> > > > 
> > > > 
> > > > On 11 February 2023 07:36:26 CET, Konstantin Kharlamov
> > > > <hi-angel@yandex.ru>
> > > > wrote:
> > > > > On Sat, 2023-02-11 at 09:25 +0300, Konstantin Kharlamov wrote:
> > > > > > On Sat, 2023-02-11 at 10:17 +0800, Po Lu wrote:
> > > > > > > Eli Zaretskii <eliz@gnu.org> writes:
> > > > > > > 
> > > > > > > > However, I meant the IDEs which are using tree-sitter and
> > > > > > > > support
> > > > > > > > developing C/C++ programs.  I believe some do.
> > > > > > > 
> > > > > > > I think most of those have similar problems supporting macros.
> > > > > > > Who knows their names? I may be able to ask some of their users.
> > > > > > 
> > > > > > From my experience on and off work, there are just two IDEs (as in,
> > > > > > not
> > > > > > editors)
> > > > > > used most widely for C++ code: QtCreator and Visual Studio. The
> > > > > > first
> > > > > > you
> > > > > > discussed, the second is proprietary.
> > > > > > 
> > > > > > Then again, people most often code in C++ and C with text editors,
> > > > > > in
> > > > > > that
> > > > > > case
> > > > > > popular choices from my experience: Sublime Text and VS Code. These
> > > > > > two
> > > > > > have
> > > > > > don't use tree-sitter either.
> > > > > 
> > > > > I installed Sublime Text on my Archlinux and tested with the C++ code
> > > > > OP
> > > > > posted.
> > > > > 
> > > > > What I see is that ST does seem confused about indentation, while
> > > > > trying
> > > > > to
> > > > > make
> > > > > a newline right after `slots:` line.
> > > > > 
> > > > > However, if you try to make a newline after the `void someSlot() {};`
> > > > > line,
> > > > > it
> > > > > will use the indentation used on the previous line.
> > > > > 
> > > > > The default cc-mode in Emacs works similarly. The cc-ts-mode on the
> > > > > other
> > > > > hand
> > > > > doesn't make use of the previous indentation, and I think it should.
> > > > > It
> > > > > would
> > > > > resolve that problem and others, because in my experience it happens
> > > > > very
> > > > > often
> > > > > in C and C++ code that you want some custom indentation level, so you
> > > > > just
> > > > > make
> > > > > one and you expect the editor to keep it while creating more new
> > > > > lines.
> > > > > 
> > > > 
> > > > That last statement sounds easily solvable. Can you send me a short
> > > > example
> > > > describing exactly what you want in a code snippet and I'll add it.
> > > > 
> > > > Thanks,
> > > > Theo
> > > 
> > > Thank you! The example is below, but please wait a bit just to make sure
> > > there's no opposition from other people, because I don't know if it works
> > > like
> > > this on purpose, or not.
> > > 
> > > Given this C++ code with weird class members indentation:
> > > 
> > >     class Foo {
> > >            int a;
> > >            bool b;
> > >     };
> > > 
> > > Now, suppose you put a caret after `bool b;` text and press Enter to make
> > > a
> > > new
> > > line (all tests are done with `emacs -Q`). The behaviour:
> > > 
> > > * cc-mode and Sublime Text: creates a newline with the indentation exactly
> > > as
> > > on
> > > the previous one.
> > > * cc-ts-mode: re-indents the `bool b;` line, then creates a new one with a
> > > custom indentation that is different from one on the `int a;` line.
> > > 
> > > The cc-mode and Sublime Text behaviour seems like less annoying to me,
> > > because
> > > if I wanted to reindent the prev. line, most likely I'd did it by pressing
> > > an
> > > indentation hotkey (e.g. `=` in Evil mode I use).
> > 
> > Oh, wait, though I mistakengly used c-mode instead of c++-mode. The c-mode
> > works this way, it keeps prev. indentation, however c++-mode instead uses a
> > new indentation. It's odd they behave differently, and it certainly is
> > different from other modes (e.g. emacs-lisp-mode). In this case I think the
> > question of whether it should re-use prev. line indentation, which I think
> > the should.
> 
> C-mode or c-ts-mode?
> 
> Yeah, this is what I'm thinking too. I'll look at it tonight or tomorrow :)

c-ts-mode works the same way as c++-ts-mode does.

Upon further inspection I realised that the vanilla c-mode keeps previous
indentation in aforementioned case just because it doesn't recognise `class`
keyword. But if you replace it with `struct`, it will make use of whatever
indentation it thinks is correct instead of one from previous line.

However, actually, the vanilla c-mode and c++-mode behave inconsistently.
Depending on the code they may or may not make use of previous indentation. So
anyway, I re-created an example where indentation is being kept in ST, c-mode,
c++-mode, but not in c-ts-mode or c++-ts-mode, below. I also threw in other
editors for comparison.

Given this code:

    int main() {
        foobar(
             arg1,
             arg2
             );
    }

Suppose you put a caret after `arg2` text and press Enter to make a new line
(all tests are done with `emacs -Q`). The behaviour:

* c-mode, c++-mode, Sublime Text (both with `.c` and `.cpp` file), VS Code (both
with `.c` and `.cpp` file): creates a new line indented same way as previous
one.
* c-ts-mode, c++-ts-mode: re-indents the `arg2` line to have indentation
different from `arg1,` line, and creates a new line that also has new
indentation.
* QtCreator: lol, it does no indentation whatsoever in this case.

Overall, it seems like "using the previous indentation" is the way to go, it
also is used in VS Code and Sublime Text.

As a side note, if a user explicitly wants to re-indent the code, behaviour
should depend on how much text they selected for re-indentation (at least c-mode
and c++-mode behave this way) which is intuitive. For example: if I only select
arg2 line, then re-indentation uses previous offsets, so basically nothing
happens. However if I select arg1 and arg2 lines, then indentation would be
different because the previous line has a different syntax construction of
"opening parenthesis", so the default indentation for that case is used, which
is "indent arguments to the opening parenthesis of the function".