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: Android port of Emacs Date: Fri, 23 Jun 2023 10:04:24 +0300 Message-ID: <831qi23bif.fsf@gnu.org> References: <83v8fnslfz.fsf@gnu.org> <83edmask4z.fsf@gnu.org> <5c02371a-3c42-de66-70b7-4ed0d88cc3fa@gutov.dev> <834jn159vs.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26218"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 23 09:05:22 2023 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 1qCarB-0006PZ-CT for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jun 2023 09:05:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCaqF-0000DS-7G; Fri, 23 Jun 2023 03:04:23 -0400 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 1qCaqC-0000DI-5X for emacs-devel@gnu.org; Fri, 23 Jun 2023 03:04:20 -0400 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 1qCaqB-0004uV-T1 for emacs-devel@gnu.org; Fri, 23 Jun 2023 03:04:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Lhjw3uZYGq6NyVxN+NT9YDRUQ7ekhk5PFIQBmYALV8g=; b=rnjOX2DXFJS/ +iwIDH8FZxEGXzGIjkEdp6SPxAt1MVzyZNdegFSyU1/ORh0ZdROUC4QrXwh6dkdMBnpdznM7ZO9qb w/0jRltZ9VBKyuQ9uKhgempYQYLhd6BZgJwCM/dQMPYGLC5aqDE2o9+1oAtqe6EJbeyMtDFLE83+U fiH4wh63ISWuaQio5S+Uc7hoQoid76wqhWrOCWBooCPH0dyNUA5mtKEhfz6txU3/VtdLagvgtctma 6d73lLrlPLlRyQc4XrQO9QgiRe8mJVyvps/Att80cb764K0DnxuNIgR5tRXVz6qSUnsXi6A4bb+fQ imIvF4ZPfbrOLF3mvOfeHg==; 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 1qCaq3-0007fP-FY; Fri, 23 Jun 2023 03:04:11 -0400 In-Reply-To: (message from Richard Stallman on Thu, 22 Jun 2023 21:47:14 -0400) 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:307148 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Thu, 22 Jun 2023 21:47:14 -0400 > > > This side-steps the issue which actually prompted me to start this > > thread of discussion. The issue that bothered me is why should we > > commit ourselves to including a significant feature which complicates > > Emacs, if it might soon enough become unmaintained (due to several of > > its aspects I described). > > I think that is a valid concern. But if Po Lu says that he wants to keeo > working on it and make it good enough to achieve popularity, I suggest > that makes the effort of installing it a good investment. For how long will that single-person support last? We have bad experience with depending on single persons for specific expertise in important areas. For example, GTK was essentially unmaintained until recently, because the one person who knew about it resigned from Emacs maintenance. The NS port is in that status now: serious problems are solved only by sheer luck, if at all. Basically, any area in Emacs that requires extensive external domain knowledge that cannot be acquired reasonably easily by reading some freely-available documentation, and/or that's implemented in code not documented well enough, will become unmaintained if the single person who currently supports it goes on to greener pasture. (Someone brought up redisplay and bidi as such examples, but that's false: those are well documented in Emacs and the requisite external knowledge is in standard documents that can be studied and understood with reasonably small effort. For example, if bidi.c loses its sole maintainer, someone could study the UBA in UAX#9 and reimplement it from scratch, using the large commentaries in bidi.c and xdisp.c as guidance.) When I started this discussion, I thought we'd want to learn from past experience, and expected some discussion of how to learn from the past and whether this case is somehow different or not. Instead, all I hear is that the Android port will be a useful feature (true, but never a question in my eyes), and how we already made similar (mistaken?) judgments in other cases. E.g., I point out that a significant part of the Android support is written in Java, so Emacs maintainers will need to be proficient in Java or rely on others for making decisions, and in response I'm told that we already have Objective C in the NS port. IOW: we already made similar decisions in the past, so let's keep doing the same in the future as well. Are we not supposed to learn from the past? Are we not supposed to apply past experience to similar situations, not just reiterating the same decision-making processes with quite probably the same outcomes? Here we once again have a situation where a single enthusiast says he'll be working and supporting this new useful feature indefinitely. And we again make the same decision: if he says so, then it must be so, and there's nothing to worry about. The potential negative outcomes are neglected as improbable, in direct contradiction of past experience, which clearly says otherwise. How many cases with such unwanted outcome do we need to see happening before our eyes before we conclude that what happened in the past can very well happen in the future, all the well-intentioned enthusiasts notwithstanding, and before we start applying that conclusion to our decision-making process? But maybe I'm the only one who is bothered by the fact that we never, as a project, raise the head above the water level and look farther into the future than just tomorrow or the day after? In which case I'll stop talking about this and accept the fact the others aren't bothered. After all, I don't own this project, I'm just the steward; if the community decides to go with this, the community will bear the consequences, whether good or bad.