unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Troy Brown <brownts@troybrown.dev>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 70929@debbugs.gnu.org
Subject: bug#70929: 30.0.50; eglot--apply-text-edits prevents point adjustment
Date: Tue, 14 May 2024 08:43:59 -0400	[thread overview]
Message-ID: <CABvCZ41QOykU1gKDqt0YqeW5hcaYdVES78yA7+P8uPP4wtRhNA@mail.gmail.com> (raw)
In-Reply-To: <CALDnm50BJyJb24D494+NGC7+=JNd05_m1N_UQKrA5aRF+pWGvQ@mail.gmail.com>

On Tue, May 14, 2024 at 5:28 AM João Távora <joaotavora@gmail.com> wrote:
>
> I've reproduced this on the clangd server and c++-ts-mode, but only after
> turning _off_ electric indent-mode, which hides this effect.

Yes, that's correct, electric-indent-mode can hide this.

> > eglot--apply-text-edits, it uses save-excursion, and this prevents the
> > point from being pushed to the end of the inserted spacing.  It would
> > seem that save-excursion should be avoided when applying text edits.
>
> Doing that naively would lead to chaos.  Edits can be supplied to arbitrary
> places in the buffer.  Edits can happen in many situations, even when inserting
> completions, for example.  If you circumscribe yourself to OnTypeFormatting,
> even Clangd for example performs edits before the full expression that precedes
> the newline.  There not even anything forcing the server to provide
> whitespace-only changes.
>

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.

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

I'll bring this to the attention of the Ada Language Server developers.





  reply	other threads:[~2024-05-14 12:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-14  2:15 bug#70929: 30.0.50; eglot--apply-text-edits prevents point adjustment Troy Brown
2024-05-14  5:30 ` Felician Nemeth
2024-05-14 12:38   ` Troy Brown
2024-05-14  6:23 ` Eli Zaretskii
2024-05-14  9:28   ` João Távora
2024-05-14 12:43     ` Troy Brown [this message]
2024-05-14 14:16       ` João Távora
2024-05-15 12:58         ` Troy Brown
2024-05-15 15:10           ` João Távora
2024-05-21  3:35         ` Troy Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABvCZ41QOykU1gKDqt0YqeW5hcaYdVES78yA7+P8uPP4wtRhNA@mail.gmail.com \
    --to=brownts@troybrown.dev \
    --cc=70929@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).