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, 16 Jun 2023 21:03:35 +0800 Message-ID: <874jn7h848.fsf@yahoo.com> References: <83v8fnslfz.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="39642"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 16 15:05:09 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 1qA98W-000A4v-S9 for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Jun 2023 15:05:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qA97N-0005cw-S0; Fri, 16 Jun 2023 09:03:58 -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 1qA97H-0005cO-Gu for emacs-devel@gnu.org; Fri, 16 Jun 2023 09:03:51 -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 1qA97D-0006eO-UM for emacs-devel@gnu.org; Fri, 16 Jun 2023 09:03:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1686920625; bh=wTeOoIXU6j6tDfMH6mhioENSMdPl/huenGG0hz0dOGg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=OE43I85xCoh+szZnY/KEMMxrBlw4MperhYRAdYPf5PSOHJJT9/6hKf9iEi10+4eukWwJfORoI6ZqQOAqJc6mKGK3zuUei2Kk2/2Lxkbje2WA3rl9w6tMZm6zdvZAEsarbFoQ3vpzPzcCGw3mLUAUkQqDWHYZBnlY8rdOb1zWocDAObEKk364DiV1RoCClQCPRLTPJCPpeVemmabPKqgBrfEjkTBKrLFzIDX5ROG/IJ/u8rcq3VkgxTRk1RhMMLJGr0+vjTzz2X71DE+feoOkaHWzSsPZUNhtKb+8yO9qkwVOLkMg4vHBMHvTUAxjCeBR++VyyYTKfG+LwcmeAPumdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1686920625; bh=BzH82vlQcGvhJJ1D9EGcVr/UO/iFD+fxHSrIX6B4zr+=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UQNBsd+1k2i3PAepBmHe1FMqjL5Jz/eWyeZShC/AmKttFbcmXqTBkNRd95NpsGv+l4TvucknGkoFLyIwaOc15AConsxo36ALk8iooo18YOG6rRsm626Aqe6r+jeHFRskKDRpsPElM/FDTR2sqpxVuLLQEYmhK+Q+kSh0ARy6y5xIU7TSf/JattuX+P/WZMYpPcx/6ruHIMoO5WzfzVc3+S/Br1c10BRXA8VNS7F2gp9OZR//vvFeDq8HexPV309TCJ3jlS2qWSMl8BlAHvCOuFKYHnUWDQz4wpNUnCYAeZt1Qfnc/oVEA+vXDhKyn1BYPRUeO/vNH1qLqGA+d4HcOA== X-YMail-OSG: FdjImt4VM1kVe5IKF2sm7pi4daDlgHNM9npYXekvKsmXP8cR8tx_aHePj7czTLr ubKqR47wbe947LRonOQFG8pdHzdWmlTDD54JGYfJIDv3CxabHTodea_.Orbd10CmXi5wpAz0b0Xt 1mbscTqXGVYrS2K4OUQDDYapes0R8.hL72Bl2cwli8ApVPhyXcDkD9bSI_eYb5.nwGRja24VsurP mJm6.0zvYPL1mv7gGIRsSZYQsSnjhs7jeac9aacItYPHuLpjvfN9zwyv9Nkc1FtTXUyKHKsqTnhR .FLFMXZeyyfJcmAqxh4miiNGn5uYe_Mn_zwOYg261APoheVDyG.rX2uALu1bmHC1VN8WEYnqQBrJ AuWIqz66HsIfBnv0G2LdKE6jancjSKlv1BAz41appx2GCPLby4Fez6C3JMtV3TaP2QGIaDiVvlEH yEACQ3DPJaBrTUhlVKNKxUnRMJaCcCPVv3CqJK.v65VmkolPV4SfAILco69RxR0.vy_fiXCmJmh8 PQuyzcDgboW3lSsQWfcgXcboeiSwKWbUgB3X9yeLhtCqH0nAXSi8mvg_FrDMFnKLB8wJOqqy997Y RS4qO_RLoLF7nk__OuRNlt9_2etrMgAHkEoB1JfYNUG2Ta7rWPM_wI0zzFxM7QewwP69aJtjSFpz TmGYZnUZGqkiZOFcferwq7Kr8bppbF0E2swae6p9NL_I5jYLGWz33BMamTy5g5EkudCipIIU.xui TbqzKJj2IYC2J860nPLKK1TtqXvQVU246G_LolP.gT02SjMvWdivW_5eEHdsHFjF3M9L75mREGQN dQalGJNgdPSoymsRYBK5_JlB9bCZV_zW7V0PjEj5.i X-Sonic-MF: X-Sonic-ID: fd014530-d4e3-402b-84ab-29ef70e04d14 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Jun 2023 13:03:45 +0000 Original-Received: by hermes--production-sg3-748897c457-fp9l7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 95f24f3cdbaa67336f2eff2b011e1abd; Fri, 16 Jun 2023 13:03:40 +0000 (UTC) In-Reply-To: <83v8fnslfz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Jun 2023 14:20:16 +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=unavailable 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:306830 Archived-At: Eli Zaretskii writes: > I wonder whether the Android port of Emacs, which is being developed > by Po Lu for the past few months, should be part of the upstream Emacs > and whether it should be distributed as part of the Emacs release > tarballs. The advantage of having the Android support bundled is that > we allow people to build the Android port right out of the release > tarball. However, Android is a proprietary platform, so it isn't one > of the systems that we are required to target. I also don't think > Android (and smartphones in general) will become the main, or even > important, platform for Emacs any time soon. It's worth mentioning that this port of Emacs runs just as well on the free Android-based systems, such as Replicant. Whether or not enough people use them is up to debate, and sadly my opinion is that those systems are used so rarely that they should not be put into consideration. > There are some significant disadvantages of the Android support: > > . it makes the Emacs distribution significantly larger (I think no > other port, not even the MS-Windows or macOS ports, add so much > stuff to the distribution) I believe most of the code stems from Gnulib, and most of that is vasnprintf-posix and its assorted dependencies. > . significant portions of the Android support are (and AFAIU must > be) implemented in Java, which is not used anywhere else in Emacs; > Emacs developers are therefore not expected to be Java experts, > and we have no Java-oriented coding conventions in Emacs Similarly, the Nextstep port is written in Objective-C, an object oriented language similar to Java. In the Android port, care has been taken to keep as much logic as possible written in C, with only the bare minimum required written in Java. For example, the font backend which is actually used (sfntfont-android.c), and much of the bitmap copy code, is written in C. In contrast to Nextstep, no Lisp functions are implemented in any non-C language. Additionally, the Java code is also written to minimize the use of Java specific features in the language, and a 900-line (to be expanded) write-up is provided on the specifics of both reading and writing Java code and connecting it to the corresponding C code. > . it requires non-trivial knowledge of the Android platform, > including its unique requirements and limitations The interfaces between Java and the rest of Emacs are designed to closely resemble the X window system. As a result, the C-level input, windowing and graphics code is more or less a direct translation from xterm.c and xfns.c. It was intended for Emacs developers who do not need to change Android-specific code to only require basic knowledge of X. > . its integration adds some non-trivial hair to many existing Emacs > APIs and processing, whose purpose is only clear if one considers > the special Android quirks I can only think of two specific quirks: file management and the `exec' helper binary. The former is not so different, and much closer to Unix-like systems, than the Unix emulations in msdos.c and w32.c (not to mention the numerous special cases under DOS_NT in fileio.c), while the latter seems is not much different from the `cmdproxy' binary found in NTEmacs. They are all well behaved and stay out of the way of system independent code parts of Emacs. > . currently, we have a single developer who understands the > specifics of the Android port and works on developing it; it is > not good for Emacs to depend on a single individual for a port > that should be kept alive and up-to-date for the observable future That's still a significantly better situation than the NS port, which seems to have zero people who really understand it. > Given these IMO significant downsides, I wonder whether we should > maintain the Android support as part of the upstream project. It > sounds like a non-trivial maintenance burden that relies on a single > developer. Should we really commit ourselves to this additional work, > from now on? > > An alternative would be for the Android support to be a separate > project on Savannah. Maybe in the long run this would be better? > > I think this deserves a serious discussion and a more-or-less > agreed-upon decision, before we decide to land the Android branch and > thus commit ourselves to supporting the Android port. > > Once again, apologies for bringing this up so late. When the work on > this port started, I had no idea the result will be anywhere near > where it is today, or I would speak up much earlier. Here are some more facts to put the maintenance burden into perspective: - The Android port is being developed by one person in his limited spare time, and even under those circumstances was completed in 4 months. Synchronizing it with other changes being made to Emacs is trivial: even as it stands right now (in a feature branch), less than 5 minutes of my time are required to merge the master branch and prepare new prebuilt binaries each morning. - Problems posed by the Android platform have already been solved, and the solutions are likely to benefit users of other systems as well: input method and touch-screen support come in to mind. - There are many free software programmers with Android development expertise, especially when compared to those who have experience developing for systems such as DJGPP. Thus, if necessary, it should be much easier to locate a replacement Android port maintainer than one for the MS-DOS port. - More commentary on the Android port is going to be written before it is installed. If the Android port is installed, other Emacs developers are invited to make changes without consideration towards the Android port. I will correct the fall-out, or the Android port will be broken. Thanks.