From: Philip Kaludercic <philipk@posteo.net>
To: "João Távora" <joaotavora@gmail.com>
Cc: Yuan Fu <casouri@gmail.com>, 60338@debbugs.gnu.org
Subject: bug#60338: [PATCH] Add option to present server changes as diffs
Date: Fri, 30 Dec 2022 15:09:06 +0000 [thread overview]
Message-ID: <87k0297wtp.fsf@posteo.net> (raw)
In-Reply-To: <CALDnm52XtrvrJen5zPmz3E9g4Le4B-6+vf2okTZw-oohWeJ3rw@mail.gmail.com> ("João Távora"'s message of "Fri, 30 Dec 2022 13:13:05 +0000")
João Távora <joaotavora@gmail.com> writes:
> On Thu, Dec 29, 2022 at 2:39 PM Philip Kaludercic <philipk@posteo.net>
> wrote:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > The idea is good, but how does this play along with the existing
>> > eglot-confirm-server-initiated-edits?
>>
>> It takes precedence, since the diff is regarded as a kind of prompt. If
>> you want to, I can also update the patch to use that option instead of a
>> custom one (e.g. present a diff if
>> `eglot-confirm-server-initiated-edits' is set to `diff').
>
> This is an improvement, but it's not enough, unfortunately.
>
> The current semantics of eglot-confirm-server-initiated-edits must first be
> investigated, then potentially expanded/consolidated, even before the
> augmentation
> with the new 'diff value. Only then should 'diff be added. If we do this
> some other
> way, we only increase inconsistency and confusion.
>
> Here is some information to get started with the investigation.
>
> The function responsible for applying edits, eglot--apply-workspace-edit is
> called currently from 3 places:
>
> 1. eglot-rename (this ignores eglot-c-s-initiated-edits, but confirms with
> a prefix
> argument). The reasoning is that this is such a common action that by
> default
> we shouldn't bother the user with confirmation.
This is also one of the situations where I believe that a diff is not
necessary, since the change is predictable.
> 2. When the user chooses a code action from a list of code actions presented
> as a menu and that code action happens to contain an edit. This also
> ignores
> eglot-c-s-initiated-edits. The locus of the call is
> eglot--read-execute-code-action.
> The reasoning here is, I believe, that the user is already being presented
> with
> an interactive prompt, and presenting a second follow-up seemed too much.
>
> 3. When applying a code action that makes the server initiate a code
> action.
> The locus is eglot--handle-request (for workspace/applyEdit). Here
> eglot-confirm-server-initiated-edits is read honoured. The reasoning here
> is
> that the user might not be aware of the breadth of the code action that the
> server is about to propose.
>
> Note that the differences between 2 and 3 are subtle, and perhaps
> conceptually
> non-existent, but technically they do exist. In 2, the edit is immediately
> available whereas in 3, a further server trip is required to get the edit
> to apply.
I am afraid I can't conceptualise the difference between the two. The
2. is probably what I am familiar with, but when does the server
initiate a code action. Are we talking about an unprompted change? Or
something like code formatting?
> Moreover, the current method of "confirmation" is just a prompt that lists
> the
> files about to be changed. This is what should change, perhaps even by
> default, to a presentation of a diff in a separate buffer.
Would you say that this means we should always generate a diff and only
apply it when the user confirms the change, or is the cost of doubling
the communication acceptable?
> Currently, the confirmation happens also (regardless of the value of
> eglot-confirm-server-initiated-edits) if any of the files about to be
> changed
> is not yet visited in a buffer.
>
> So to summarize, I would like to hear proposals on how to make
> user confirmation of edits more consistent and predictable across the
> various use cases.
>
> Then, as I've already said, the "diff" method of confirmation sounds in
> principle very robust and in-line with Emacs' principles. It could
> eventually
> even be made the default.
So in the sense that a diff is presented as a kind of confirmation,
along with the option to apply all the changes immediately. All in
all, this makes me less certain that merging the change into
`eglot-confirm-server-initiated-edits' is the right approach.
> João
next prev parent reply other threads:[~2022-12-30 15:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-26 13:42 bug#60338: [PATCH] Add option to present server changes as diffs Philip Kaludercic
2022-12-29 0:01 ` Yuan Fu
2022-12-29 14:28 ` Philip Kaludercic
2022-12-29 14:36 ` João Távora
2022-12-29 14:39 ` Philip Kaludercic
2022-12-30 13:13 ` João Távora
2022-12-30 15:09 ` Philip Kaludercic [this message]
2023-01-04 20:56 ` Felician Nemeth
2023-06-09 7:55 ` Philip Kaludercic
2023-06-11 21:33 ` Philip Kaludercic
2023-06-12 11:56 ` Eli Zaretskii
2023-06-12 12:35 ` Philip Kaludercic
2023-06-12 12:52 ` Eli Zaretskii
2023-06-12 13:29 ` Philip Kaludercic
2023-06-12 13:41 ` Eli Zaretskii
2023-06-13 21:34 ` Philip Kaludercic
2023-06-14 6:00 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-14 11:27 ` Philip Kaludercic
2023-06-18 11:38 ` Philip Kaludercic
2023-06-18 15:18 ` João Távora
2023-06-18 22:37 ` João Távora
2023-06-24 16:53 ` Philip Kaludercic
2023-09-01 0:06 ` João Távora
2023-09-01 5:18 ` Philip Kaludercic
2023-09-01 21:12 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-01 21:19 ` João Távora
2023-09-01 22:01 ` João Távora
2023-09-02 6:13 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02 9:55 ` João Távora
2023-09-07 1:00 ` Dmitry Gutov
2023-09-07 6:28 ` Juri Linkov
2023-09-07 12:41 ` Dmitry Gutov
2023-09-07 12:45 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0297wtp.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=60338@debbugs.gnu.org \
--cc=casouri@gmail.com \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.