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: Tue, 19 May 2020 17:59:26 +0300 Message-ID: <96bf0b6e-3559-ed02-5596-6a6642188309@yandex.ru> References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> 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="84708"; 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 Tue May 19 17:25:24 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 1jb47O-000LtM-Em for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 17:25:22 +0200 Original-Received: from localhost ([::1]:37616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb47N-0001wr-Gu for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 11:25:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jb3iP-0000s3-07 for Emacs-devel@gnu.org; Tue, 19 May 2020 10:59:33 -0400 Original-Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:46771) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jb3iN-0003xk-OX; Tue, 19 May 2020 10:59:32 -0400 Original-Received: by mail-wr1-x443.google.com with SMTP id w7so16223187wre.13; Tue, 19 May 2020 07:59:30 -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=0X9MMAxYatboT4U09Xub5vd/POFeMHtyC5aZVTGW+Es=; b=qysO/y7sdtWm4bxdTVm9GytjnS3raRZfh3cHMaQFyuJW9uJTvAhFavNHn28MlzstUk sz3j11idqUMbdYvEZkS7WSgMOT/tZL/vmujzn2YNpBbnfTTJl9R5gPUTaXCCBudrX2iN b7PqUE53qN3a6iCXuZH7oP1qyfP1IDksTB2qi7Q+W/yiHZ14bNRr7CsjlpXwld0EztGb +qoGA1VqvG8P2l9W93hgPMYd04bsxuIe39Ten9Ip++4PMHXvw5x28Mf2zpqFOY/0vefs oV1nFowSZ1fWW3dM94tQ5a/b8VHFpSiNX8VRKt1oQ/OcWe+VN582eNhUrum4NndR7BBa vqLA== 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=0X9MMAxYatboT4U09Xub5vd/POFeMHtyC5aZVTGW+Es=; b=F9EuZZ5YSvwN+nGTV2rB37E0Nff6S0D26+460GR9CNzEGG0hA5GuH3G0vpfLTG0uxl i2V9A2smjAsAkClzX0W5jxIi87mJ2jtNcGbCpOp8j+yBtbptO3VbG6TkUeusL9eFY+dG 9/WOx/u+je+O4u1U42L/BnlNHvKsTaTLvE38awu8fnPrse0GtRxlEPJ0x8KYhcnvDxe7 LbVQ6FdMF8g3C96hr3oGhsylLwv9jBV81bexX1SZCRQJkkSk8/LC2KQZA85mMXZxKD52 g0RmlpOhQZ1EsjRCXwvFLzhybtvCJKvgb1gkmgLeJV/zv4IMgyChfCo4XCFmTPEDaWAe r2RA== X-Gm-Message-State: AOAM5305mjFAgUeyYK9/FqWIaqL2N3x3SIHJSY5KdgpFaA7X6K44wIGX bKn6w9Sqtv/yIMkdzVFV1PwMc2/I9/4= X-Google-Smtp-Source: ABdhPJxZyEsRGXjptiseYqaM5NRC4nGPYBzkMm/tWSY8qwoWCOTMV82yVCzrqXoBVbAPBCdln5i3Ig== X-Received: by 2002:adf:ec85:: with SMTP id z5mr28480554wrn.153.1589900368663; Tue, 19 May 2020 07:59:28 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q9sm4066739wmb.34.2020.05.19.07.59.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2020 07:59:28 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::443; envelope-from=raaahh@gmail.com; helo=mail-wr1-x443.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, DKIMWL_BL=0.001, 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:250946 Archived-At: On 19.05.2020 17:11, João Távora wrote: > On Sun, May 17, 2020 at 2:38 PM Dmitry Gutov wrote: > >> I would like to point out, as an author of several packages, that in my >> experience having a package in ELPA is _better_ than having it in the core. > > I know you like to develop on GitHub, and I'm not going to argue that: > it is a completely separate discussion. Indeed. That's why I was arguing about different things, rather than how nice it is to be able to use a different hosting and bug tracker. > I disagree on specific technical reasons that IMO don't get enough attention: Below, you are arguing about two specific packages. I didn't say that _no_ packages should be in the core, however. Just that for most of them there is not much additional benefit from that. But we can discuss these examples, too. > 1. If Company were in the core, you could have major modes in > the core or elsewhere setting up the desired completion strategy or > strategies. I.e. instead of having central database of > `company-backends` that packages like Eglot have to override to behave > sanely, you could have a buffer-local `company-backend` instead. You c > ould continue to develop the specific eclim, clang, xcode, etc backends > on GitHub, but you wouldn't "force" them on people that don't use them. Major modes already define c-a-p-f, we have a frontend-agnostic API for that. On top of it, however, Company provides finer-grained controls for the users, which can't be decided by major modes. I don't think 'M-x completion-at-point' can be realistically expected to go away in any near future, so it doesn't seem like some tighter integration with major modes is on the table (and I don't know what it would look like anyway). As for Eglot, it seems to successfully do what you want here with no extra boilerplate. The only problem I see there is breaking some users' existing configurations. > 2. If Yasnippet were in the core, again, no need for the centralized > database of snippets: major modes define their snippets. Other tools > can use the snippet-defining infrastructure without eating all that > João-the-ten-years-ago newbie cruft. But even with yasnippet.el, it > is possible (though not ideal: Stefan once convinced me to rewrite it > which I did to 90% in a so-called snippet.el -- but there's still the > 10% missing). Yasnippet has been wildly successful without all that. It's the #1 standard snippet solution and format for Emacs. It's in GNU ELPA, everybody can use and depend on it. About "newbie cruft", how will that go away without somebody rewriting yasnippet's code? And when they do, the result can sit in GNU ELPA as well. Finally, the only snippet collections I still see maintained are being done by third-party developers. If the major mode authors (BTW, how many are actively maintaining major modes in the core?) wanted to also add snippet collections, they'd have already done so. And even if they do the new snippets will only reach the users once every 2 years. (facepalm emoji) > 3. If Eglot were in the core, again, no need for the centralized stuff > currently living in eglot-server-programs. Right. So CC Mode will define which completion server will be used by Eglot? Really? And suppose major mode authors even decide to take up that responsibility, the LSP field moves much faster than Emacs these days. Six month after Emacs 27 is released, another LSP server for C++ falls out of fashion and stops being developed, and Emacs users will stay with outdated settings until the next release. Or until their distro switches to Emacs 28, actually, which can be another several years. > Also, major modes in the > core can affect Eglot's LSP interfaces via stronger coupling techniques, > such as adding methods to generic functions. You still never gave an example for that. > Besides major modes, > other tools than build on some LSP basics, such as an LSP-enabled > spell checker could be built. Yes it can. Anything stops it from being in ELPA? > Also, I want to note, again, that even if Company, snippet.el and > Eglot were in the core, they could still _also_ be available > for download via GNU ELPA. I also noted that later. >> The exception to that rule is more or less cases where the package is >> not only added but also enabled by default. > > I've argued that that's not the only exception. I'd argue if we call something "infrastructure", then it should either be enabled by default, or used by other packages, or otherwise have a necessary stronger coupling to other code. This is a fairly high barrier.