From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Wed, 20 May 2020 20:20:37 +0300 Message-ID: <712d7134-b8ef-b843-bb20-152717092497@yandex.ru> References: <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <96bf0b6e-3559-ed02-5596-6a6642188309@yandex.ru> <93a7bb1c-390f-440f-02cc-6cce39ea9431@yandex.ru> <87k1175sl3.fsf@gmail.com> <2a43cea0-8e00-3c22-3ddc-eff29fc9b2db@yandex.ru> <87d06y4kze.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="22174"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Richard Stallman , joostkremers@fastmail.fm, emacs-devel , "Alfred M. Szmidt" , Stefan Monnier , =?UTF-8?B?7KGw7ISx67mI?= , Eli Zaretskii , Phillip Lord To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 20 19:21:27 2020 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 1jbSPD-0005cx-Oy for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 19:21:23 +0200 Original-Received: from localhost ([::1]:56010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbSPC-0006UJ-QC for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 13:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbSOa-0005Y7-W3 for Emacs-devel@gnu.org; Wed, 20 May 2020 13:20:45 -0400 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:34028) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbSOZ-0002lN-OP; Wed, 20 May 2020 13:20:44 -0400 Original-Received: by mail-wr1-x42c.google.com with SMTP id g12so2770495wrw.1; Wed, 20 May 2020 10:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eBIigxqh2xRDX1/IWTBzFE9d5cTrAPTAaKXDhe+Hhzc=; b=rdQ16k1fCw/fxWd1mFfIwoJxY4BH40Lyd9gFZ7a6a3v2PdJcGEUD31Cf1tiLbBfS9v 9lITEhZ5T9HJM2kurojCDzAVawI1E/PSy7yTMi7TwlpcEr6NTMzeTFbn4uBYw4UkqQb7 eFjaRsQulzZRGgWpDokfcg3ZLi0tlc8aI40tJ9/N474YdkRApMH9Bypzjw+xXD872jpL h/oiR/7pSgVD3WKd4Hszm7BOUWHkrmQLQoayBM0kwCDIT4d4SUZk9kWlrw5Qgbi0/tDb OfdbZL1NKnOP961DFP2oJ4ifLnursrwx70Wh1i42EnRNYnNsdIl3O0WLio3EhpObQooM C2hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eBIigxqh2xRDX1/IWTBzFE9d5cTrAPTAaKXDhe+Hhzc=; b=hIC+LB1lCrBQES7QQxDzFVES67wS+GGWvltbXIs+D5aenX4iFbItLmfcq2YAbGklsI Wfj67FQDhwZCeQ+8fr/zFPOqdGxgPxWcoFYjSWJEQslyY8DoZUnSpziidD5wEsDOMEAc exsYRE1ew6dLXxfGaqc+OwDDUxithA3O+A2UkKvTWTWoJDUumwe3+3A3S6MwnjQDeUHQ H2GAmEyblB4ht0plqSmDKTmFcAioQSBuctOWfGoeZmHaBQEFjUi2kjYd2szOntvOEjay Wn/Ozha2zvBC7En0xTvlpTlic4z0PqSzbF1FJi5rZl4vQA1PF5E9q5nfNzCLSzw1P71A SiRw== X-Gm-Message-State: AOAM532c5SBloQzND7fLinMiTjWh8Wd6s3IFUiwsOq6ao/ZD5/ZBIxG0 uiEMOtw9EevjohO+XsW6AjZB/Jvz X-Google-Smtp-Source: ABdhPJy2t3OANWFq5vUhq++ZvYfakkHfygg8+DcY4oAy0Z5IrfaAjQBCeHyEZ6qqZNApyZa5T3yDOA== X-Received: by 2002:a05:6000:100d:: with SMTP id a13mr2198965wrx.317.1589995240010; Wed, 20 May 2020 10:20:40 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id v24sm3896114wmh.45.2020.05.20.10.20.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 10:20:39 -0700 (PDT) In-Reply-To: <87d06y4kze.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:251077 Archived-At: On 20.05.2020 19:41, João Távora wrote: > Dmitry Gutov writes: > >>> Right. That part is optional, as I wrote. >> So it's actually off topic for this discussion. > > AFAIU we've been talking about modularity for quite a while, so it's > really very much on topic that we discuss ways to modularize software > and the possibilities that opens. The topic is core vs ELPA. >> Fix your completion function to honor the c-a-p-f contract (at least >> when it matters). > > It _is_ honouring it. You want to revisit that, fine. Open an issue in > Eglot's bug tracker. We've been over this a dozen times, on the issue tracker, in the commit comments, etc. If you just want to give me the runaround, it's on you. >> I wouldn't say no to a milk run, however. > > Skimmed, full-fat, goat's, what do you want? Goat milk is the best. >>>  not even talking about people rejecting such changes. Only about >>> that someone would need to make them, and to maintain them thereafter. >>> Code doesn't really rot, especially when maintained in the same >>> repository, built together and tested together. >> I already explained how these settings get outdated. > > I missed it. Can you point to it? LSP servers come and go, settings get outdated. Like the one that was mentioned in the RLS issue, I imagine. >> So IIUC you want to delegate that to both major modes that are >> available for Rust currently. And if the one installed by a user will >> fail to do that (or do it correctly), and the user files a report with >> us, we will shrug and forward them to deal with the authors of their >> major mode (helpfully explaining how to determine what major mode they >> are currently using). > >> Is that the idea? > > More or less, yes. That's very much what I do already when the problem > is on the server side. It's totally reasonable that the user comes to > Eglot first, because that is the user-facing side. But the problem very > often lies partially in the server, so we try to politely inform users > of that and help them debug and/or collect information from Eglot's > interfaces. Meanwhile, lsp-mode developers will address similar reports directly, without footballing the users. You probably see what I'm getting at. > Come to think of it, there's another argument for making Eglot > "invisible" in the long run: the report would go directly to foo-mode's > developers. I'm not sure this is how it's going to work. But suppose it will. And suppose we only consider the major modes already in Emacs. If you decide to only field Debbugs issues that have "eglot" or "lsp" in the name, you will miss said reports. Who's going to address them? >>> I don't recall: if Flyspell extensible? Like Flymake, for instance. If >>> it is, this seems to call for an eglot-flyspell plugin. >>> I don't think it is. And extensibility is not a binary thing, >>> depends on the API. Oftentimes rewriting is better. Flymake was >>> extensible, before the rewrite. >> Sounds like it should be. If so, my point stands. > > Doen't stand very strong though. IIUC you're saying: first invest the > effort in making Flyspell extensible specifically to support LSP, then > develop its LSP backend in a different repo because modularity. That's > not very enticing :-) That's how it's going to have to work anyway.