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: Fri, 22 May 2020 11:49:49 +0100 Message-ID: <87367s1bxu.fsf@gmail.com> 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> 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="67873"; 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 Fri May 22 12:50:32 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 1jc5G4-000HZ7-I4 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 12:50:32 +0200 Original-Received: from localhost ([::1]:38098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc5G3-0000Xm-IP for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 06:50:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc5FT-00082T-T5 for Emacs-devel@gnu.org; Fri, 22 May 2020 06:49:55 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:37433) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jc5FS-0001rq-P2; Fri, 22 May 2020 06:49:55 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id f5so1129062wmh.2; Fri, 22 May 2020 03:49:53 -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=WDd9TK24MWAs4zsohkN9cUk2emTFmJGuc8ODocDSrAs=; b=WPZKOCIYSryaS4fmuydzxYOVWDiRebj9n9u88iGtEdYi5+Y3NTlbA8XkoZPFlp+nhb aApHvBixA4peVt3I3bm4vQLGYHuc+tfAK53KpnEttT6hTuKWT4hOs3v1z+jvO40t46sY ztClTZLpqjF7qTPlIUzYyyifUa1ghXfsxZeO60GrqhPBmKZBzmMs8mEr6vt5Xli9bbd8 Zmy0ktI4CMHXXZ2CMTLWorjIwQJaYcKxzVN6vk7fm3BFYAINrYtUzA8qYZGkYiuonTEP EgE4f5zrJUqA/BqlovHkgWi2vxmqvEdMH8RZ4VfAkYlKHHjIEiiIXYMZ0jTgOy6iLelC Zj3Q== 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=WDd9TK24MWAs4zsohkN9cUk2emTFmJGuc8ODocDSrAs=; b=LozOtGdca7Zxdi+31HKAaOGsrrSs8b6uycgLyWgjW9Je/n6EndGlI0FQa0mp1s8GRF 1/ORaRemipeIq0z9a0GKUQ6MobhdioWdTaufgKSy1s15wcQ+YB0DzP5qtfw+SnkmnlnF SKmw69sL9rhl4hbLBE9hZcb5Dh+87poSpEDt1V3EtgAlldNyxiovOI/Bl2mr+tyhXecm EYV0J0MEK+hT6WoHsrPIDaxe67cv/NSv/NSMMeQSFgPFlzSHvvDhuUnoVxEAjeSD1BPh 4H0Y0hUn5+PcVSX179OL48vTSjS7hILIuvlzfudca0On4Uxqig+aLq3JhgYfcSuNWZhb nK7w== X-Gm-Message-State: AOAM533t6x9B1hDjcohPo2Z8qMsvgWu/EUTDrM1rzIBQ9KSxZ2wbB9GG /WAnrYfxxUfTMS36iRMKFKvoZzAKtV9zMg== X-Google-Smtp-Source: ABdhPJy6MGqYTwY6oO38h4Rrsigd6yxfBLcseszLy4bGmKAZXAhrTZFN5N6Y//oOFK2IcFvs+fOYYg== X-Received: by 2002:a1c:7212:: with SMTP id n18mr13918841wmc.129.1590144591896; Fri, 22 May 2020 03:49:51 -0700 (PDT) Original-Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id 88sm9033051wrq.77.2020.05.22.03.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2020 03:49:50 -0700 (PDT) In-Reply-To: <712d7134-b8ef-b843-bb20-152717092497@yandex.ru> (Dmitry Gutov's message of "Wed, 20 May 2020 20:20:37 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x333.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:251208 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. > > The topic is core vs ELPA. Sorry to have drifted the party line. Anyway, my point, for your consideration: "I wish Company could be modularized. Among other reasons so that a part of it could enter core and be more integrated there". >> 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." >>>> =C2=A0not even talking about people rejecting such changes. Only= about >>>> that someone would need to make them, and to maintain them therea= fter. >>>> 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. 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. 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". >> 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. >> 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. Again, nothing to do with LSP. And again, you're putting the cart of the apocalypse way in front of the horses of the apocalypse. >>> 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. Jo=C3=A3o