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 18:28:43 +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="120973"; 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 19:29:51 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 1jb63r-000VMn-Fa for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 19:29:51 +0200 Original-Received: from localhost ([::1]:42308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb63q-0001Mu-Iv for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 13:29:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jb635-0008S2-IS for Emacs-devel@gnu.org; Tue, 19 May 2020 13:29:03 -0400 Original-Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]:33079) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jb633-0006Ca-DR; Tue, 19 May 2020 13:29:03 -0400 Original-Received: by mail-io1-xd31.google.com with SMTP id k18so39501ion.0; Tue, 19 May 2020 10:28: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=Papzv1nk84v+B5fESIVXiUGUV9kMZmNWfNfCeaNJO7A=; b=IZf02ONVjxj7rz6oE6XUwR8cBYWn7yEsBqHni7k9Yw0RygcJa+O0PoMvz9UMANY9vV Yi9pfjQXnPqogzgyx7BuCraJk+ojtty0zRIjPrFmcFKnExwenZNxnAwLEg0Rgd/IvA3a h+EbQ9mhYnLmJoRyjosKzjXWRKm+GvI9IgZOoe15tIvXKl2243AzFJ9iML2WaNXlJ14k ASe1w8zq7OPsO7dpdhK541JHv30JHcfCMYF4DBYIQ1mxPB6FdTzU3Llywr4Nyo/ejQJL xuqUczLrVJq+iiFPOCDDdbyhoRJkGk/f8EFJs9bKZvIxetXbtTf0ky/UZ65fGayZNteq svSQ== 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=Papzv1nk84v+B5fESIVXiUGUV9kMZmNWfNfCeaNJO7A=; b=KYYocEe+aKqevcfszlLSn5qqEpXGH+zEMjfqSRcwsX4DCSQP4dptg1BKDwGMAhzZEW nQqBEJj9x/T9p79W+C/BAVHd4AFFnuozZIQM+YYs3if6vYTHuE66S0q+xJs9/khGwCyh Y2eBwc7RJIE/XSTTQUHFTH9elJr3dnVDBe5Nwuu4vkN1rxmco/figWqtux4cPq/uuxhD yjXFvRYn0d0yZvVUyVDDSeSxxVbQJeDf2Bd6oH4n94jcNpc/QRRFRqSEVPoAGI59W33Z 4el33pef4tiQB3TGYEPUgzpy3abUs+y662Fl23KBFQzK1bRhEIfiFCJ6T0/04047wKpr N0zg== X-Gm-Message-State: AOAM531gdbmFoHowYpBalHZ62LuFfb5Kp3DhnYsPNVM0BepjTfWcb/hd BWeRAjo56IIYhP2MEzk5IlZAUTrsfOCzJBL037A= X-Google-Smtp-Source: ABdhPJwbBwpKBjOMKX/x2wYkqEaaGXk+IRjTRp+2JdKNYz1oBQHGAeHcMhum3KqdQ8hMYBsIgKFxE3ArNvD04XpsDxU= X-Received: by 2002:a6b:e006:: with SMTP id z6mr18431iog.138.1589909337147; Tue, 19 May 2020 10:28:57 -0700 (PDT) In-Reply-To: <96bf0b6e-3559-ed02-5596-6a6642188309@yandex.ru> Received-SPF: pass client-ip=2607:f8b0:4864:20::d31; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd31.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:250969 Archived-At: On Tue, May 19, 2020 at 3:59 PM Dmitry Gutov 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 completi= on tooltip in the core, much like icomplete, one that gets to integrate with other pieces in the core. > 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 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? Anyway, after my fix, I've finally got them to update the webpage: https://github.com/llvm/clangd-www/pull/1/commits/a328d8e92eb05b8e62cd0973b= 592d6b48278c23d > 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_. 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. > 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 wel= l. One part can be developed in GNU ELPA, the other in the core. BOTH parts can be downloadable from GNU ELPA, nothing 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. > 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. > 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. If Alan doesn't want to, then we'll make another C mode, 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. > 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. > > 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. Anyway, see eglot.el. It has some, though I've been quite conservative, again, precisely _because_ that code doesn't belong in eglot.el. 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. And do I really have to download clangd and xcode-specific code to my machine. > > 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'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. Both approaches are defensible, of course. But a mixed approach will tend to limp. 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. Jo=C3=A3o