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: Mon, 14 Nov 2022 12:52:50 +0100 (CET) Message-ID: References: <87fsemjs7v.fsf@yahoo.com> <87edu5izi9.fsf@yahoo.com> 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="2406"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "xenodasein--- viaEmacs development discussions." , eliz@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 01:09:14 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 1oujVq-0000OX-AK for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 01:09:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouilJ-00060S-B5; Mon, 14 Nov 2022 18:21:09 -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 1ouifd-0002B8-1F for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:15:19 -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 1ouY1E-00072P-Sk; Mon, 14 Nov 2022 06:52:56 -0500 Original-Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id AB1091060170; Mon, 14 Nov 2022 11:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1668426770; 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=AbLTJ1JgElkUpZdtV/uTUKoD9FWM5dOmuqdDYGuPrr0=; b=L0oeVlmURrblf6sBPTAboClcYNsfP7xez6Z+JIUKy5jnEGWDFsD1w9MgVcgVhP9h ONs3qfysbC+V3qvHLvDc2tdSvJfVobNVJccKQW+4WBoKrw+58dbVQ08p7alh+prsiB8 F4f4JctqsCkymE8oTaROxYfaKH5tt6ivmHOM0KYUB+bGI5+Jke8XMShZXMDhGZKF8uM drz9ssolkmDu6cnwEArQnlvkUz2eTsdzoQnkEORyt0IoLqMDSZwOGvW1NJkfO6APgUG QmxeNXLCDeEhQiPDnNeuBXyylFgSGXDtcWl5+MSET7bE0ftw4SvD8Zj8WBGfOKU9Svf NFQ1ZPFo+w== In-Reply-To: <87edu5izi9.fsf@yahoo.com> 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:299786 Archived-At: Nov 14, 2022, 10:47 by luangruo@yahoo.com: > xenodasein@tutanota.de writes: > > Something changes or it doesn't, I have no clue what you mean. > > Most changes break nothing. > > > Anyway, 'statistics' in my head formed after looking through lisp files= , > > how many of them there, and the fact that how few people are maintainin= g > > these, anyone can see this thanks to git. > > I don't see that. What I see instead is the same as with any other > mature, well-established software: most of our code is finished and does > not require constant changes. Practically all the programming languages or programs we support keep evolving yet our code is finished?=C2=A0 Surely you can see how this contradicts the whole point of software lifecycle wisdom? > > Problem is over time commits to core packages keep making assumptions > > about each other's existence and that inter-dependency does not seem > > to encourage anyone to work on them, even their original writers. > > Any specific examples? The example is the commit history, and the number of people rushing in to help maintain old Emacs code they didn't originally write. > Anyway, once a package is included with Emacs, and its minimum Emacs > requirement also bumped, it is fine for it to rely on the rest of Emacs > being present. But if its maintainer decides to support older versions > of Emacs as well, then everyone else does not interfere. See TRAMP for > an example of one such package. Crucial point here being Michael A. actually does the hard work and TRAMP is not one of the orphans. > > Even you are in your own X corner and not touching that issue, except > > for nay-saying on this list. > > It might not seem like it, but I have a job to keep me busy, and the > amount of time I can spend on Emacs is quite limited. That is why keeping the core as simple and easy to maintain as possible is very important. > Add to that the fact that Emacs 29 is about to be released, and the > major changes to the GUI code in it have inevitably led to regressions > that have to be ironed out, and you will see why most of my changes in > the past two months have been limited to minor refactorings and bug > fixes. That approach seems to have paid off. For example, it has led > to bugs that have lain unfound for almost 30 years being fixed (see for > example 25c6bc7a3.) Your fixes are numerous and very helpful, thanks a lot. > > Yeah? Who he is going to put in the cold hard work hours into > >=C2=A0 maintaining all that? > > Presumably whoever wrote the package and has *asked* us to include it > into Emacs. My whole complaint is that this is not happening, so the trend here should be reducing lines of code, but opposite is happening.=C2=A0 This not a good direction. > > Furthermore after certain complexity it is of no help even having > > numerous developers. > > [...] > > These are well documented and understood facts of software development > > and when someone keeps denying these things without substantial > > argument it displays blatant incompetence. > > So by changing the repository in which some code is placed, other code > is made more complex? By what, magic? By their interdependence increasing over time.=C2=A0 All code being in the same place and the nature of free software without strict rules, seem to lead to this result, I believe it is easy to observe from Emacs source. Quoting from some other mail I've sense to list: "Same reason emacs-devel is not responsible for every single line of Elisp code on the Internet?=C2=A0 External packages seem to get more love from their developers.=C2=A0 If not, something new replaces them, people migrate, and nobody complains to Emacs bug list about it." > > I don't see how bundling millions of lines of code together when there > > is already a system to distribute these as external packages is a > > shortcut to usefulness for everyone (what does that even mean?) > > You cannot seriously claim it is easier to run several commands to > unpack and install a package in the ELPA directory than to do nothing at > all. Technically it is not easier but also how much harder it is to install them is so minuscule that the maintenance burden it causes it is not worth it.=C2=A0 All that effort is better spent improving Elisp, minibuffer= , simple, cc-mode... i.e. "the good parts" and let convenience projects get externally maintained.