From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Development Speed Date: Wed, 22 Dec 2021 16:51:41 +0100 Message-ID: <87k0fwy6wi.fsf@telefonica.net> References: <87sfulx86y.fsf@telefonica.net> <83h7b0ycwr.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="30596"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:pw5rzIOHRGzwc1mrB7Gd2JrZWQA= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 22 16:52:55 2021 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 1n03vD-0007nW-LO for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 16:52:55 +0100 Original-Received: from localhost ([::1]:58248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n03vC-00069R-8C for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 10:52:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49578) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n03uJ-0005GR-Kc for emacs-devel@gnu.org; Wed, 22 Dec 2021 10:51:59 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:58988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n03uH-0006Ef-NZ for emacs-devel@gnu.org; Wed, 22 Dec 2021 10:51:59 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n03u9-0006IK-Qz for emacs-devel@gnu.org; Wed, 22 Dec 2021 16:51:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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" Xref: news.gmane.io gmane.emacs.devel:282771 Archived-At: Eli Zaretskii writes: >> From: Óscar Fuentes >> Date: Wed, 22 Dec 2021 11:09:09 +0100 >> >> The amount of tension and obstructionism that emerges every time that >> someone suggests implementing some technology less than 20 years old is >> overwhelming. > > Generalizations are almost always risking losing accuracy, but this > one does that with a vengeance. I think it's not only inaccurate > (when talking about Emacs development), but also simply unfair. E.g., > some of the recent developments in Emacs use technology that is much > newer than "20 years", and I challenge you to come up with examples > that could back up your generalization, or even come close. Example: the painful road from CVS to a modern VC system (first bzr and then Git when was clear that bzr was inadequate at several levels, as some warned before it was adopted.) And then many contributors didn't bother to adapt to the distributed workflow and keep using Git as if it were CVS, which makes the VC history hard to follow and of diminished value. Another example: the mailing list used as a bug tracker. We went from no tracker at all to a big hack that happens to accommodate the personal preferences of a few contributors while making things harder for everyone else. Basic things like subscribing to a bug are too advanced: you either monitor the mailing list or out of touch. Another example: the amount of old cruft and hacks that pervades the source code, prominently the C part. The motif port was re-enabled with the excuse of two users saying that they use it (two users! which actually didn't actually said that they use the port, just that they build it.) A the same time someone suggested experimenting with a new approach to display and he was shunned ("We tried with such a library, many eons ago. It was named lwlib, and you can judge for yourself how successful it is.") Right, because if it failed many eons ago, trying again is doomed to fail for sure, as technologies in software change as often as in medieval masonry; and what the OP was suggesting is not what lwlib does, IIUC. So we maintain old code because two people "complain" (they didn't) and meet with... let's say skepticism, proposals that seem to require significant changes on the source base but with a high impact on improving Emacs' potential. Lots of features and fixes are made trying to not change the "stable" code, that's why we end having functions over 1000 lines long sprinkled with #ifdefs, which not only make any substantial change very difficult, but are a big red sign saying "here be dragons." Emacs' architecture favors plug-in components, in the form of Elisp packages, external processes and C libraries exposed to Elisp. That's what keeps Emacs somewhat competitive, often thanks to heroic efforts. But working on certain key parts of the core is very hard, both technically and socially. You are concerned about the lack of C contributors, but I think your worries are not well focused: there are still plenty of C hackers around, but do they see our C core as something they would enjoy contributing to?