From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Adding use-package to core Date: Mon, 14 Nov 2022 19:39:55 +0200 Message-ID: <83a64tjuz8.fsf@gnu.org> References: <87fsemjs7v.fsf@yahoo.com> <87edu5izi9.fsf@yahoo.com> <83cz9pk5fb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14693"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 01:33:58 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 1oujtl-0003Ul-R6 for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 01:33:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouij6-0002qA-2Z; Mon, 14 Nov 2022 18:18:52 -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 1ouiea-0003B9-2v for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:14:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oudQv-0001RT-3C; Mon, 14 Nov 2022 12:39:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=RW06jZTOy39N1u84WJOB40I2G1uDWtFpXZcmElLaK6s=; b=aYk1m9fWyxtaaIaF2NCq E2xXgP4JCZ5+Wc+g3VrKPDGMjMf4+XYkll5BocyVGv76G6rANg4YbeZXzLlJbRVBdiEOX11B4hK/8 O5U6BGYIurViipFLejhxTp5ENFcwLUwZP5uB8OrFkfInCoXAgNt+sdGOeFHhqblK8eMU7RdxxsJmO J9266r79eX0DWeTzQxlm7sOvAETg6DSoDsd+gNiBXy0fJCU0vIlYOUp6bJvmkPulYwjwu6Li9jqqM FZ6sn503SWukaw8bKR+pxTtTT/GLtKWAsXCbXqczvsoiCH6PDQuihJ6nkdHcRq4rrP3JVT5Ce1ZGY ex8hOffiGzjN5Q==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oudQu-0001e5-J9; Mon, 14 Nov 2022 12:39:44 -0500 In-Reply-To: (xenodasein@tutanota.de) 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:299796 Archived-At: > Date: Mon, 14 Nov 2022 15:47:43 +0100 (CET) > From: xenodasein@tutanota.de > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > > > You are entitled to your opinions, but we disagree, and we have many > > years of experience to present as evidence. > > > > Given such stark differences of assumptions, opinions, and experience > > in Emacs development, I see no reason to keep arguing about this. > > Experience in accomplishing what exactly?  How can I examine this > evidence?  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. > 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. 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. 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.