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: Development Speed Date: Wed, 22 Dec 2021 19:12:17 +0200 Message-ID: <83wnjwwolq.fsf@gnu.org> References: <87sfulx86y.fsf@telefonica.net> <83h7b0ycwr.fsf@gnu.org> <87k0fwy6wi.fsf@telefonica.net> 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="36259"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 22 18:13:45 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 1n05BR-0009Df-Cy for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 18:13:45 +0100 Original-Received: from localhost ([::1]:52334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n05BP-0006Kc-Qu for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 12:13:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n05A1-0005TO-Hi for emacs-devel@gnu.org; Wed, 22 Dec 2021 12:12:17 -0500 Original-Received: from [2001:470:142:3::e] (port=48052 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n059y-0000xL-Cn; Wed, 22 Dec 2021 12:12:16 -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=HiH2gF+/WacrHbxg6dffBcNvex6kK166YaVNYCUwZGU=; b=QprHN5Hp8eOktLb4KN1e BmuwOPF1h5RR0NF5F4YwpCFsQRfa1QtqN9hQ0HudhGbTVmqfXJcApanlKVDGEANwLz3yaYqW3Uppq 1kv9e6G/UXCpWCjC/TW61NhP36PSzwZqaCsywvrIz6ORTouelQirKe7nbIppjlLhDla74HNdR/cM7 cRWQwfySfx7x7NIdeOibLEMKoBdbxu9AMEtB/8q7s3qGBODnZLCmngsdAqdoAy239xWv63mk3eUlu 1zMgwsc7lRuxuX1WZC/bqUMBblOpE7Wf0fTCTN9mo1wjqAyrkKnorzaSExngdsrjx0ncZmUvW7V54 deswWEec2NRn4w==; Original-Received: from [87.69.77.57] (port=2130 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 1n059y-0006nf-20; Wed, 22 Dec 2021 12:12:14 -0500 In-Reply-To: <87k0fwy6wi.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Wed, 22 Dec 2021 16:51:41 +0100) 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:282791 Archived-At: > From: Óscar Fuentes > Date: Wed, 22 Dec 2021 16:51:41 +0100 > > 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. That's a lopsided view of what happened, with denigrating epithets ("painful", "inadequate") to season it. The switch to bzr was no more painful than any switch from a centralized VCS to a dVCS could be expected to be. At the time we switched, bzr was a viable alternative, used by several other projects (some of which kept using it long after we switched to Git). And how the problem with contributors' mindsets is any evidence in favor of your argument is a mystery to me. > 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 lopsided view: we are looking for a better system for quite some time, and until now none was found to satisfy our basic requirements. Hopefully, sourcehut will. For a more balanced view, try to find a project that is happy with its bug tracker. I'm still looking. > Another example: the amount of old cruft and hacks that pervades the > source code, prominently the C part. Really? Like what? And how is this a "technology" problem? Or would you like us to rewrite Emacs in Rust? Come on, get real! This is supposed to be a serious discussion, not a mud-throwing match. > 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.) And how is this any evidence that we procrastinate in our acceptance of new technology? Does Motif support disallow any such advances? > 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. Maybe you misunderstood what the OP was suggesting. Or maybe you have some different suggestion in mind, because what he was suggesting makes no sense to me. Do we have to accept any suggestion whatsoever, no matter if it does or doesn't make sense, lest Óscar will accuse us of being backward? > 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." No, we maintain old code because it works and because we decide not to break it. It's a decision which has reasons, you just choose to ignore them because you want to make a point in an argument. And how is this any evidence of (not) accepting new technologies, anyway? Or are we changing the subject now to something like "all I hated in Emacs development but was afraid to say out loud"? > 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? That is against any reasonable experience and facts on so many levels that I don't know where to start. Here's several items, as food for thought: . Emacs extensibility via Lisp can only go so far, sooner or later it hits a wall. Some extensions and major developments need changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in with Lisp is bound to fail. Evidence: linum vs native line numbers. Evidence: bidirectional editing (which originally had a Lisp implementation which went nowhere). Evidence: HarfBuzz vs "ligatures" via prettify-symbols-mode. . Working on the C level requires certain efforts, but is far from being impossible for novices. Evidence: face-extension feature and display-fill-column-indicator-mode feature that was coded by someone who started from almost zero knowledge of the display code. Evidence: several people who started working on the C code just recently (see Git logs). . Reasons why "plenty of C hackers", if they indeed exist (and IME the jury is still out on that one), need serious investigation. I have my guesses about that, but they will remain unsaid at this point. Bottom line: I find that Emacs recently picks up quite a few new technologies, and for an old and stable program such as Emacs we should be proud of what we accomplished.