From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Wed, 20 May 2020 17:41:41 +0100 Message-ID: <87d06y4kze.fsf@gmail.com> References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="121878"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: Richard Stallman , joostkremers@fastmail.fm, emacs-devel , "Alfred M. Szmidt" , Stefan Monnier , =?utf-8?B?7KGw7ISx67mI?= , Eli Zaretskii , Phillip Lord To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 20 18:45:42 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 1jbRqf-000VWz-FX for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 18:45:41 +0200 Original-Received: from localhost ([::1]:55718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbRqe-0002aL-Hw for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 12:45:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbRmx-0007FW-8x for Emacs-devel@gnu.org; Wed, 20 May 2020 12:41:51 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:37093) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbRmt-0003s1-V5; Wed, 20 May 2020 12:41:50 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id l17so3851636wrr.4; Wed, 20 May 2020 09:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=M6FkXGz0M8FyIMVzT8LgVg3D54DPMUC56M7N1mqYIco=; b=HDpkVQkqiu+YqXoxuSxNLJbhTDalKLokdtCNKTKI9dDIfeU4joPLLdlptMnIZMEXsM er3z0syQ1lBaF9VCSLFBU/Qd0oopSAdBJcyVSSikqwfPkGqgVmP3EpF9wjd5Lqq6ZjVR kUZ3UwzxXRkrYqN03gwSs2i5On3ZZTLNm7ECM/XTrrHWkKPBEWhqNCTdI5BXYt2wUttK HW2NOIMTNpXDQE7HibORh0JS3aqQq0msAQMnJPg5zZRYO9ibKPNw4Nip9TRZ7soYRtoD /rMs2J4Kke5w61M4yC/DwMrRA4QMjzbMe83a535clhxdKDz7UwK08eoY7aDAK4Rcc627 7mtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=M6FkXGz0M8FyIMVzT8LgVg3D54DPMUC56M7N1mqYIco=; b=bd9HPNAXx85RjowBFvBjOUyydH98Z2mke8Q/5UkfdlVWJicCGZQtylGd4OtXIJVRTf LIDGeHxzW+RSNnyo14jBQXqgJdA6YV3zxb1FhNQvkvUSVv9SIj1pt3Zy3wVELsEytBqV xuevHhhw2g+yZYelHSxYEvR4hpRNj8QZAlyiY2Nfh4LZeDC58pWMNgJeqr0b+NpiF4sh nPVxCL8nevd0aWCwEXAujLwTIfnTPPln/Zj+PPdg6virig9NnzUCr/jHD/3AG4CtRcF6 UJWlQsU7MduXmEcVt/cAZ2MNb7rtsdKLlnHUPF2H9NLANT0WT/vE9uZh3eSExJJDyn8l 6oOg== X-Gm-Message-State: AOAM530rwaRJV3cC4XR5vJzemhDcYKqPW36ZK7FbXaqL+bWi6e389CpO lAGhaDrIY/P8KHB98fKDJ/T88sKNvlkqyw== X-Google-Smtp-Source: ABdhPJyptEEi06Uv5F6MQc/wPGbvidLU7ZhjZCpOP+kFGqYxl4eLwhcQjNefntFMK/12UnKZ9kMuKQ== X-Received: by 2002:a05:6000:10c3:: with SMTP id b3mr5219336wrx.53.1589992904794; Wed, 20 May 2020 09:41:44 -0700 (PDT) Original-Received: from krug ([89.180.147.224]) by smtp.gmail.com with ESMTPSA id r3sm3508964wmh.48.2020.05.20.09.41.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2020 09:41:43 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Wed, 20 May 2020 17:40:34 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.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: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, 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:251076 Archived-At: 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. > 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. Better yet, M-x report-emacs-bug, put "eglot" somewhere in the title, and make sure you CC me in the receipt from debbugs (yes I know you know how to do these things, just testing out a new section in the README.md ;-) ) > I wouldn't say no to a milk run, however. Skimmed, full-fat, goat's, what do you want? >> =C2=A0not even talking about people rejecting such changes. Only ab= out >> that someone would need to make them, and to maintain them thereafte= r. >> 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? >> Anyway, major modes in emacs are about loading one file, or=C2=A0 >> requiring one feature and having everything set up, even if not >> enabled immediately. In my opinion. > > Another problem with that idea is that it hints that major modes might > stop to work properly in the absence of LSP. Or a least some of their=20 > major functions. I mean, major modes can _leverage_ LSP: if it's not there they do something best-effortish. Modes can leverage multiple things: up to the mode. > That aside, going back to > https://github.com/joaotavora/eglot/issues/363, it seems to mention > some extra configuration that is needed to be done for integration for > RLS. And it's fiddly, and the format how to specify it is non-obvious. That's a question of interfaces and documentations. The format to configure servers in some parts is "free", or "server dependent". It's the major mode that must know what is reasonable to provide to the server that it is configururing. > 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. 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 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 :-) Jo=C3=A3o