From: Felician Nemeth <felician.nemeth@gmail.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: "Philip K." <philipk@posteo.net>,
martin rudalics <rudalics@gmx.at>, Eli Zaretskii <eliz@gnu.org>,
Alan Donovan <adonovan@google.com>,
70193@debbugs.gnu.org
Subject: bug#70193: [PATCH] Re: bug#70193: Acknowledgement (eglot: RFE: recenter buffer upon showDocument request)
Date: Tue, 23 Apr 2024 09:43:47 +0200 [thread overview]
Message-ID: <877cgobk24.fsf@betli.tmit.bme.hu> (raw)
In-Reply-To: <CALDnm53m-Wf_wQTDYF00zRiM27yqmfQR7TNeLcQpSnwPxPF89A@mail.gmail.com> ("João Távora"'s message of "Wed, 17 Apr 2024 13:13:10 +0100")
João Távora <joaotavora@gmail.com> writes:
> I'm sure the patch is correct but 50+ lines of window-management code
> in eglot.el?
I agree it can go elsewhere.
> Just for that one user?
I don't think that should matter.
> There's nothing LSP-specific in the new function
> `eglot--window-recenter-region`, it's pure window management code.
>
> The derived-mode-p specifically bit also looks very much out
> of place in Eglot. What is it accomplishing, and why is this
> prog-mode exception not in the preceding function itself
> (maybe as an optional toggle)
reposition-window relies on `beginning-of-defun' and `end-of-defun', but
it is potentially better than window-recenter-region, because if the
selection of showDocument is inside a function, then it tries to show
the preceding comments as well.
> In fact, there's nothing intrinsically LSP-specific about having
> clients request Emacs shows the user a given part of a file.
> I can't believe this obscure LSP interface is its only client.
> Is it really?
Maybe textDocument/publishDiagnostics is somewhat similar. Flymake
shows the region of the diagnostic messages with as little care as Eglot
currently shows the selection of showDocument.
> So, if this new impeccably documented function designed by Emacs's
> window management expert :-) does what it says, I think we should
> put it somewhere else.
I agree.
> Practical matters: there's the usual problem with Eglot
> compatibility with older Emacsen, but there's:
>
> * compat.el (I think Phil has already made Eglot use compat.el recently)
> * there's the strategy of using (or creating) another GNU ELPA :core package
> (like external-completion.el and many other ones)
> * there' the strategy of 'fboundp' where this nice-to-have "excellent
> recentering" feature would only appear to Eglot users running it on
> a recent Emacs.
I think the third option is good enough in this case.
The current patch can be regarded as a prof-of-concept implementation if
anyone is interested in continuing to work on this.
next prev parent reply other threads:[~2024-04-23 7:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 13:17 bug#70193: eglot: RFE: recenter buffer upon showDocument request Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <handler.70193.B.171223666917509.ack@debbugs.gnu.org>
2024-04-04 13:32 ` bug#70193: Acknowledgement (eglot: RFE: recenter buffer upon showDocument request) Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 14:43 ` Felician Nemeth
2024-04-05 9:07 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 13:53 ` Felician Nemeth
2024-04-07 7:30 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-13 8:08 ` Eli Zaretskii
2024-04-13 9:10 ` Felician Nemeth
2024-04-13 16:36 ` Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-17 9:15 ` bug#70193: [PATCH] " Felician Nemeth
2024-04-17 12:13 ` João Távora
2024-04-23 7:43 ` Felician Nemeth [this message]
2024-04-23 9:27 ` João Távora
2024-04-24 16:37 ` Juri Linkov
2024-04-24 20:14 ` João Távora
2024-04-27 10:25 ` Philip Kaludercic
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=877cgobk24.fsf@betli.tmit.bme.hu \
--to=felician.nemeth@gmail.com \
--cc=70193@debbugs.gnu.org \
--cc=adonovan@google.com \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
--cc=philipk@posteo.net \
--cc=rudalics@gmx.at \
/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.