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: [GNU ELPA] eglot-x.el: Protocol extensions for Eglot Date: Fri, 05 May 2023 15:20:21 +0100 Message-ID: <87354auafu.fsf@gmail.com> References: <874jorc7q2.fsf@betli.tmit.bme.hu> <83h6sqj4ed.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="32590"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Felician Nemeth , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 05 16:18:55 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 1puwGt-0008F1-Mz for ged-emacs-devel@m.gmane-mx.org; Fri, 05 May 2023 16:18:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puwGE-0005hz-5R; Fri, 05 May 2023 10:18:14 -0400 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 1puwGC-0005hk-Aj for emacs-devel@gnu.org; Fri, 05 May 2023 10:18:12 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1puwGA-00022H-HH; Fri, 05 May 2023 10:18:12 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-306dbad5182so1249164f8f.1; Fri, 05 May 2023 07:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683296288; x=1685888288; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TP/UH1rruQjAJOSw0O6dNJLQfEL1HLwgrwWZgiP4KZc=; b=kV+rUD2qc/2+329PsDIgxc0qR+eObm80bkosZR8JZ4YriAdMDpft5O1q5+MuH5y4pf wVrk2ZIsHpVgKlFkeHn9VaTuRK9n2F6et8XTVBcaDmqGPZybm/ALsTmDR80fWhkNAnmH QBpNBT+BkzKq/dY4e0SGRGSwooB1ijKvABpIyBHUAb1c5UwsSMLAwCqh5hwm8asjp8m+ IyzPBw7b87Oo23yI9NECeQEunwiUmNWlopOXq9u2hki/J1K3g26ghd4Uj4Vu2b1qwUIQ SmHs6wSCRzjus4QTD7qxkf8GFIFulDwVzruJoaY+18irapb/Fgt7J2PAz2UJL3nJ6b+X KXQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683296288; x=1685888288; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TP/UH1rruQjAJOSw0O6dNJLQfEL1HLwgrwWZgiP4KZc=; b=IFR6m1b2zFgmuZ9yJ4tc4TejSFJGARNEzXM9aHMPIBZbn9JPhHxfigdE6DUQDfiezC 0U85VbAtxac9eMdT34x9FXf7klg3MJSOZNdxsbM1IlXZc0cnFfFu7EeVkCpUVIPq/MRI D+hFsA73z36mqXv3cs+IrhXGSn7gCVMLSRKw452NUnika34AzZZOyZw3VAY4huMpi3Rb WKSF9Ml34QI02I4eB4mQ+hbedCWRj+cjoGHLZsmYk2BVw4+uWI1Wc0dduzk7+18fP9O7 W+D5iRtbsQDb8aS85IWQBPr6QFqN1vjeqowEXN9z6FncIcxdmdRwHLRLprTI4/ogJJWi 9BSA== X-Gm-Message-State: AC+VfDzLgFyF7JhjVpsBHnHZtgJprCuFD7HmCEhfdRL4PLQQqrUfP93P XichXXHeqX0G7ZwfH+wSSTzIbtz4hKk= X-Google-Smtp-Source: ACHHUZ7Zht8Lk5CFERAkEmL/PB6VpYuyh72m/S+YDtaWbzh1Tc8L7yJSzr9JY1Eg2busWBGc8TJrcg== X-Received: by 2002:a5d:4146:0:b0:2cf:e747:b0d4 with SMTP id c6-20020a5d4146000000b002cfe747b0d4mr1429427wrq.40.1683296288199; Fri, 05 May 2023 07:18:08 -0700 (PDT) Original-Received: from krug (87-196-74-197.net.novis.pt. [87.196.74.197]) by smtp.gmail.com with ESMTPSA id m2-20020a056000008200b0030630120e56sm2522487wrx.57.2023.05.05.07.18.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 May 2023 07:18:07 -0700 (PDT) In-Reply-To: <83h6sqj4ed.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 May 2023 16:26:18 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x430.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:305880 Archived-At: Eli Zaretskii writes: >> Jo=C3=A3o intend to support only the standardized protocol features in >> eglot.el, but lots of LSP servers extend the protocol in their own way. >> (It was Jo=C3=A3o who suggested the package name long ago.) I considered >> eglot-x just an experiment and a learning possibility, but people seem >> to use it, so I'd like to make their life easier by this submission. > > It sounds strange to me to refuse to support LSP extensions in > eglot.el. Noone "refused" anything. Some years ago, Felici=C3=A1n and I came to this agreement. If there is an actual patch for eglot.el being proposed, I can review it. Felici=C3=A1n has contributed much code for eglot.el and th= ey are very appreciated. > At the very least, eglot.el could benefit from offering a > supported mechanism for adding such extensions; there should be no > need for using advice for that. I agree. Eglot has an API. I haven't looked at eglot-x in depth but I suspect it's using some of this API in part. If it's not sufficient, then Eglot could enhance it. What part of eglot-x is using advice, if any? > Jo=C3=A3o, why would you not consider supporting these extensions as part > of eglot.el? They're non-standard, each server has its own set of extensions, which in some cases could be volatile and become obsolete. Furthermore, I would suspect that if eglot-x.el modifies eglot.el's standard behaviour, it is not as well tested across different servers and could provide a surprise for users of other servers. A guiding principle of eglot.el (and indede LSP) is to not have any server-specific code. The only such (reasonably manageable) exception is the eglot-server-programs variable. But even this variable should ideally be dissipated across settings in major modes, as was frequently suggested for gdscript.el mode with much success. I plan to spin it off to a new file in the near future, as it is growing very fast. Furthermore, I presume some of these extensions need some kind of user-facing UI, and Eglot is conservative about that. As frequently explained, I generally prefer using non-LSP generic UIs that integrate well with all parts of Emacs. Fine tuning the design of such UIs takes time and care. So in general, I think having eglot-x.el as a kind of laboratory where authors can experiment freely with new LSP-powered UIs is an excellent approach. As these extensions make their way into the official LSP protocol Eglot can support them. For example, I believe "inlay hints" started as some kind of rust-specific protocol extension and is now well-supported in Eglot for many servers (I use it daily). We could consider bundling eglot-x.el with the Eglot ELPA package (I do hope Felici=C3=A1n is aware of the ins and outs of :core packages though). And I think a separate package isn't really bad either. Jo=C3=A3o