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: Explain a bit more on how to configure language server in Eglot's manual Date: Thu, 9 Mar 2023 09:43:05 +0000 Message-ID: References: <86sfeisu49.fsf@stephe-leake.org> <87356gvkkb.fsf@gmail.com> <87r0tz8jag.fsf_-_@gmail.com> <87lek78eyq.fsf@gmail.com> <87ttyv2cug.fsf@gmail.com> 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="14913"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Stephen Leake , Emacs developers To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 09 10:44:01 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 1paCoa-0003ct-5Q for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 10:44:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paCo0-0003cl-EY; Thu, 09 Mar 2023 04:43:24 -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 1paCnv-0003cR-Sn for emacs-devel@gnu.org; Thu, 09 Mar 2023 04:43:19 -0500 Original-Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paCnu-0000Rl-4c for emacs-devel@gnu.org; Thu, 09 Mar 2023 04:43:19 -0500 Original-Received: by mail-ot1-x32a.google.com with SMTP id g6-20020a056830308600b0068d4b30536aso688550ots.9 for ; Thu, 09 Mar 2023 01:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678354997; 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=n7+PhuutxdfNPuA8gSJvKh6U/+KqdQ4ENAN7L08Js60=; b=ZcgtvmHFMpCxUu/N2IHrfymeDviPZ8iaCgffhVoWPVte7Eat2PHOxQkZuzWo6SL4zh sdgmWL9BhWrHxGymzPjEan63q0yaZ6rPxH6+petybEQNKgm19HHt7UWbFsHVduZGji/b GFJvojOAtE9NC1C/SyvJyl96iZ07qSWY1sO+ZryRcp2U/HBhYiHCF9jx/hvLzDCEzF2C GxWmoEMruyDKgbCi3gBg5gppF+6mtfFhkIu8Av+vmSU6vpUNJifWQ+wEuLO21fjYqDSA p6rxNLweR5jU6x9U9oqW7ecEonBdy/kBS13BnKVJZhUAamEC67zKC9mkIPLFUCyrl442 4VPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678354997; 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=n7+PhuutxdfNPuA8gSJvKh6U/+KqdQ4ENAN7L08Js60=; b=boTyMeeWqp6l1n4q5cmQQDq0LpJ/LnmCZLF4BUqv0X7DMqU72Kn+PgM9DNFmUDe4PJ pcyF5DuLFHDdOA2+RKn+H2GNiFC83AIHmqGdXdJozlqzz2J7raZM4m1sWYwriwqw+y5m V8s68nNXCs/yOs9s56T+MTTlH1djOrdjoG/U22EuEzt5QbD4uCB+iZ7KVmbavg4iXvpc jG/JUgOkLlzZrGWo0PKNGNjpkhA+lJ105rEdzq41HH2RunTDmdhX4jSTAWDfHmbeVtTk kyFfvUCdnbLWWjVbd2sN0g4UT8X3Eca7buIsrla1OdixGtaHSGkLKeBmdDYG+hawQ0Vm re0A== X-Gm-Message-State: AO0yUKWQTvn4SJGFxRl/2NPrA8RNO5C8nK35Pr9hsr64FhAmwGf9WF0t 2GZmxJKHwfZRRmG9+xg5ZsCcHqMYlvRN/2Jf9jwpE60Vuk8= X-Google-Smtp-Source: AK7set/9zUbD4UF0jpG0JaqI0E1ubGKfD7JVWPRxlAlrcXL6oCWtgOXTQdgBKktGH7zVRnKSvxkTh0obf42Hd3tKeEw= X-Received: by 2002:a05:6830:245a:b0:694:7e59:55d7 with SMTP id x26-20020a056830245a00b006947e5955d7mr3823824otr.4.1678354996698; Thu, 09 Mar 2023 01:43:16 -0800 (PST) In-Reply-To: <87ttyv2cug.fsf@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x32a.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 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:304176 Archived-At: On Wed, Mar 8, 2023 at 8:43=E2=80=AFPM Augusto Stoffel wrote: > Of course you would need to combine it with split-string (and a > dolist or seq-reduce to process a list of those dotted names). :-) and the kitchen sink to handle all the quirks... I Yuri is just right, there are too many problems in the general case, but in the LSP case it's more tame, which explains why other editors manage to use it al all. > >> Speaking of bloat, and I know I shouldn't insist, but a basic version = of > >> the savable eglot-show-workspace-configuration barely adds 30 LOC. > > > > Your code has at least two big problems: > > > > * it takes the current value from one place and > > potentially saves it in another place. This is asking > > for trouble. I know you favour the 'nil' method exclusively > > for setting e-w-configuration, but it's not the only supported > > methods and there are configurations out in the wild that > > we can't break. Also note the that per-file or per-sub-hierarchy > > workspace configurations _are_supported by LSP (the scopeUri > > argument to the workspace/configuration server request). > > Right, this is a problem. It's missing the part that will =E2=80=9Cnot c= onfuse > the other 10% [of users] to death=E2=80=9D, as you said. > > > * it doesn't take into account dir-local-set-class-variables > > This too. Neither the possibility of e-w-c being a function. Or the possibility of it being an '(eval ...)' form. I think that should make it 20% (I found a lot of eval when perusing GitHub for .dir-locals.el examples). > > These are exactly the type of edge cases that I don't want > > to handle in Eglot. In other words, Emacs has many variable > > setting methods and making an Eglot function to oversimplify > > them, even if it happens to work for an estimated majority of > > cases, is a bad idea, simply because it will break a minority. > > Fair enough, but it seems that this multiplicity of methods basically > precludes one from making a helper tool for configurations. Of course not. Just target the 90% and bail out for the 10%. Usually, if a user has used dir-locals-set-class-variables, probably has no trouble with editing dir-locals. > > So I urge you to generalize your code and propose it here > > in a new :core ELPA package. > > If you provide a function that receives a new configuration value and > stores it back in the right place, then this package becomes trivial. I think you misunderstood me. i was proposing that you work on that generic variable editing facility, and open up an API for packages like Eglot to take advantage. Start working on it in, say, lisp/files-x.el and then later on we could consider making it a :core ELPA package. > If you don't, then this package is completely entangled with Eglot's > logic for reading configs. In either case this doesn't seem to make a > lot of sense as a separate package. I read your code and I even here I don't agree :-) There are a couple of '--' references in there, but this is easy to overcome. And Eglot cannot change that logic without breaking backward compatibility so you're adhering to a published interface. So even an "eglot-edit-wconf" library would make sense as a GNU ELPA package. Jo=C3=A3o