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: Fri, 22 May 2020 15:26:57 +0300 Message-ID: <90325e25-7a44-0068-9294-91afda7ed953@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> <712d7134-b8ef-b843-bb20-152717092497@yandex.ru> <87367s1bxu.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="110249"; 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 Fri May 22 14:30:10 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 1jc6oU-000SXU-Fs for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 14:30:10 +0200 Original-Received: from localhost ([::1]:45062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc6oT-0006qy-Hn for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 08:30:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41752) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc6lV-0002LZ-6Z for Emacs-devel@gnu.org; Fri, 22 May 2020 08:27:06 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:35097) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jc6lT-0002pE-Rk; Fri, 22 May 2020 08:27:04 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id x14so4615480wrp.2; Fri, 22 May 2020 05:27:01 -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=LtEfCIeWphS/hrcuGbE3RJAM6jzualoz9MJqYQbpAd4=; b=KW1notHUNhHk/CHs1ob+4agu5+LbbnaRfcpqKRDVr/+CdnzhVsJkGn8n0z4ZiCHzUq XM7E0hM9chVuJkYmn97nC9gUm1CQmvdCcnfqlypa0VWnVvCn2n3G7M+Mhlq8cPlB5V5G he/Ma7uyofwEBZN9Rlrpm42Cbap0VJE/oSz6jJbm4PLZMu0lHbXlvkl7mNPT7VLVvpSB tRtSFeykr30B9ICjEjq6oecjd5zQ0fSy7fsZQYBd7SJIICit5qmyLpmqMXoqMXsrTVtU 6WLTyg7AlKTrw4QbvrO1BzvvuN8mdNLCZYQiw53dw8BRCGjsHsPBJmzyNI3xcWzodnvG DbTg== 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=LtEfCIeWphS/hrcuGbE3RJAM6jzualoz9MJqYQbpAd4=; b=nYuxqylCWBAe/ClfD9NatZRwyOHoV1aB6UwJmDubtDfj55ycAaQZScA9YRFyF5fSTR D6cbmqvXSkJeXEmGHp/38qDJPJPrsMUSnXJAtLbzecngcVF1v9k0QP9H2mttjNYhHega Uq6orlaWolIbAb0BKOpebxz1vrUV+mq/4B2jEIiQTerCOj6gXdhGl1HHI5ZkvQPTxaTN on/yP9yZ8y6lzsfUfNMoLCtvNJm/vDmOS9TdvYzwSZkf83994Gonkqv3k05VURXJx2zM cx4QbGCXcJWPdVYYweWIBotAh9saeGfC9KgkjG15eR3wi+68ZX3vQj0Ze9YQxS7Su5UQ DD6g== X-Gm-Message-State: AOAM530TefXiDIuOPXCOvhJYGkhsfZI7IHKDi2iggFhBSaSU5jmDXOXh JF5xrQn9Jk85HYu/ZMeeTJRm08/a X-Google-Smtp-Source: ABdhPJwRWxZNwJOUZige1MtKWYDl25A5klLBDBSzM+uGH2bVhy5mmGQjOelyRpXg/yqN4VFFIelDJw== X-Received: by 2002:adf:8302:: with SMTP id 2mr3393365wrd.114.1590150420042; Fri, 22 May 2020 05:27:00 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id g69sm4941061wmg.15.2020.05.22.05.26.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 05:26:59 -0700 (PDT) In-Reply-To: <87367s1bxu.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=raaahh@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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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 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:251215 Archived-At: On 22.05.2020 13:49, João Távora wrote: >>> 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. > > No. Burden of proof is on the accuser. Open new issue, start a thread, > continue an existing one, etc. Also: "The topic is core vs ELPA." You've made my point. >>>>>  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. > > But that's the server's fault.> Hopefully, if major modes start relying > on things, they should choose wisely and rely on some stable stuff. Hopefully major modes don't. > Just like ispell.el does to spelling programs. I'm just saying > generalities, because these things are general, they have nothing to do > with LSP. If one wants integration one has to integrate. Did you just compare RLS to Aspell? Relying on a "stable" program is fine until it doesn't do the job anymore. > Seems like you don't want much integration. Fine. It's been said to be > hard, and that's true. But there _is_ an I in IDE, and it doesn't stand > for "immense .emacs". I never suggested to put the burden of configuring this on the user. >>> 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. > > They regularly solve LSP server bugs in lsp-mode? Very bad idea. Relying > on features is one thing, relying on bugs is another thing entirely. Did that report concern a bug in a language server? It didn't look that way to me. >>> 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 supose it'll work the same way we deal with a bug report about "my > colours are all garbled" and it turns out to be about font-lock, which > the user is oblivious to. Offloading work to other contributors, I see. >>>> 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. > > No. If there is LSP support in emacs.git and Flyspell is in emacs.git, > you just develop in the same repo, emacs.git. So what? Implementation-wise, it will be a plugin either way. Which would be just as easy to put in ELPA.