Re: master d9b5f618baa 2/4: Eglot: introduce eglot-events-buffer-config

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 27 Dec 2023 17:38:13 +0000
> Cc: emacs-devel@gnu.org
> 
> On Wed, Dec 27, 2023 at 5:29 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > IOW Reconnecting to a server may trash useful caches, fail due
> > > to numerous reasons, etc...  We don't want to initiate it just
> > > because a user changed a preference.
> >
> > Shouldn't these caveats be in the doc string, where you tell users to
> > invoke eglot-reconnect?
> 
> No.  It's too server-specific, every server can behave differently.  It's
> assumed that if a user wants to reconnect and interactively chooses to do
> that, it's because they want to and understand what it does.  The model
> is the same as in SLIME and SLY, which also work with a multitude of CL
> implementations, and it has never proven problematic to my knowledge
> (at least in a over a decade of SLY maintenance).

Then we are inconsistent: either running eglot-reconnect is mostly
okay, in which case we should do it automatically when the option's
value changes, or it has issues, in which case we should at least hint
on those issues in the doc string, perhaps saying that with some
servers it's okay and with others less so.  The way the doc string is
worded now, users will invoke eglot-reconnect without being aware of
the possible issues which are the reason that you are reluctant to
invoke eglot-reconnect automatically.