Re: 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]

[Theodor Thornhill <theo@thornhill.no>]

João Távora <joaotavora@gmail.com> writes:

> 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

(I haven't read that bugreport yet, sorry if this has already been discussed)

This is interesting! But for the time being many lsp-servers vary a lot
in their ability to do this properly. Gopls, for example, seems to
handle this very well, in that already has a very heavily enforced
indentation style. Same goes for rust. Java, however, is a different
beast. Intellij has its own indentation implementation that isn't
lsp-available. Eclipse is lsp-available, but was for me almost
impossible to configure in the initializationOptions, as it required
sourcing a file with xml-settings etc. Getting jdtls to format things
like Intellij, which coworkers use, is hard. Similarly, for javascript,
where other tools, like prettier, is used to do this. Sometimes they
allow for a plugin to the lsp-server, sometimes it has to be executed
separately. My point is that getting indentation correct often relies on
factors outside of lsp, or emacs even, making it hard to
configure. VSCode offers a settings-ui for much of this, which writes to
its own settings.json (or something like that). I'm not sure how such a
configuration would look for emacs, but I'm sure it's possible.

Theo