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: Wed, 20 May 2020 03:09:59 +0300 Message-ID: <93a7bb1c-390f-440f-02cc-6cce39ea9431@yandex.ru> 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="33132"; 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 Wed May 20 02:10: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 1jbCJm-0008TS-4V for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 02:10:42 +0200 Original-Received: from localhost ([::1]:49202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbCJl-0004cl-5z for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 20:10:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55054) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbCJD-00043y-5z for Emacs-devel@gnu.org; Tue, 19 May 2020 20:10:07 -0400 Original-Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]:40646) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbCJB-0006vX-Ky; Tue, 19 May 2020 20:10:06 -0400 Original-Received: by mail-wm1-x341.google.com with SMTP id n18so1068783wmj.5; Tue, 19 May 2020 17:10:03 -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=oVgbk2L1IcNElUjIC8MOZZ6fPg7pRaacnVlQR6hLEnE=; b=Ry0WgUOTvET1srYYqLdXZYTJ6x3MxGdvRHSArdw94s8S6DUwSPMfT4yKC45+eWTNq4 lO665d+JuXoxHFXD2ZPsMqeZDfH5tWMIO6cbq3BtrHHmn30mhfLUz4r95d14KAYqnbnH VP4f10ScLkKPtwPGQF88M3Fxx+364N0DWmZ0CI67i8to6hjnqr0yGY1Y9h1rBzZZ3Dun mWZ/he39GIvsPQn6FprorovIyX8rW5cwv+QChZCTGYy3ePcS4J/MGGIUfx4dgNjmU66G yJ5uxY7f1FHMPTib/8i8r0jfr/nPXoaksVVzNzOXnHPNy8t9Nf8Ak1t8bJx5eHazVIBb L0PA== 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=oVgbk2L1IcNElUjIC8MOZZ6fPg7pRaacnVlQR6hLEnE=; b=npNCJ7TTYu09e7+g4FRUewj97jH7mkTi5Xr1c6D3o5ZdjFYM8LwGsAh9y7RMba7fng DatlpyZt+Og7TDg1WxZ0P0zuLhmYMw1VVn6HlWYJnd962Z2gLSd2/S5fE5i95GMvabap ejAq2LdSHZ3a+YJ9jSE/QPKiHDPXOGdT/jRYVYImXywHsMPtbsFO6NdMEknHMneDgpuw sdIFBDWlIvGtsK+Ui1j1PY1YdNTtSer/60UGf1H25lmbvwKfunWOsZjCnSkRturZTyB/ 00iBVqpZoBPZFO/JrSdQyZOwpPEd9fVrG3Vx+0qIr9QAsvacAVPBO45yxadiN9XsgdsE Ga3g== X-Gm-Message-State: AOAM533z1624riIc8v9mLwFsKbEgizS8Hwe2XRko3N0ZVl1DfkMHy7+n ZqRNk7IrWxUbAlPjK2jRM1kq8o+f X-Google-Smtp-Source: ABdhPJzInLarS49+zdFTBgO40bcFe8+CkMjhjh4BIwzUwIPE5kXWew3K2YyNQxHM1L5lBpaMIua9kQ== X-Received: by 2002:a1c:32c5:: with SMTP id y188mr2084917wmy.16.1589933401751; Tue, 19 May 2020 17:10:01 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 32sm1122428wrg.19.2020.05.19.17.09.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2020 17:10:00 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::341; envelope-from=raaahh@gmail.com; helo=mail-wm1-x341.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:250991 Archived-At: On 19.05.2020 23:56, João Távora wrote: >>> "**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. > > Maybe you misunderstood me. But that warning is exactly, ipsis verbis, > the reason I did what I had to do (override company-backends). I'm saying that simply moving company to the core won't solve that problem (it will still need to support existing features). I'm not sure how splitting out a "core" package would help if the "full" version depends on it, actually. Surely you are going to support the users of the "full" version as well? And they will have a longer list in `company-backends' by default. >>> 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. > > But you're the one arguing for all-out modular and mini-package stuff for > the others! Your Company has become a mini-Emacs :-) Nice reductio at absurdum. I never said every single file should be a separate package. A decent guideline, in the commercial world at least, is to split project into services along organizational lines (e.g. one team = one service, very roughly speaking). There's nobody else who's going to maintain company-clang but me. In other cases, I do recommend people create and maintain their own packages. You might want to count the number of dependents on MELPA. >> If you have free time for some documentation writing, help welcome. > > No thank you, but I _will_ help you split it into packages. If it behaves sufficiently differently from company (as I recall you were planning), you might want to pick a different name. For example, "solitude". >>>> 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? > > Hm? They would define snippets for the programming they support. > Snippets that are active by default once you activate the major mode. Or maybe they simply won't. You might want to create a separate thread here with a vote and count the major mode maintainers who are in. :-) >>> 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. > > Well, we wouldn't know, would we? A bit of history: I got seriously > interested in Yasnippet because of TextMate. At the time, I did some > Ruby and watched lots of screecasts, all had Textmate. Textmate had > all the things: syntax, snippets, commands, menus out of the box. I > even tried to do that stuff with Yasnippet only, there's still some heroic > (but working!) code that will take a Textmate "bundle" and put everything > it has in the Yasnippet menu. Good stuff. > Many years after that, I'm still trying to achieve the same, but by > integrating with existing code, instead of trying to cram > Textmate stuff into Emacs. I know you're going to say: "then > put the major mode in ELPA and you can have your bundle", and > I'll say "OK, but let's develop it in the core". I don't really mind the idea of putting snippet.el into the core. It sounds like a small, self-contained library, with limited scope. Perhaps some other core developers take interest, too. But I don't see moving snippet definitions to major modes as inherently "right" or beneficial, because putting a lot of functionality in one place is not particularly flexible thing to do, it's like a huge function that does everything: when you need another function (e.g. major mode) to reuse some part of it, the design breaks. I see your desire to offload some responsibility to major mode authors, and I can sympathize with that. But if the people on the other side don't pick it up (or pick it up but then forget), this won't work. Especially with eglot-server-programs. >> 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* > > An evil laugh straight from dependency hell, evil indeed :-) > > Now seriously: not everything, but the things that we think will be updated > often enough to benefit users between two major releases, sure, why not? Indeed, why not. Were I supposed to argue against this? :-) The more developers think about ELPA, and take care to bump version numbers in their files, etc, the more acceptable the idea of "let's jump move to packages will become". Not everybody might agree, though. You might notice that there's still no cc-mode package in there. >> 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. > > That's not what I wrote. > > Eli said that he wants CC mode to support syntax-highlighting > and indentation from other sources, such as TreeSitter or LSP. > LSP will soon support these things, along with many other things. I'll have to see this first. And how reliable it is, and how much of it depends on VS Code's internals, etc. And actual language server support. But I'm repeating myself, from another thread. >>> If Alan doesn't want to, then we'll make another C mode, >> *insert another kind of laugh here* > > Don't be silly. I'm not proposing we evict Alan. But Emacs is about > alternatives. It was more of a weak, exasperated laugh. We couldn't evict Alan even if we wanted: CC Mode is a beast, and C++ is difficult enough to support that there haven't been any real alternatives, I think, ever. sm-c-mode in GNU ELPA is a cute experiment that supports only a fraction of its features. Even for C, IIRC. >>> 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? > > OK. Rust and java stuff down the end of the file. But the bug tracker > is rife with hacks that people use to get it working in other languages: > I've been telling people to put them in their .emacs. But they belong in > the major mode really. > > See also https://github.com/joaotavora/eglot/issues/363, for example. From what I see it there, someone could/should make an RLS-specific plugin for Eglot. Not sure how major modes would help. There are several language servers for Rust, after all. > See also the `;;; API (WORK-IN-PROGRESS!)` section in eglot.el. Every > generic function that takes a server as an argument is a candidate > for major mode tweaking. Like generic functions. Suspicious on the idea of major mode specification. >>> 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? > > Why not? We do have your beautiful xref.el right? Again Lisp is not > Java hehe. > > Seriously, because that's where it belongs, at least the way that > major-modes have been though of throughout the aeons. If you want > to change that fundamental property, you are fighting Emacs, in my > opinion. I want to find a Python file and start working in the best > environment. The only major mode that integrates with xref is emacs-lisp-mode, AFAIK (ok, and a couple of derivatives of it). All other integrations are in minor modes. That could probably tell you something. > By the way this reminds me of a Medium thing I read this week > where one users was fed up with VsCode asking to install packages > for typing an Hello World in C++. One user indeed. >>> And do I really have to download clangd and xcode-specific code >>> to my machine. >> This pertaining to..? > > Company. Did I put it out of context? Sorry. I still don't understand what this is about. I don't have clangd or any xcode stuff on my machine, and I develop Company. >>> 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. > > It is if you want to rewrite or enhance flyspell, for example. > Exactly how I did flymake, a package that was injustly ridiculed > to the point that someone made a "Flymake done right", tsk tsk But you wouldn't rewrite Flyspell on rely on LSP only. It would still have to be extensible/flexible/open. So how would Eglot's presence help? >> Do you like that Org is just its own microcosm, and basically never >> extracts features? > > I think you know my answer to that. But again, irrelevant. Stuff > doesn't happen by the truckload. So you wouldn't even agree that it would make a lot of sense to move Org to ELPA? It's not even developed here. > PS: this discussion is getting looong. Yup.