unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

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