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 04:17:44 +0300 Message-ID: <2a43cea0-8e00-3c22-3ddc-eff29fc9b2db@yandex.ru> References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <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> 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="46879"; 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 03:18:21 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 1jbDNF-000C6Y-7F for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 03:18:21 +0200 Original-Received: from localhost ([::1]:48312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbDNE-00040r-6l for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 21:18:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbDMl-0003bc-HB for Emacs-devel@gnu.org; Tue, 19 May 2020 21:17:51 -0400 Original-Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]:51735) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbDMk-0003SP-9L; Tue, 19 May 2020 21:17:51 -0400 Original-Received: by mail-wm1-x342.google.com with SMTP id f134so1048408wmf.1; Tue, 19 May 2020 18:17:48 -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=E9lLdNLBjoZ2Gu+0M5xOKN8Sb7L8Ph4yFubgZVbQgO0=; b=hNW75JP5ZfzPKdukERwmwZutGQPyJaP6M5RLQ5nGleL8Tue6abkl2efi+jFCmC69H1 UNr5wo2+r/lvx92zTd3o4tOFrPckPdR9bxiqIyyeFP+dzebkIQrvVBi5vWTehbW5Jovi 2rsQrsIiUYtp1aNZfKXtD9mebx1VQ24rFPlIWQoWtgASlHpZw7S4SUA4TBwlBO0CPZ+5 mLclcJX0ZZon473dURSxIAdnZvtEtUqcaLdBEW1wU+DJtKj+HlNVXpQayTRHpveo8b+U RewRbqfrQTD+YStHUXvLMfsG/eWq1FmGnMspNLbJYzlsStsLXg0djsmF/ivf8MLQNmBd kUrA== 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=E9lLdNLBjoZ2Gu+0M5xOKN8Sb7L8Ph4yFubgZVbQgO0=; b=X9VQzO+/fcwvK1WeLTwFxI/en0iNiDVoY1KdNspowhutg44mDgdv7wsXUiRiTTFg6h R37W+2Tcb4SxKUO+Sd1ElOgckjuevW1NUjKVC/MDauwr36v8ZV1bJnvdOP4KU22ny4NU 66PeRdgdbHQdGKPpRUvYBN6xGhgDfeSU62YXnSzcfxT8PoEUlOOaloGFSbJikUZPTljg tYsrTXcZDQC0WJgV4yFTCLIhGxjwwt/48iU61duJhAu5CuGJx2v/HDVgp+KjnYm/cK6z Wok3d4MyPSrITS6101SnB4aLJMIlZYf3q95NciQMs3DroxCf5fCiC4lMIL8w5e/JSc2C aA/Q== X-Gm-Message-State: AOAM531Ao+hYKIbHsGPz7B62+TCaUPV9iBpt3ZF9YCBW5v+SKoyIJWrB Zz2DHU75wZA37VwebUjWVAUx463T X-Google-Smtp-Source: ABdhPJyKm8Xnyj6pgWifL9diH2u/mLZz2ldmWXpB9kcSvXJKmCuZYs9A1+JWZRrRtbwoEan6omj2CA== X-Received: by 2002:a1c:2dc7:: with SMTP id t190mr1964353wmt.129.1589937467266; Tue, 19 May 2020 18:17:47 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id v126sm1718401wma.9.2020.05.19.18.17.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2020 18:17:46 -0700 (PDT) In-Reply-To: <87k1175sl3.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::342; envelope-from=raaahh@gmail.com; helo=mail-wm1-x342.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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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 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:250998 Archived-At: On 20.05.2020 03:59, João Távora wrote: > You're not following my idea. I'm saying: > > - make a company-base package that includes the basic company stuff like > the nice tooltip code and what is now company-capf. (Maybe also move > that to the core, why not? :-)) Eglot would depend on just this. > > - Make a company-clang, company-xcode, company-foo for users that want > to use these things. > > Then I would remove Eglot's overriding of company-backends, making you > happy in return. If a user _also_ has company-clang installed and it > conflicts with company-capf, it's his problem, not Eglot's. Again, note that none of this is predicated, or really affected, by company simply being in the core. >> If it behaves sufficiently differently from company (as I recall you >> were planning), you might want to pick a different name. > > _That_ idea was a rewrite, something I've done in the past when I > haven't been able to convince the owner of the thing I want integrated. You might have more luck after following certain requests by the said owner. >> For example, "solitude". > > Interesting, but doesn't really sell, does it? I prefer "freelance" > or "proletarian". Proletarian sounds the best. Very solid and people-power'd. >>> 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. :-) > > Major mode mantainers are all of us. So you'll move information around but continue to keep it all up-to-date yourself, together with other Eglot developers? >> 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. > > Again, major mode maintainers are all of us. I don't view code that > someone else authored as off-limits. If there is a difference of > opinion, we bring it here and the matter usually resolved in the > interest of both parties. If the major mode authors simply don't want > to have snippets or LSP or Flymake or treesitter-vapourware.el support, > then there's nothing we can do except making an alternate major mode. I'm not even talking about people rejecting such changes. Only about that someone would need to make them, and to maintain them thereafter. >> Not everybody might agree, though. You might notice that there's still >> no cc-mode package in there. > > I detect a hint of obsession with cc-mode. Not good, not good :-) Just a friendly warning, from a fellow revolutionary to another. >>> 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. > > It tells me those major modes don't have access to the tools that > provide code navigation, because they're not in the core. Or that the tooling is decoupled from the major mode definition. > Actually > CEDET is, but noone knows how that works. There is one Indian guy who keeps posting videos of new improvements he made, but for some reason isn't hurrying to upstream the changes. >>> 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. > > With a meme-laden Medium account, and lots of fanboys, come on! That has > to count! Then he speaks for all of us, naturally. >> 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. > > Sorry, not clangd, I meant clang. I mean I _certainly_ don't have xcode > but I have a file called company-xcode.el because i installed Company > with code that I suppose is for xcode. Not only that company-xcode is > in the default value of company-backends. Yeah, that one will also have to go. >> 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? > > Eglot contains much of the code that would make it possible to rewrite > Flyspell to rely on LSP, even if as an alternative. I don't recall: if Flyspell extensible? Like Flymake, for instance. If it is, this seems to call for an eglot-flyspell plugin. >> 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. > > If Org is somehow a library helpful to other things in the core, > no. Otherwise yes, if indeed it is not developed here (in emacs.git) At least we're somewhat compatible on the basics.