From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Fri, 23 Jun 2023 17:05:36 +0800 Message-ID: <87jzvuy2e7.fsf@yahoo.com> References: <83v8fnslfz.fsf@gnu.org> <83edmask4z.fsf@gnu.org> <5c02371a-3c42-de66-70b7-4ed0d88cc3fa@gutov.dev> <834jn159vs.fsf@gnu.org> <831qi23bif.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33525"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 23 11:06:58 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 1qCckr-0008Uh-UY for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jun 2023 11:06:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCcjs-0005z3-Du; Fri, 23 Jun 2023 05:05:57 -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 1qCcjp-0005vX-3C for emacs-devel@gnu.org; Fri, 23 Jun 2023 05:05:53 -0400 Original-Received: from sonic312-23.consmr.mail.ne1.yahoo.com ([66.163.191.204]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qCcjn-0002AA-8G for emacs-devel@gnu.org; Fri, 23 Jun 2023 05:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687511148; bh=KEizCzr0yaaz81IX4fFIoI2kFLp/VRBPw9v1ZvywTsE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=ZGqVHQOvMObhimJBef9q0qJ7omRxTNTA0UG97IBdUBXZWRXdBlzKuAdMelEjys/0S/jaTuWhlQbFIYXeIGEg5oyDlm3J6olEQ0Zy815jiGdqtFAMXO7aZOMOOVOnfN4EYEe3Sp6l+3UTkbTr3AEWMWkJo7X7MT03tYfWcG8xRROnr4dkZNH8W+5xYyGdf8kVfotCHOrbsEw/SDlzIRUH5j2rBY4rww7tXZUlb0mFu+JRdo7XWL6t5ca3jqdyaU5+yXnhNU8R6B6Eh1t6X1ffTvg0YELcCrIP+IjNDOvg+dlnfSqmb7V/smFkMyaL8dcaa3RrnpKEw/ugIGWixZZ0Ew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687511148; bh=IXHSmvQXzqvDYG5kLMow3kD44DO3h/46WljPGhgNgd7=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=j1pKJgwhYvGHyx/xSuWcb9gldASkjnvcRPdKm1/gLXT/Xl5xEObiXFkRtmpZshG/K+6/yTS1jwbPjGXBqipcHZJOVV4uq8Bs3LoUlOZ/qPz7JCFxbYhmy6pIc1u5OAiQJMqFsipKMKl7Ws7IQmThHB6V2aQc9zLYRGvNOUTOGRiZZCjnCZJ8ysZ+gADuc02r+k9GF43gMh+JfhNWvWxRdrJTgcqkeJrnHDFT9jlkhVQWDc8VskZ5py3JDnC65VWvHTf/hZsIau3rx8Y/rt1donfhZDur10j8q41WRzywe+1CCKl5zW5rjmEzLoaXjgC45pLLZvRlUlUAT5O03trluQ== X-YMail-OSG: tmuQdnQVM1nudwgRkaZ06aXAiy7CcSmbVsGHZ.iwMp_oUM6.1PedafyxqQUV106 fpW69csKXFDEeu5pHKrzdrQENV4_U.mctItrKOaDMeV8v4diuLNtcldgmBSGnwLkloP4hfmUN8QU zV0laC1yzbT1zLjKxPSi0NHAb8XZlRCluMe5HC.xOwKcE2ofbXAgmYPd5BvAXZucjdNVgwwNTu0j 7kIePCg6TrZA4lz05ySee_2pgqXAwquFdtenRzYrtkXLN9_tBO7kfOmu1IfGxfQ89x__V9ohWo0Z ErqmJHDpbuqEoYcQt0TZfQik5fH1ZU0kyrC2HSAOEpRXl7la3rbzo5Hkx6mV30YzB1YM5H_gVqEU K0slJ2kg4hJwYLrupVAtFDc_D2J0oQJpZBkt8DMMrkN_SVcjFm4FvNJMbEYR_jZ3AWSQkDKslDQB w3WCb26t.KVBS0Gp6eMhl2HhV5_qY2klGIpv7mpuY_NAu4vfgPhOLWOrseMPiOP77M03joXR319J 0rq23a.VLS58RL0gyUPSAUXYXBfkyLZr1ltmSmwzTMR.Sj.E7v5g4r1eqagCExVwF3Mno12lhegu vOh_ooRl8RhZz7pt8YMu6gyqvVrTrj9QZ.UsMttvBnl.68aJaT8_7teSHafsXHjBScZuxRNGmxbz NcU5LLhWot8V1WnCDqKnQpLSjSUl_2e_dqLruY3tdS6qQqwmBRWgk2MGqGpv_kP7HSE02QVunjVv 0P24fMwsiC0eVSiCN2qUmqMozRuv.X0aaiHuMbm0OXCHpiEoqf7WvfU3A.ZQXJ0XLrMERWfgOqK8 EIE_5hhDER0ZtgEArxAuruSJdqfZ.eFzdxkdb_Y4vU X-Sonic-MF: X-Sonic-ID: 159933f7-4f52-4ee2-8332-f28c98d21c2a Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 23 Jun 2023 09:05:48 +0000 Original-Received: by hermes--production-sg3-748897c457-fqxqz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0366b6d2d343527380e6a42e370803a7; Fri, 23 Jun 2023 09:05:41 +0000 (UTC) In-Reply-To: <831qi23bif.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 23 Jun 2023 10:04:24 +0300") X-Mailer: WebService/1.1.21557 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.191.204; envelope-from=luangruo@yahoo.com; helo=sonic312-23.consmr.mail.ne1.yahoo.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:307155 Archived-At: Eli Zaretskii writes: > 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 Android documentation is freely available, and the Android code in Emacs is fairly well documented. > 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.) Just as someone could study Android from the reference manuals at: https://developer.android.com/reference and standard C, POSIX, and Java materials. Though that is hardly necessary: for most Emacs maintenance work, only an understanding of X will be necessary. Xlib functions translate to Android ones through simple substitution; for the most part, replacing `X' with `android_' and removing arguments that expect a Display or Screen. > 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? I pointed out that we have Objective-C in the NS port, not because that inherently makes using Java a good idea, but because it demonstrates that the use of a non-C language in GUI code does not lead to problems. While NS has severe problems, they are not caused by the use of Objective-C. And NS uses Objective-C to a far greater extent than the Android port uses Java, with many Lisp and redisplay primitives implemented in that language, which are all implemented in C as direct translations of xterm.c or xfns.c in the Android port. > 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. How many people will have to step up to maintain the Android port? Because if 5, 10, or even 20 people do so, they may all still leave for greener pastures. This problem is solved by making the Android port trivially comprehensible for programmers who are familiar with platform-independent parts of Emacs, not by counting the number of people who are currently involved. I say we are already there. Thanks.