From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: master d9b5f618baa 2/4: Eglot: introduce eglot-events-buffer-config Date: Wed, 27 Dec 2023 19:05:10 +0000 Message-ID: References: <83le9f8ufh.fsf@gnu.org> <83il4j8sgf.fsf@gnu.org> <83frzn8omt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35092"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 27 20:06:19 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rIZEQ-0008sY-Kd for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Dec 2023 20:06:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rIZDc-0002Hj-Ll; Wed, 27 Dec 2023 14:05:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rIZDb-0002HR-EZ for emacs-devel@gnu.org; Wed, 27 Dec 2023 14:05:27 -0500 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rIZDZ-0005gs-Pw; Wed, 27 Dec 2023 14:05:27 -0500 Original-Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ccad57dadbso39626681fa.1; Wed, 27 Dec 2023 11:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703703923; x=1704308723; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+JU75jHJdtBc00N/qb9PLKZj10TKTIgn9yGzeJvzLvk=; b=hLOJ64W0RevwqdbZL5/vM/5IhYagIZFnxPacNKNAFdiuXnm604JLO291UbVe54PIQB H3Cngqx/vVTiOBzBYneq2UInMX86pdmViMZxwAkR91n48zDfbukqClEbjw8C8Kdm/Foy XT9Pv6nGlv8Fdl/9FDHyB1OGarQaNxwyMKguABgAld1RzyBYLwTPJ/VKqT0Yi6yoeoaT oNgAUwm5+a4tmsrpxj/sC1/49PN+W2bnBLPmSZbJMyqo8D0geWkHx2+IA+yTKozMJV6k k4EycjN7AyAXsTHhhkOIJI8LOYg1su6ZgygKMBHFulU1N/bjaHO9MZUsNzoi27NqKY9T 1qyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703703923; x=1704308723; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+JU75jHJdtBc00N/qb9PLKZj10TKTIgn9yGzeJvzLvk=; b=GXP4JRd2tGWYP5Vqg9qYy9fzlDYFW2evmHCFPNLxlt63jyxlfxgjOWJ0nVxoTswgcc IYds7utHXS1luscYAhByghKj1S4bCTEiHXTTZVymEGr6Ibhth2j1UeIOGGDsgK//zwgv 08iJP2mYSPpxPfsBegFpfASTRX8r1QIpfSQltaQiEJIcgp+hFSeOCSALB230LsPpdqaa 6dvlpTdcQp2RRK2gxxIceuq5K2JeDIJTia8ANa48zCI/h/6e/kEFxo2sZjgdOrvW64+0 L6AZATPEgXsPxsw4ZZjpaRdSx8nZlRhKIO4iIJbzBu5qqbtBk02nrHKTmgIZ2j+v1CXu yrEA== X-Gm-Message-State: AOJu0Yx0piWyAbvxxgQPc9GeZ2SJeUXk0bi1E+zjvRGcJdnBLuzgXoaX 6QK4HtxAX0skLwlDVVgn/V2ToJFInQkKo4msXbS5DauU0iw= X-Google-Smtp-Source: AGHT+IEt8mIAc7XAFP7AeMOydZiauPVaZYfP7x5DRKWvkBviTziq3bUHtkMsg1wgL3ihAr7qHiDyChQ9iY/oQVWEVHo= X-Received: by 2002:a2e:be0f:0:b0:2cc:7546:368e with SMTP id z15-20020a2ebe0f000000b002cc7546368emr3755141ljq.99.1703703922414; Wed, 27 Dec 2023 11:05:22 -0800 (PST) In-Reply-To: <83frzn8omt.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x22c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314258 Archived-At: On Wed, Dec 27, 2023 at 6:52=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Wed, 27 Dec 2023 17:38:13 +0000 > > Cc: emacs-devel@gnu.org > > > > On Wed, Dec 27, 2023 at 5:29=E2=80=AFPM Eli Zaretskii wr= ote: > > > > > > 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. No. What a connection entails is explained in more than sufficient detail already. Stuff like this, which requires network resources, reads config files, runs user hooks etc is just not good to invoke non-interactively is all. Not to mention a user may have multiple connections ongoing for multiple connections, some quick to connect, some slow, some sync, some async (see doc of eglot-connect-timeout). I just don't think the problem exists. Moreover the number one reason for garden-variety users to want to customize that otherwise obscure variable is now likely gone, since the default value leads to much faster performance. Jo=C3=A3o