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: Wed, 20 May 2020 01:59:52 +0100 Message-ID: <87k1175sl3.fsf@gmail.com> 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> 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="105585"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) 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 Wed May 20 03:00: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 1jbD68-000RN1-Ux for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 03:00:41 +0200 Original-Received: from localhost ([::1]:39012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbD67-0005HJ-VH for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 21:00:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58974) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbD5U-0004cW-PP for Emacs-devel@gnu.org; Tue, 19 May 2020 21:00:00 -0400 Original-Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:55828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbD5T-0008AP-Im; Tue, 19 May 2020 21:00:00 -0400 Original-Received: by mail-wm1-x344.google.com with SMTP id f13so1003150wmc.5; Tue, 19 May 2020 17:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=KwQz9LG2YauOJO/zeILsaf9HLsPwn9gpYG1+jnAzQPw=; b=KEWhnhCavMPFZxmPqC+dxABhdtMOFwqPRm1EKDxyrSU0W6EW0ndgIytotAsgwHdXgD feoVTB/iewDDozgyWVLYc1uZhovHhvAZZBdYmnDcFQv7Zun75EJCcYwNhYoue7RCzsr9 kslFq0ars2qOtdbFEGc5dWkHR280GLyt9bohTzI3c+hHq23Suh9G0FM8X9sDc5DwptOz 6a6qf07p3sMxgc/epGjMrCzyyTAKIiXVGs7gdfCmXuZOSeMKLVNHHUZ8G1/sRNSqCcJa j0hrPeM6vYhEZRNOGxkzhgYkebmqRYlEk0sJdgQ2s9sofxNg30i5nbwN8qWLH9KeCzts kP/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=KwQz9LG2YauOJO/zeILsaf9HLsPwn9gpYG1+jnAzQPw=; b=LDJDL1xh+nvtcpCPKz3V7eEjlMXU1DalUNpHoQlWNOUbY5b5dhAhVNQ/u4jhiI/HBf 1vKv1d25z4FfscOGPlcAq+Ypt1RB2pfo/9kDB1MylMn07JwtvESAyflnjO4wNe+ChCR3 cvYDp9VdK6sdPviu1L51UCoW3p0nZclFo5cEAdWCRFpSq36kYB3w3ZnFQu4quj9HZdtv 5r94K/edEPumA9DclH/boTNOQvbJwvn5AGby1khCd3wxiQkKyEqNvz8CHC/V02wEJzNG N48NBsTdTgV31h6UVO8GlIH6eziSsKzVUGE1sPC75B0KQW3DB8jTxQvYV/KfYCFX6J9R Fwcw== X-Gm-Message-State: AOAM533OOWinRPeTn38RSEaMrLhpbP7C8qfqjNDKYCBUBYFwXbkezn5F s+hkEsvT+HAQlgnMtsA/ifVn2niuj5xh2w== X-Google-Smtp-Source: ABdhPJyXzGiaSK0zFyW3UizP10tCoEsPCn+JkOlVp+7+reRGDDav8mS+R60/soy6ZpfrlbunijE2Kg== X-Received: by 2002:a1c:545b:: with SMTP id p27mr1952944wmi.81.1589936396635; Tue, 19 May 2020 17:59:56 -0700 (PDT) Original-Received: from krug ([89.180.150.4]) by smtp.gmail.com with ESMTPSA id l9sm76769wrv.32.2020.05.19.17.59.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 17:59:55 -0700 (PDT) In-Reply-To: <93a7bb1c-390f-440f-02cc-6cce39ea9431@yandex.ru> (Dmitry Gutov's message of "Wed, 20 May 2020 03:09:59 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::344; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x344.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:250995 Archived-At: Dmitry Gutov writes: > 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. 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. > 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. > For example, "solitude". Interesting, but doesn't really sell, does it? I prefer "freelance" or "proletarian". >> 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. Also, there's a very good thing in Emacs called `define-derived-mode`. And lots of other options. > 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. > 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 :-) > 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. But there is TreeSitter. And LSP. And probably more parser solutions. Even Semantic has a parser generator which I dont' think has been sufficiently explored. Anyway, C++ is just one language among many. > From what I see it there, someone could/should make an RLS-specific > plugin for Eglot. No, that's not my view at all. That's precisely what I don't like about lsp-mode. > Not sure how major modes would help. There are several language > servers for Rust, after all. So the major mode chooses the best one. Or it can even decide on a preference order between multiple servers. Up to the author/maintainers. >> 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 specificatio= n. =C2=AF\_(=E3=83=84)_/=C2=AF >> 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. Actually CEDET is, but noone knows how that works. >> 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! >>>> 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. 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. > 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. > 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) >> PS: this discussion is getting looong. > Yup. Yup, yup, trying to wrap up.