From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Fri, 30 Jun 2023 17:40:12 -0400 Message-ID: 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="28547"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 30 23:41: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 1qFLrl-0007GP-MA for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jun 2023 23:41:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qFLqt-0002hB-Ma; Fri, 30 Jun 2023 17:40:27 -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 1qFLqq-0002go-UP for emacs-devel@gnu.org; Fri, 30 Jun 2023 17:40:24 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFLqo-0000AI-8t for emacs-devel@gnu.org; Fri, 30 Jun 2023 17:40:24 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 43DB64415F2 for ; Fri, 30 Jun 2023 17:40:20 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E96CE441679 for ; Fri, 30 Jun 2023 17:40:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1688161213; bh=SE9X5hT8u4VxIxRojpf330F9za45HHgHupDFhHxSsjU=; h=From:To:Subject:References:Date:In-Reply-To:From; b=arVLlbZAczQNdnNHOo8KKG2o7rU6JimCGfLSNJUyjW8E7QSoqHgeWWG+GlTUBGUAI n9Da97XizSaSpLx2Smf4Y9ltnnCS8lUX8WgABi/TAIILbXpctLR71EA7PUZpIzsCHo hHJZbpjrjd2iw6R0w1lTS18TEKPUMeK0O5e9fRfgWUnxwSRq6bqIzShKhG0KZYvXCo Jk/XiU0itlGiJ0JxSQsTQkN4AGfaroeDGZ2xS8NHjFRgFUypZVZWUVOMDaRWqh8MEZ E0x9B7V/3vmMWTbiIt1GQ/bJkU24c8XT+AWsTq9UCAYfsVRwFpkztYmzQmGETpKqOu PQLUjeV8Tt7oQ== Original-Received: from pastel (69-165-155-162.dsl.teksavvy.com [69.165.155.162]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CFABF120205 for ; Fri, 30 Jun 2023 17:40:13 -0400 (EDT) In-Reply-To: <83v8fnslfz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Jun 2023 14:20:16 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:307318 Archived-At: [ Yes, I know, I'm coming late to this discussion, sorry. I don't intend to say much more about it. ] > 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. I have not looked closely at the branch itself, so take my opinion with a grain of salt, but here it goes: I don't think Emacs is currently very usable on Android because Emacs evolved in a context of machines where the main input device is a keyboard, with a mouse as secondary input device, and Android devices that fit this description are basically limited to Chromebooks. But for the same reason I think it's important to invest efforts in this Android port: machines whose main input device is a touchscreen are not going anywhere, so taking a longer-term perspective we should try and make Emacs more usable on those machines, and currently that mostly means Android machines. > However, Android is a proprietary platform, so it isn't one > of the systems that we are required to target. I don't think we're required to target any platform at all, anyway :-) [ I personally use LineageOS on my Android devices, and I don't consider it "proprietary" (tho I don't consider it fully Free either). ] > I also don't think Android (and smartphones in general) will become > the main, or even important, platform for Emacs any time soon. Agreed. But I think it has the potential to become an important platform in the long run (probably not to edit source code, but to run things like Org mode). > . 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) FWIW, I'm not sure how useful/important it would be to include the Android port in the Emacs tarball: I'd expect that anyone dedicated enough to build his own Emacs-on-Android (that requires a fair bit more effort than for other platforms, in my experience) would do so from Git. > . 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 I think we should treat this the same way we do for the macOS or MS-DOS support: there's always the threat that we'll remove that support if noone steps up to combat bitrot. > . 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 This is the real issue, IMO. We need to take a hard look here to see how to solve those problems. Is there a set of bugs opened for those integration issues? Or some place where we keep track of them? That's not a deal breaker, I believe (after all, we have similar quirks introduced by other ports, such as the /-vs-\ in file names, or the fact that we resist the introduction of a `fork` primitive in ELisp because of the problems implementing it on the w32 platform), but we need to keep this as much as possible under control. > . 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 While I don't foresee hordes of people contributing to the port in the future, no matter what we do, I suspect that if it becomes an "official" port (with a usable release on F-Droid), we'll start seeing more people contribute patches to improve Android support. Probably not many patches to src/android*.c, but patches to things like lisp/org/*.el, as well as new Android-specific *ELPA packages. > An alternative would be for the Android support to be a separate > project on Savannah. Maybe in the long run this would be better? The "mac port" experience is an anecdotal proof that it can be a valid option, but Aquamacs is the other anecdotal proof that this tends to have trouble keeping up with Emacs development and ends up forking and then dying. I'd rather include it in the main branch, to encourage its maintenance and hope for mutual long term benefit, while making it clear that if/when we have to choose between breaking this code or improving Emacs for GNU/Linux, we'll choose the latter. IOW, just as is already the case for Haiku, MS-DOS, ... Stefan