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 22:38:36 +0300 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <96bf0b6e-3559-ed02-5596-6a6642188309@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="47910"; 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 21:39:15 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 1jb855-000CKw-6f for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 21:39:15 +0200 Original-Received: from localhost ([::1]:42550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb854-0007cy-63 for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 15:39:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jb84a-0007Dk-Ew for Emacs-devel@gnu.org; Tue, 19 May 2020 15:38:44 -0400 Original-Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]:35710) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jb84Y-0001GP-Rm; Tue, 19 May 2020 15:38:44 -0400 Original-Received: by mail-wr1-x444.google.com with SMTP id j5so737300wrq.2; Tue, 19 May 2020 12:38:41 -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=Hgt025P0bZV7QHyjuQldlswgH+/Wb/haMjUtnYyBqXo=; b=tFML80rX9OS59TYRfoZa1TvVjJXDCHEZE62iCI113uIyEDEfWHw0y5HdSmn4Y15scz WQRWCrdZzGvL9WqY9EsMCAYzYgzk8DMdh+I3vogwImdxibRWzc9wGplx/0ocrOpPMkub CeTCWuGubcuS5Lr6NLzuadpK44L14jnexAPCejZb9X1SmPCvHYE/CbS3fsTNVfpyNz13 1qDBodGI9qYSdIHZMsu/kEeXqu4k7Se41D9S/AoQeSIE5JtEd7nxwICCZesHLhKLIuF0 0WxmNlB65nmPui39dk7zkX6/OPlxujwTGy/FUZq2tIwYjYusxR8oMm+ZUG0MTv7uK+GT 5/Ow== 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=Hgt025P0bZV7QHyjuQldlswgH+/Wb/haMjUtnYyBqXo=; b=GLiN76WkfCBRYYoxwBvE3lpXP+Jw5c1yhF93knKz4lKJjcCLfjU9/XwYpoNSWWqLeL B56hX/TqWsJuMBHcw+Ar8ODTsu+1UTS1oyO6aAODGlR5nxIXICadYR9/Wvd9eylNRhLE E2phk5fe7bidVLG2zJs9z87SojqyOJBOFgn90Ebb13pGUjiVdmzJJSUIhoJfQxYuLDKb M1AbCr3yjbOKqw6/6RImAkjspAp9u1/hBEAt0nVlK2jawcv5ri62Llc7Eny1fg0/z9vm 8HO1jdswkJiZBAy6nxDlMa95Rr/UsGFlGPtyqTOTKT8N5+wiOfqR1iw0aGy+uFfF4CAJ HBGw== X-Gm-Message-State: AOAM531X/Jv9WsA3f/qhLxu2PVqcryeAhKpflJPgVxXWLw1BdZ9izljy c60QQz4CaLdiKDai0aiSS+GSHYWM X-Google-Smtp-Source: ABdhPJy4G3MM6n4VTbTDuCec02eAuh//n3LOPpvBI2E+Tap6h6gMh+pU/OBfg5E2mO/c8EVxgfPjMw== X-Received: by 2002:adf:8023:: with SMTP id 32mr499342wrk.247.1589917119534; Tue, 19 May 2020 12:38:39 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id x24sm481144wrd.51.2020.05.19.12.38.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2020 12:38:38 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=raaahh@gmail.com; helo=mail-wr1-x444.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:250979 Archived-At: On 19.05.2020 20:28, João Távora wrote: >> 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). > > I'm not arguing for it to go away, not at all. I am arguing for a completion > tooltip in the core, much like icomplete, one that gets to integrate with > other pieces in the core. Maybe you could provide better arguments. Because I understand the idea, but the details of the argument don't convince me, so far. If you just argued that it would be good to have a completion popup in the core, and _enabled by default_, I would have nothing to say against that. >> 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. > > In the Clangd webpage, a warning was issued to Eglot users: > > "**company-clang is enabled by default**, and will interfere with clangd. > Disable it in `M-x customize-variable RET company-backends RET`." This is a different point than you originally made. > This is clearly counter to Eglot's out-of-the-box experience, so I had > to override company-backends. Again, if you had left that brutal default > configuration out of the company package, I wouldn't have had to. > Really, even if just on github, why don't you create a `company-nocruft` > package that only has capf support? Because I have other things on my list, and because supporting different versions of the same package is not as fun as someone might expect. Also, you ask for things that would make life easier for you, but when I ask you to play by the rules of the framework, you reserve your choice to just go the most convenient route. > Anyway, after my fix, I've finally got them to update the webpage: > > https://github.com/llvm/clangd-www/pull/1/commits/a328d8e92eb05b8e62cd0973b592d6b48278c23d That's a good news. Anyway, I'm considering removing company-clang by default (and some other backends as well) after some upcoming release of company. To do that, and to avoid confusing some of the users, I'd have to create some instructions on what C/C++ developers should use and in what cases. If you have free time for some documentation writing, help welcome. >> 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. > > What are you saying: major modes in the core _can't_. What would they use in it? > And just because it was successful in GNU ELPA doesn't me it can't > be _more_ successful if developed in the core. Below you say major > modes in the core aren't maintained: well, maybe _because_ they > can't tap into resources like Yasnippet. Um, that's unlikely to play a big role. >> 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. > > One part can be developed in GNU ELPA, the other in the core. BOTH > parts can be downloadable from GNU ELPA, nothing against that. If there is something existing code in Emacs can tap into in the "new part", I don't have anything against that. >> 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. > > The lack of maintainers is not an argument for changing the place > where these things are maintained. That's not magically going to > bring more maintainers. As far as Yasnippet is concerned, I'm not arguing to change things. You are. I'm arguing the current situation is pretty good, and not without reasons. >> And even if they do the new snippets will only reach the users once >> every 2 years. (facepalm emoji) > > No. You keep saying this, but if the major-mode is GNU ELPA :core > it's no problem. Okay then, we'll go ahead and make everything into GNU ELPA packages. And /my plan/ will be two steps closer to fruition. *evil laugh* >> Right. So CC Mode will define which completion server will be used by >> Eglot? Really? > > Yes, supposing Alan wants to provide LSP features, yes. Eli has said > we wants features in CC mode that LSP is capable of supporting. Could you please avoid referring to general statements by Eli until you actually discuss some particulars? "Let's provide features we can provide" as as sensible as it is noncommittal. > If Alan doesn't want to, then we'll make another C mode, *insert another kind of laugh here* > maybe > resorting to LSP only or to TreeSitter or a mix of both. Or Alan > can come around. Or make it opt-in. Lots of options here. Yes, there are many ways to try to skin this particular feline. Some of them more optimal than others. >> 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. > > Again, this fictional tragedy ignore the advent of :core GNU ELPA > packages. If we add every [important or fast-moving] core package to GNU ELPA, that could solve some problems indeed. Mainly leaving organizational issues, like increasing the diffs mailing list traffic, the bug tracker load, and so on, the more packages we take in. And increasing the core's risks and commitments in unfortunate cases where the original authors leave. >>> 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. > > Unless I missed something, you never asked. Stefan asked off-list, and > I gave him examples. I asked, last time you mentioned this. > Anyway, see eglot.el. It has some, though I've been quite conservative, > again, precisely _because_ that code doesn't belong in eglot.el. Could you mention some symbol to search for, at least? > So you're describing the chicken and the egg. Or look at the very large > amount of mode-specific code that lsp-mode.el. It also doesn't belong > there. That could be true. But if the Eglot team are best-positioned to write that code, and to maintain it, you'll be the ones to do it anyway. Then why split it across files, move it to major modes, etc? Furthermore, if some necessary setup will be performed in CC Mode, then alternative C modes, if they ever appear, will harder time making use of it. I'm not sure if we'll have this particular problem, but alternative major modes have been created for other languages. Rust, for instance. > And do I really have to download clangd and xcode-specific code > to my machine. This pertaining to..? >>> 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? > > But it can be developed in the core and be downloaded from > GNU ELPA, as I keep saying. The two things are completely > unrelated, thankfully. I'm just saying it's not an argument in favor of either of the options. >> 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. > > This is the classic monolithic vs modular debate. Emacs is mostly > monolithic, so unless it goes full modular, you're seriously > handicapping development of some stuff by demanding it sit > outside the core. In theory, your statement makes sense. But I don't see any solid examples so far, as pertaining to packages under discussion. And only by considering examples in detail we can derive good rules. > Both approaches are defensible, of course. > But a mixed approach will tend to limp. This, however, is something good-sounding, but just as likely wrong as it is right. We could use some principles, however. Yes, I want Emacs to be modular, and I'm not the only one. But the degree of modularity, and the division lines, all should be driven by practical considerations. Do you like the current monolith? Are you sure the current architecture is good, and gives appropriate incentives to the authors? Do you like message-mode (as essential feature) still being a part of Gnus, a big specialized application, after all these years, and depending on its other code? Do you like that Org is just its own microcosm, and basically never extracts features? Do you like all the references to tramp- functions outside of its implementation? I don't want to criticize anyone in particular (we're all volunteers here), but some clearer distinction between infrastructure and applications could do good. > Again, distribution and where the source code is kept is now mostly > orthogonal, thanks to :core packages. The distribution is the thing > that's preventing the "discoverability" the supposed subject of > this debate. Development is a different reality: we shouldn't > have distribution concerns hamper it. Eli asked why we never followed up on our "promises" to consider some packages for the core which we put into GNU ELPA. I explained that those packages likely didn't need that anyway. This is where this line of discussion came from.