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 19:49:59 +0100 Message-ID: <874k70xync.fsf@telefonica.net> References: <87sfulx86y.fsf@telefonica.net> <83h7b0ycwr.fsf@gnu.org> <87k0fwy6wi.fsf@telefonica.net> <83wnjwwolq.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="2225"; 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:DSCg134YTnIOxry1fwBkvGyOI14= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 22 19:51:53 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 1n06iP-0000NL-M3 for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 19:51:53 +0100 Original-Received: from localhost ([::1]:41042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n06iO-0006gh-9g for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Dec 2021 13:51:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n06go-0005CK-3o for emacs-devel@gnu.org; Wed, 22 Dec 2021 13:50:15 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:39466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n06gl-000453-E5 for emacs-devel@gnu.org; Wed, 22 Dec 2021 13:50:13 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n06gj-0008st-32 for emacs-devel@gnu.org; Wed, 22 Dec 2021 19:50:09 +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:282820 Archived-At: Eli Zaretskii writes: I'm skipping over several things to keep this short and to the point. >> 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. I don't think so, the few doubts I had vanished after reading his recent messages. > Or maybe you have > some different suggestion in mind, because what he was suggesting > makes no sense to me. Maybe asking for clarification? I can expand on the proposal, but somebody else already did. I can answer specifics about that topic if necessary. > 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? Well, that's a glaring example of what I said about not internalizing the social implications of our "new" tools :-) If you have doubts about his suggestion, you could just say "I don't get what you are proposing but if you think it is good for Emacs then sure, go ahead and I'll examine your work when you have something to show." Then the OP goes to work on his personal repo. That has almost zero cost to you, both on effort and risk. It's not like the old times when you had to give write permissions to the project's repo and destabilizing WIP usually happened on the main branch because merges on CVS are a pain. >> 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. Very true, but I don't see how this contradicts what I wrote. The occasional new feature on core base happens, but extensions (Elisp, interfaces to external processes and, more recently, modules) makes the bulk of Emacs' user-perceptible improvements, much more so if we count external packages. > . 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). I'm convinced that there is a strong survival bias at play here. > 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. This definitely agree with.