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: Android port of Emacs Date: Fri, 16 Jun 2023 14:20:16 +0300 Message-ID: <83v8fnslfz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26806"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 16 13:20:51 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 1qA7VZ-0006m3-9j for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Jun 2023 13:20:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qA7Ug-0001lb-AC; Fri, 16 Jun 2023 07:19:54 -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 1qA7Ue-0001lC-Jk for emacs-devel@gnu.org; Fri, 16 Jun 2023 07:19:52 -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 1qA7Ue-0006cY-Ao; Fri, 16 Jun 2023 07:19:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=NFq4cn9ZVKMwndYo4/e3X+GNcUBs+lzLwNYoJRnw+7A=; b=DL/fGakvoVXps2 HqAs8ZciRcp6jVabqgqoKcVPrE9ZRFV1AWkHvypIXRw6WHcbfPILGwaFj8vnhLnrPxbuZHTcXuYfO tKM7nODSk1uEJbBjm8Axa8e8HxDvVfWTw7YupLb5Pb+ZGhILFPvZvNYuiGIG5osMY5GCMKySR608L DSVUrCPlrf1xfXbwdOOrC2A4GH4EwJa2q0vNx2LCWJBEHlsO8G9T1fWnI+AZqskTo+6qY1i1mvVAH EQgiUOuA2YL7ewfEhG2IyKwz176us/ceQFrM/ksBBANHJYuKLc+1Qm5UZhbWI1uVe8Y2cparn4GD4 W2lY9mQZMm/t5asoX9FQ==; 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 1qA7Ud-0001b8-Rh; Fri, 16 Jun 2023 07:19:52 -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:306827 Archived-At: I apologize in advance for not bringing this up earlier. However, better late than later or never. 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. 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) . 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 . it requires non-trivial knowledge of the Android platform, including its unique requirements and limitations . 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 . 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 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.