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: Tue, 19 May 2020 21:56:45 +0100 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" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="2495"; mail-complaints-to="usenet@ciao.gmane.io" 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 Tue May 19 22:57:41 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 1jb9Ix-0000Va-Mn for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 22:57:39 +0200 Original-Received: from localhost ([::1]:40626 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb9Iw-0004pc-Lo for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 16:57:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jb9IM-0004O2-OV for Emacs-devel@gnu.org; Tue, 19 May 2020 16:57:02 -0400 Original-Received: from mail-il1-x143.google.com ([2607:f8b0:4864:20::143]:33204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jb9IK-0008Jh-E9; Tue, 19 May 2020 16:57:02 -0400 Original-Received: by mail-il1-x143.google.com with SMTP id o67so901524ila.0; Tue, 19 May 2020 13:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pFDOSq5MrOZbOiDo2p8F3+RdJgXR5hx8qoQj9JIIxP4=; b=U6ZeAWj8UOmT4mwlBSYfaA0NKIpf8DXsUOa8CnN3kTpUObR9DciONvHmheKn91InzJ FAwEbrg3lzChaZhFjWFUWqaxHpXxNFXX7sc8FUwtyhCMQ5oUekT/ioABECnZg5wScXqy B+V5LGgNeoqLaw2Q5aaOhJ17DCk3X+HtYLip9k7Ib5bzcRK6wRFtTtoTDRfy2rIaXcSS dkc/X2xJoKQRk/AcE28SgaxKYEibrQ9ydeFF/dvsohNstVpkF/cgqou+XayucQEaOJBt TI1SqLcrVlZATSCbmuv5L7ZVqRmCPXzmLA9qDX9aOA1pNaq4A9ZL428WiWF7NTh57FP1 9QtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pFDOSq5MrOZbOiDo2p8F3+RdJgXR5hx8qoQj9JIIxP4=; b=JhIwX7eMMHw7fXKfUWgWg3bn5lQa5y47wbHAVWi9BdPudzUhZEV6L0qNP+9EwaE2sg 9N6SjZpPS9n3Y/mZV3XGnLdLoFg1EToKp/brhjkkioXn53GFz+aZoLdmW4qfiicmjowd Led0ge/+ECm2cp9e0Tko2SLmrfPTWqAorgXQUnRk0y6uzRwC/1SYWNN6/4HnjSsUMJOT yR5/3wYuQ25wrufQILisvS5gHy91GdNMNogAdukew04ZfkYDzOXNaWKa79cqUvl8J90w p08GJ0LLfh9QspgFfbyrhffg2cEaXFfiS221CiVU0UJCCqT1IrvbESvfrHwKjC1K/emM v1wg== X-Gm-Message-State: AOAM531D9Cp2xX/4UvbUpg5valJYFokV6XZmIpKBH2an454CzuvDxg1D 2k9Vzy2IPBQ6+6rZE6H3N172HWTcU9Mwmp7Hg8c= X-Google-Smtp-Source: ABdhPJw9D2eX/C1+N62mEp6clINOmz1H31ITWGVKhDqkl5R6eJnbM3jimjja1I1u4scRPyktw1MND0uKX9klEMVkCFE= X-Received: by 2002:a92:1b17:: with SMTP id b23mr919164ilb.199.1589921817968; Tue, 19 May 2020 13:56:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::143; envelope-from=joaotavora@gmail.com; helo=mail-il1-x143.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:250982 Archived-At: On Tue, May 19, 2020 at 8:38 PM Dmitry Gutov wrote: > > "**company-clang is enabled by default**, and will interfere with clang= d. > > 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). > > 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 :-) > 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. Or just create those things as packages that depend on `company-nocruft` (Yes I know "nocruft" is a cheeky name, just to make a point. Call it what you with, `company-base`. Eglot would depend on that) > If you have free time for some documentation writing, help welcome. No thank you, but I _will_ help you split it into packages. > >> 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. > > 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. 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". > > 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 a= re. I thought you were talking about major-modes, which Yasnippet is not. Yasnippet would presumably maintain its one-man maintainership, Noam, for which I am very grateful. It's Noam's call if Yasnippet stays in GitH= ub, mind you. But it's my call to propose snippet.el to the core, and I can't imagine Noam saying no to offloading a big part of the snippet expansion and navigation engine to another much cleaner package. > 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? > 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. > > 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. There's already another C mode in ELPA, I think. No C++ mode though, that's much harder to parse (and _that's_ why we should offload this work). > > 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. Yes. Important or fast-moving sounds good. > 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. I told you I was not going to discuss these things ;-) And you agreed, so don't mix up the discussions. > > 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. 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. > > So you're describing the chicken and the egg. Or look at the very larg= e > > 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. 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++. > > 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. > > 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 > 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? And this is precisely where the problem is. My answer to this question is irrelevant, because I'm a very small part in the development of Emacs, due to multiple reasons. Skills, time available, etc. So I try to work in a way that doesn't actively preempt future migrations to other architectures, but I don't refrain from working inside the current architecture because I'm not conceptually satisfied with what it could be if I could magically convince everyone to think like me and spend an almost unlimited about of collective brain power. These is my rule-of-thumb: scratch my itch. If possible scratch other's, and do it in a way that doesn't induce new itches to others still. > 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. Look in your backyard :-) extract that company-clang to a separate package :-) > 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. Sorry, I might have missed some posts in this particular line Jo=C3=A3o PS: this discussion is getting looong.