bug#70929: 30.0.50; eglot--apply-text-edits prevents point adjustment

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

On Tue, May 14, 2024 at 1:44 PM Troy Brown <brownts@troybrown.dev> wrote:

> Possibly, although VSCode, which is probably considered the model LSP
> client implementation, allows this to happen.  Not saying it's
> necessarily correct in doing so, just another data point.

VSCode has its own mini-plugin for each language (sometimes not so
mini).  Akin to a major mode, but has somewhat less than 40 years
of work put into it.  In that aspect, it's not exactly a model of what
LSP purports to bring: a language-agnostic solutions.

So I don't model Eglot after VSCode, and have never done so. I model it after
LSP and my knowledge of Emacs.  That's not to say that I will ignore
if you show here whichever solution VSCode uses for this (if anything).

> > The workaround of enabling electric-indent-mode or just turning off
> > OnTypeFormatting
> > via eglot-ignored-server-capabilities is much better.
>
> I'm not sure a workaround of turning this off is desirable if you're
> trying to use it for indentation.  If the mode doesn't have internal
> indentation support, this will fallback to something like
> indent-relative which might get you in the ballpark but won't be as
> accurate as having the language server provide you with the correct
> indentation.

Sure, a workaround is not a solution, by definition.  But the way to
implement the solution in a LSP language-agnostic way -- which is what
eglot.el does -- is murky right now.

To gain confidence in any approach , I'd ideally first have to have
unit tests running on say, 5 servers that support OnTypeFormatting.  Code
up those tests in test/lisp/progmodes/eglot-tests.el.  Verify that the
"after the point indentation" indentation cases all fail currently for
those 5 servers and the "elsewhere changes" cases all pass.

Then, get to coding a solution.  For a successful solution all cases
should pass.

This is non-trivial work, so I'm not rushing to get started, especially
since the  electric-indent-mode workaround is pretty decent.  For some
meaning of "decent", at least :-) I find it relevant that so many users
(including me) who are using OnTypeFormatting and never noticed this
bug until today.

But if you're interested, you (or anyone) could help get it started
by surveying servers that support OnTypeFormatting, documenting how to
install these 5 servers conveniently in a GNU/LInux system (perhaps a
Docker image).  This would make headway with the essential tests.
You're even more welcome to write the tests yourself.


As to the solution, maybe it would end up being something that relies
on the status quo behaviour of the majority of servers like e.g.
knowing that the "before point" indentation edit is always the last one
(I'm just conjecturing here, no idea if don't know if this is the case).
I don't like this kind of solution.

Or maybe the solution is super-clean and is just about asking
`replace-buffer-contents` to use the equivalent of `insert-before-markers`
and proving it doesn't break anything anywhere else.

Or maybe we can scale this up to the LSP folks so they help us understand
exactly how this should work and maybe code it up in the standard, so servers
behave predictably.

João