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: Tue, 15 Nov 2022 21:22:51 +0200 Message-ID: <83v8ngggz8.fsf@gnu.org> References: <87fsemjs7v.fsf@yahoo.com> <87edu5izi9.fsf@yahoo.com> <83cz9pk5fb.fsf@gnu.org> <83a64tjuz8.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="3795"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 20:23:05 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 1ov1WS-0000iJ-SR for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 20:23:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ov1W4-0002Cr-1N; Tue, 15 Nov 2022 14:22:40 -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 1ov1W3-0002Cg-5l for emacs-devel@gnu.org; Tue, 15 Nov 2022 14:22:39 -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 1ov1W2-00075k-TU; Tue, 15 Nov 2022 14:22:38 -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=FzUuIs1YgLuEvihHLCv1TfeT6EPqo5GwFcp98aO4308=; b=VAOu1P/jloJ0pRRUnOMq aBfWeLeCxHXTrfEkBhKTBBefMXgK4GKJbtFAl/hh0R+/qsBuDUQeZfhbJSflEjWLOuHwLCiMCm2Cw VJRghMrrGmsWOGhOkyUXTzyCrpkt7doNCyxQRXaeoNKmctUIBsczy12KNBHOxARwPEkPxHN4Xg2+R aJI6y0JG4p7oHGChLhec4ElkyZC80pxcomrw7p0iIi+25G3IYfbk3bpad1BCs8PPm/im9Odoya2bY NtvyA6j+tSQ4L+EW0O3nf6PDrDy1FgSRXNawUG7wtiloMawKF8a+hKVE4SGs0F6HPFluGSQsUdgoH rpycMCEnIwcJwA==; 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 1ov1W2-0006og-C7; Tue, 15 Nov 2022 14:22:38 -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:299878 Archived-At: > Date: Tue, 15 Nov 2022 16:38:10 +0100 (CET) > From: xenodasein@tutanota.de > Cc: emacs-devel@gnu.org > > > 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?_ Compared to what we did yesterday and to what our users want or may want us to do tomorrow. For the latter, we keep tabs on other similar editors and on technological developments, and consider their use in Emacs. > I use Emacs because I like it, not because it actually solves some > programming problems faster.  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.  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. We develop Emacs for those who like it and want to use it, regardless of their reasons. Why people like Emacs and use it is not relevant to this discussion, because no matter what we do, we cannot change the basic facets and look-and-feel of Emacs and its usage. Whoever likes it, for whatever reasons, will keep liking it, and those who don't will only rarely change their minds. > > 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?  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. I don't know how Vim compares to Emacs from the technological POV, I don't have time to study Vim that thoroughly. Maybe Vim is less complex and implements fewer technologies by itself, maybe the Vim developer is much more talented and/or has more time than we do, maybe something else. One thing is sure: with Emacs, with the kind of core developers we get for the past 30 years, this didn't happen even once, and so I consider it impractical to hope that it can be done. And rational project management doesn't build on hopes for miracles. > 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. Once you have 2 or three people, it doesn't matter how many they are: you need to discuss changes that span more than one area (and almost all of them do), you need to be able to do forensics on code for which you have no experts on board, etc. This is where we are, and no reasonable downscaling will ever be able to change that. > my impression is that you underestimate the benefits a less complex > project will bring On what is that impression based? It goes without saying that a significantly smaller project could be easier to manage, but the important question is: how much smaller can we make Emacs before it ceases being Emacs? And my answer to that is "not much". Just review all the Lisp packages that currently see a lot of commits, and you will arrive at the same conclusion: they are all important. (Packages that don't see changes aren't contributing to difficulties in maintenance.) > 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. It cannot be done. If you narrow the scope, you lose the motivation for development. More importantly, you will begin losing contributors, most of which are only interested in application levels, and that is the slippery slope to death, because contributors are the source of future Emacs developers and maintainers. > Bidirectional editing, advanced support for programming languages > etc. these are all great and must have features.  If something isn't > needed by almost every programmer or writer, package it; this seems > like a good rule of thumb? We already make decisions based on our gut feeling what is and what isn't important. So if you agree with that in general, what is left is differences in judgment calls, and those can never be usefully argued about, because they are basically subjective. And our experience is that the decision "what is needed by every programmer or writer" is very non-trivial. Emacs is so vast and people's interests and needs are so diverse that one person's main package in Emacs could be almost useless to someone else. E.g., there are people who will say that they use Emacs only because it has Org, and others who don't use Org at all, but cannot imagine their lives without VC or Tramp or Dired. > I do not understand what live-ness or dead-ness mean for Emacs' case, > as long as FSF and its support lives. Death means slowdown of development rate, stagnation, loss of users due to lack of maintenance, and then the project goes dark. Cf XEmacs. > 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.  Being in this state of being immortal (or > arguably already dead) gives you unique opportunities to be more > experimental I think. We do experiment, only somewhat cautiously. This isn't an educational student project; we have a lot of users who don't want us to make fatal mistakes. That's a huge responsibility. > IIUC the vision is having as many features (that mostly work) as > possible, instead of few superb ones. But that's not the vision. The vision is to have as many features we _need_to_have_in_core_ as possible. That's a tautological definition, of course, like every good definition is ("GNU's not Unix" and all that), which again brings us to the crucial point: it's a judgment call what to include and what not to include, which technology to adopt and which not. That's a very large portion of what Emacs maintenance is all about, day in and day out.