From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: xenodasein--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Adding use-package to core Date: Tue, 15 Nov 2022 16:38:10 +0100 (CET) Message-ID: References: <87fsemjs7v.fsf@yahoo.com> <87edu5izi9.fsf@yahoo.com> <83cz9pk5fb.fsf@gnu.org> <83a64tjuz8.fsf@gnu.org> Reply-To: xenodasein@tutanota.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25349"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 16:58:30 2022 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 1ouyKR-0006Gm-Jw for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 16:58:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouy0x-0008BK-NA; Tue, 15 Nov 2022 10:38:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouy0w-00087R-54 for emacs-devel@gnu.org; Tue, 15 Nov 2022 10:38:18 -0500 Original-Received: from w4.tutanota.de ([81.3.6.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouy0t-0000Vq-Nb; Tue, 15 Nov 2022 10:38:17 -0500 Original-Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id F416410602E1; Tue, 15 Nov 2022 15:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1668526690; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=RTMo8WA9oNQsVFgzQ9FUIqF5YSW6Msg04hOAQlobdmI=; b=1EB6KBbjjvwmk/CHZeSUcC9wMHwkrS2F81Ws2r96wfOI8tKe7ZRTMbeTgXjGu73W WqSAc1mMlJ4G6oBrgMe3X+dYNphMhVaNOOcroh4OzmQmTkCuP4x8BqWjc0JrKU/HwKc 0n31Hi902xFaQOwhPhlpGnpCjRiIN3Qs12oDDDaQuQ6hdLTCRqA4G299E3xmEIGOrla 4IIf5deOeEuUZkID/OGreCu/Ch3PZyXMlPrJ1nC6AAOqD39rD79yYpVPeO6LVjithFW WhH1kGPkBlJwpsnxVxeu+igKLwAFNzYOXNWcUEBMVS8LeBxbJmBvmrhlwZtS+GU6LSK tbBBzOToAw== In-Reply-To: <83a64tjuz8.fsf@gnu.org> Received-SPF: pass client-ip=81.3.6.165; envelope-from=xenodasein@tutanota.de; helo=w4.tutanota.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299854 Archived-At: This is a real answer, I thank you for it.=C2=A0 FWIW, no one can claim that you are not meticulous in your community management.=C2=A0 It is a tiresome and hard task rarely done well. Nov 14, 2022, 17:39 by eliz@gnu.org: >> Experience in accomplishing what exactly?=C2=A0 How can I examine this >> evidence?=C2=A0 I don't know what are your goals, is going down from 5% >> percent to 4% on StackOverflow's survey this year is one of them? >> > > The overall goal is, and always has been, to make Emacs more powerful, > more capable of supporting text-editing and text-processing > applications in more and more areas where people need such > capabilities and applications. Examine the NEWS files over the last > 20 years and ask yourself if that is not happening with every new > major release. > > As for the evidence, it's right before your eyes: show me another > similar platform that lived for so many years, and after all these > years still gets developed at the same, if not higher, rate. What > other evidence do you need? 5000 commits each year for the past 20 > years cannot just come from a small band of like-thinking weirdos who > are detached from their users. > >> I really want to see this story of success, but wherever I look >> that has numbers tells that you can't compare numbers even with >> Notepad++. >> > > We develop Emacs for those who want and need to use it. What matters > to us is not the percentage of our users between editors and IDEs, > what matters is where our users want us to advance, and which new > technologies will allow us to provide them with new and improved > capabilities, infrastructure, and applications. > The problem is, more capable and powerful _compared to what?_ Comparing yourself against only yourself of yesterday is a great maxim to have, in line with an ideal world and FSF ideals.=C2=A0 The reality is that almost everyone using a different editor/ide do not actually hate Emacs and would use it instead of Electron bloatware _if_ it solved their problems faster, which it does, seen from how things are and my experience is also supportive of this.=C2=A0 We are a practical species if nothing else. I use Emacs because I like it, not because it actually solves some programming problems faster.=C2=A0 I am aware how it actually does many things better after investment and when programming is your lifestyle, but for most it is only a task.=C2=A0 Note that having to invest is not an advantage or accomplishment, other programmable editors come very close to Emacs if you program the hell out of them too. >From this perspective Emacs doesn't accomplish to actually be the better editor overall, if we compare ourselves to others.=C2=A0 For example Vim's advantages in quick remote editing or availability.=C2=A0 That availability is also an accomplishment over Emacs, despite it being the GNU editor.=C2=A0 I agree popularity is not always a great thing to have and most times does not bring good things to its way.=C2=A0 Ideally Emacs would be both demonstrably better yet still niche and we could revel in our l33t productivity, without others rushing in to have some :). >> I find it hard to understand how leaving whoever comes after you an >> even bigger Emacs despite having said currently no one understands >> all parts of it. >> > > No matter how small we make Emacs, no one will ever be able to > understand all of it. It spans and uses too many too wide areas of > computer processing technologies for any single person to be able to > understand it. Apart of the "usual" CS stuff, we have Unicode and > character properties, GUI and TTY display, text shaping, font > selection, image processing and display, Lisp and its compilation, > file I/O, regular expressions, and that's just a sample. Who could > possible be an expert in all of that? > > So this is a red herring. > Is it though?=C2=A0 Vim's Bram Moolenaar seems to manage it, not to mention how GNU Emacs came to be; there are many more impressive software out there with this singular dedicated developer.=C2=A0 Aiming for a single person is indeed too bold, reducing this number to a few on the other hand almost feels like a low hanging fruit.=C2=A0 Not every contributor has to be in the top echelon of course, my impression is that you underestimate the benefits a less complex project will bring and instead decide it better for the users when there is more stuff all together.=C2=A0 (I believe it is a correct assumption given you make it in a time what Internet is not as ubiquitous as today.=C2=A0 Even then there could be bigger alternative distributions that include optional packages, mainly for less lucky parts of the Earth.) > As for "even bigger Emacs" part -- if you really believe Emacs can be > divided into core and the rest, I think you don't understand the > spirit and the heart of Emacs and its development. (Which I can > totally feel for, since it takes a lot of time and personal > involvement to really grasp that.) See, separating the Emacs core > from applications built on that core makes no sense, and if you try, > you will most probably kill Emacs. If you examine carefully every > significant development in the Emacs core, you will see that each and > every one of them was always about some application or class of > applications. Take the recent addition of tree-sitter, for example: > it would make no sense to develop that if font-lock for many > programming languages was not in core, because who in their right mind > would do all that hard work if it couldn't be immediately applied to > existing applications that are part of Emacs, and do it Right, using > all the expertise of "doing it Right" we have on board? > > You should arrive at the same conclusion if you examine carefully > "core" Lisp packages, like subr.el, simple.el, etc. -- every single > part of them is there because we needed it for some application in > Emacs itself. How could that happen if the applications were outside > of Emacs? It is a fact that developers of 3rd-party applications tend > to solve the problem by themselves, almost never asking us to provide > new core features to help them solve those problems. If most of Emacs > applications were outside the project, we could never have progressed > and extended our basic capabilities and infrastructure as we have them > now. > I actually agree on this mostly, what I try to suggest is to narrowing the scope of these applications, which must be maintained by emacs-devel.=C2=A0 Bidirectional editing, advanced support for programming languages etc. these are all great and must have features.=C2=A0 If something isn't needed by almost every programmer or writer, package it; this seems like a good rule of thumb? (I guess from the timing I sounded like I am strongly against inclusion of use-package, but this is not the case, this was more of a general complaint.=C2=A0 I am somewhat against use-package because I think it is a band-aid over the shortcomings of existing customization facilities, but maybe Emacs should turn towards use-package style customization I don't know.) > This intimate bond between the internals and the core infrastructure > on the one hand, and the applications that are built on top of that > OTOH -- this is our main strength, it's what keeps drawing in new core > developers over the years, thus keeping the project alive and kicking, > and developing at a mind-blowing rate. > > And yes, this presents a problem: where do we draw the line, how do we > avoid making Emacs "too big" by adding "everything"? Well, that's > what takes experience and intuition and gut feeling -- and a lot of > arguments like this one. But by and large, we succeed, as the state > of Emacs today should tell us. > > Whatever the difficulties to make the decision in each case, the > opinion that we should generally go in the opposite direction, > i.e. progressively remove more and more application-level code from > Emacs -- that opinion is completely wrong. IMNSHO, anyway. > I do not understand what live-ness or dead-ness mean for Emacs' case, as long as FSF and its support lives.=C2=A0 Because no matter what a lot of people including me will keep using it because of its aesthetics, community, the way it works etc.=C2=A0 This is indeed a great accomplishment by itself, it is nightmarish to imagine where Emacs was not an existing (viable) alternative. My overall argument here is to demonstrates why I think emacs-devel's methods are not as effective as they think, and should be more open to different approaches.=C2=A0 Being in this state of being immortal (or arguably already dead) gives you unique opportunities to be more experimental I think. IIUC the vision is having as many features (that mostly work) as possible, instead of few superb ones.=C2=A0 Doing the opposite granted Vim "the editor wars," giving an order of magnitude larger user base and widespread availability.