bug#64784: LSP vs Emacs indentation [Was: bug#64784: 30.0.50; Eglot: Lisp error: (wrong-type-argument number-or-marker-p return) in eglot--post-self-insert-hook]

["João Távora" <joaotavora@gmail.com>]

Tassilo Horn <tsdh@gnu.org> writes:

>> Tassilo, can you test?
> I can say at least that the error is gone.  Thank you!

In that case, I'm closing, but we should keep chatting because this
matter interests me as well.  In fact, let's move this to Emacs-devel.

> So is there a way to stop the indentation wars [between LSP and Emacs's]?

There's quite a bit of overlap in indentation functionality, yes.  For
example, in non-ts c++-mode, there are a lot of indentation knobs, and
they can probably do all this.  But configuring them is difficult (for
me), and I'm not sure I haven't seen at a bug or two.  In practice, I've
accepted I'll never get them to match my team's .clang-format
completely.

A way to "stop" the war is to get one of the sides to surrender.  To
make the LSP side lose, just add symbols to
'eglot-ignored-server-capabilities', like
':documentOnTypeFormattingProvider'.

> Maybe if I could make it so that return and tab would also be
> considered as trigger characters for eglot-format?

If your aim is to make the LSP side "win", I don't think you should use
the "trigger character" technique specifically.  But in Emacs you can of
course bind keys to commands that invoke 'eglot-format' synchronously.

Even better, I think the most correct way is to buffer-locally set
'indent-line-function' and 'indent-region-function', so you can keep the
familiar feeling of TAB.

I've tested this:

* Setting 'indent-region-function' simply to 'eglot-format' apparently
  works.  (Not in cc-mode, which has a tendency for wheel-reinvention.
  Or who knows original invention...  but in any case it's probably time
  for me to move on to c++-ts-mode)

* As to 'indent-line-function', there's no Eglot command that's exactly
  compatible with the protocol, but it's pretty easy to make one:

    (defun eglot-indent-line ()
      (eglot-format (line-beginning-position) (line-end-position)))

After setting 'indent-line-function' and 'indent-region-function' like
this, things seem to work well at first.  But simple things like RET
('newline') fail.  I haven't investigated.  Maybe it's becasue of
electric-indent-mode?  Or maybe just because of the fact that
`eglot-format` asks the language server to do more than just indenting,
namely it also inserts newlines.  Or maybe I'm just not passing in the
correct range.

And then there are the annoying messages in the echo area about edits
successfully applied, but that's easily solved.

I hope you (and/or others) can give this approach (or variations
thereof) some testing.  Maybe with other LSP servers and/or style files.

The reason I find this interesting it that it would IMO not only solve
the indentation wars, it solves fundamental problems of limited-context
indenters such as c++-ts-mode.  Consider the C/C++ textual preprocessor
macros: probably no tree-sitter mode can know exactly what they mean and
how to indent the surrounding code, but a sufficiently smart
project-knowing LSP can.

Are there drawbacks to this "LSP-wins" approach to indentation?
Probably.  Chief among them LSP is very slow when compared things in the
same address space, like an Elisp function or a dynamically linked C
library.

My early impression is that this fact almost certainly matters for
LSP-driven fontification, but not for indentation.

In summary, if we can get a successful approach that feels right for
Emacs users (mostly regarding TAB, newline and region-indenting), maybe
we can enshrine LSP-powered indentation in Eglot-managed buffers just
like we do for Xref, Flymake, Imenu, etc...

João