From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Felician Nemeth Newsgroups: gmane.emacs.devel Subject: Re: [GNU ELPA] eglot-x.el: Protocol extensions for Eglot Date: Sat, 06 May 2023 17:17:14 +0200 Message-ID: <87h6spbibp.fsf@betli.tmit.bme.hu> References: <874jorc7q2.fsf@betli.tmit.bme.hu> <83h6sqj4ed.fsf@gnu.org> <87354auafu.fsf@gmail.com> <835y96j10l.fsf@gnu.org> <87y1m2spbd.fsf@gmail.com> <87pm7dbo41.fsf@betli.tmit.bme.hu> <83r0rtfv3m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3278"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 06 17:18:10 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 1pvJfl-0000ZB-7e for ged-emacs-devel@m.gmane-mx.org; Sat, 06 May 2023 17:18:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvJf4-0007Oo-F5; Sat, 06 May 2023 11:17:26 -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 1pvJf1-0007OR-3U for emacs-devel@gnu.org; Sat, 06 May 2023 11:17:23 -0400 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pvJev-0003xP-F0; Sat, 06 May 2023 11:17:22 -0400 Original-Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-3f315735514so127050625e9.1; Sat, 06 May 2023 08:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683386235; x=1685978235; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=GOkDNJVo22fCoDwcjeDwN9Ic4ylPrBXKBUWqr6e0Njc=; b=ZAcVFP8TneswAa8z0GkV0TixHHzVkepZFd19lB/6uE+EtUIMzh7eTCLoV/hwqvTiYu mS8VtUw9T/qDRb10Ig3ebQgh951TpG/uDRj0knQVySyIPwDeP8AERwaUPKLXIrNmTsvt /pcpaxkGZfrThtJl9Oq5mKTWqLjWUocGq7/ylc+ntc/8Ui+2yIA9xg63xw7k79bRbc04 LUcsKJ/GT7zaKJiA4nqc40GHklfnX1b95Jex3UBfqdU0sZ4v8aG4miwNjwefhjgYXpLs 7iSmeaLnlmU0lpGNjelz10jNMjp2KvxyGTNgSKwFzcPje07KU/QYzoMEk6KKz6MGBtpM 8JYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683386235; x=1685978235; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GOkDNJVo22fCoDwcjeDwN9Ic4ylPrBXKBUWqr6e0Njc=; b=ZhvjvOzIbrY7zwQFsVTMPaHPGk6HnRG+2tb9GYbQIvYlyE4TRGO/bHsGClO7ZeWuyY t5VOgfeF822caXbyu+QTyZqDCmiEUNKJH5KC/fz9J5V3img0e2ZyvyZBRBAx97zAXp2x Thkr4PaqpxXyIcV62TN/9gko/CwrsiCX+aJf8HN+cSJ+926CyZf6BVwkZ3/L6sVJzwix kqSOAn5H/eWc1mcVrh9syx6w2rvO2GjyPNvMbXfQXtdavk8Zj0sj70glj9LauAC0tNpQ nw8k68nTQtwH/XCqLQaDLrPA6nmXFHE6FM6AMHX/y6SN1zBcfAE1GlmxzVA1d3oevUim Kj1g== X-Gm-Message-State: AC+VfDxeA1NlMMpybI3Wi4QX5DgNV+/p6j0wUdXQ9G7Ygre4mBXjq+dW RZZXsKxy6dxcXXmpKZRipmhopwEkSDM= X-Google-Smtp-Source: ACHHUZ67JiRwKzRfrr9VyDWbNd11Z5aWLpZs878Gi63baem8HBT/QPrsO6pyLvWoDrHWdL/ziKNWjQ== X-Received: by 2002:adf:e70b:0:b0:2da:3ef5:5a39 with SMTP id c11-20020adfe70b000000b002da3ef55a39mr3925265wrm.14.1683386235437; Sat, 06 May 2023 08:17:15 -0700 (PDT) Original-Received: from betli.gmail.com (catv-89-134-210-182.catv.fixed.vodafone.hu. [89.134.210.182]) by smtp.gmail.com with ESMTPSA id z8-20020adfec88000000b003062675d4c9sm5670007wrn.39.2023.05.06.08.17.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 May 2023 08:17:15 -0700 (PDT) In-Reply-To: <83r0rtfv3m.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 May 2023 16:27:41 +0300") Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEX5+fmhoaEwMDD/ ///TMNVWAAAAAWJLR0QDEQxM8gAAAAlwSFlzAAAPEgAADxIBIZvyMwAAAAd0SU1FB+AICBUfHgLs gGoAAAGXSURBVCjPRdK/b5tAFAfw753gBEwM2ApMbuVIqf+Ko0qiyhOu4sj2xJBYMn/FUdX7UUUZ OjHgyvf+yj6IcW6Bjx53934ADEvs8bmEr8UVoTYTOyJO9KoYsVofN8kILdbeJ8Li6YpZWop4xOK0 VdfIoXmkHn5/5D7/Ts/8THacSqnkKTcMTxgUkVzFnEIRTKwwYYSCvzfg16f0i8YApW/XG/Pm8R49 dXjxKmRnxv3OwooQWcv4RUYem1fsNe/WU63uk7AmYxk78y32/ee2tZB4fO+WcZ7lnIGEolXW1EGw LfkSuQ0XTgRefgNlfNwRNV6QhBxJ8JNxTMUPyBqTd0bjaAP5G7NJRU39z80hLOZTjqB7K3tEEFSj aEsuQew6qBxxyhHjVUR7H7NpC9iHJZGLMCEuweqAqE1BHbfK2oRIz9EHYA/+wiFWru9smeVfuWNZ 2+NFtX80UA1TvJNdytM4DwO4kY7bJz8Qcd0G0ceslZGkkeoBsjUHwF1+jjM3XHaXEZ7mGLfwPFO+ RV9QLY2iEdmDo78D/gNPaXVYqd+pyQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxNi0wOC0wOFQyMzoz MDoyOCswMjowMGy/yHYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTYtMDgtMDhUMjM6MzA6MjgrMDI6 MDAd4nDKAAAAAElFTkSuQmCC Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=felician.nemeth@gmail.com; helo=mail-wm1-x335.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:305909 Archived-At: Eli Zaretskii writes: > IMO, it is no longer reasonable to have extensions that cannot be > possibly supported by the version of Eglot that comes with Emacs. > IOW, if someone wants to download and install your extensions, we > should try not to force them to also download and install a newer > version of Eglot from ELPA. I hope this is possible. Yes, I think so. I'll keep this in mind when I modify eglot-x. > What mechanisms aside of advice can be used to extend Eglot so that it > could optionally support those extensions? 1. Eglot support editing remote files when the source files and the LSP server are on the same remote system. There is an extension that makes possible to edit files when the files and the server are on different systems. Eglot's own remote file support rewrites filenames, which interfered with my implementation. My solution was basically to selective advice some Eglot functions to make file-remote-p always return nil. An alternative approach could be an Eglot configuration variable to optionally disable its tramp support. 2. There's a clangd extension for encoding negotiation. The server sends the result of the negotiation in an InitializeResult response. Eglot saves the capabilities part of this response, which is usually enough, but this extension puts the negotiated encoding elsewhere. Eglot-x uses a series of add-advices calls to copy the encoding string into the exposed capabilities variable. An alternative approach for Eglot could be to save the whole InitializeResult response as well. However, the encoding negotiation extension has been standardized (in a slightly different way). Eglot does support the standardized feature. So maybe it is enough to wait a bit until clangd implements the new standard and then this feature can be removed from eglot-x. 3. Eglot uses the eglot--apply-text-edits defun to apply server initiated edits. There is an extension that allows the server to send the edits in a different format (snippet-text-edits). Eglot-x puts an advise on eglot--apply-text-edits to check the format of the edits and act accordingly. I don't know how to avoid this advice. 4. Eglot-x puts an advice on eglot--mode-line-format in order to display the server's status (which the server sends if the client supports an LSP extension.) I think eglot-x should just use its own space in the mode line. I think I just wasn't able to figure out how it could be put next to Eglot's mode-line. 5. Finally, eglot-x stores its own state in an instance of the eglot-lsp-server. eglot-lsp-server is defined with defclass, so it is possible to add new slots to it without any problem. For some reason I just wanted to hide these eglot-x specific slots from Eglot. It think the solution is to simply not use an advice here.