From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Sat, 24 Jun 2023 18:56:21 +0000 Message-ID: References: <834jn159vs.fsf@gnu.org> <831qi23bif.fsf@gnu.org> <87jzvuy2e7.fsf@yahoo.com> <83sfai1nq6.fsf@gnu.org> <87cz1mxvc2.fsf@yahoo.com> <83lega1iv1.fsf@gnu.org> <878rc9y7vh.fsf@yahoo.com> <83y1k9z6y6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2038"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , 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 Sat Jun 24 20:58:00 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 1qD8SN-0000JE-Px for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Jun 2023 20:57:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qD8R8-0001vB-LL; Sat, 24 Jun 2023 14:56:42 -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 1qD8R5-0001tW-Vz for emacs-devel@gnu.org; Sat, 24 Jun 2023 14:56:40 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qD8R4-0002l9-Db for emacs-devel@gnu.org; Sat, 24 Jun 2023 14:56:39 -0400 Original-Received: (qmail 89046 invoked by uid 3782); 24 Jun 2023 20:56:24 +0200 Original-Received: from acm.muc.de (p4fe156c6.dip0.t-ipconnect.de [79.225.86.198]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 24 Jun 2023 20:56:24 +0200 Original-Received: (qmail 9822 invoked by uid 1000); 24 Jun 2023 18:56:21 -0000 Content-Disposition: inline In-Reply-To: <83y1k9z6y6.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:307190 Archived-At: Hello, Eli. On Sat, Jun 24, 2023 at 09:54:09 +0300, Eli Zaretskii wrote: > > From: Po Lu > > Cc: rms@gnu.org, emacs-devel@gnu.org > > Date: Sat, 24 Jun 2023 09:19:30 +0800 > > Eli Zaretskii writes: > > > This description doesn't fit the reality. People who use the NS port > > > are quite disappointed by the problems that don't get solved, and I as > > > the maintainer cannot remain indifferent to their plight. It breaks > > > my heart that I can do almost nothing to facilitate the solution of > > > those problems. And mind you, no one thinks the NS problems are > > > "unimportant", we are just unable to fix them, even though we all > > > agree they are grave and should be fixed ASAP. > > > So you might be indifferent to such problems, or consider them > > > "unimportant", but IMO any responsible maintainer will not; I > > > certainly am not. And if we envision such problems to happen sooner > > > rather than later to the Android port, we may wish to decide whether > > > we want this now, before the danger becomes real -- as it became with > > > other similar features. > > I'm not indifferent to those problems with the NS port: I hope that some > > day, they will be fixed. However, Emacs development _should_ be > > indifferent to them, as its goal is to develop a high quality text > > editor for the GNU operating system, and not specifically others. > > Which seems especially reasonable, considering that the reality of > > volunteer-driven development is that every port will usually be stuck > > with one maintainer, at least until that maintainer steps down. > That's exactly the issue at hand, thank you. I'd like very much to > hear people speak up about these aspects, not anything else. > Lars, Stefan, Robert, Martin, Mattias, Philip, Dmitry, Joćo, and all > the rest of frequent contributors and developers: where are you? I'd > love to hear your opinions on this. Well, I'm not sure whether or not I count as a frequent contributor, but I'll answer anyway. I think you're right to be a bit concerned - how many people in Emacs have even the slightest hacking experience on Android? I think an answer of one would be concerning, but it seems not unlikely to be the case. Again, how stable is Android at the moment? Again, I don't know, not being the owner of an Android device, but my impression is "not very", at least in the sense that GTK, Wayland, NS, and so on, also don't seem very stable, more like "rapidly changing". All of these versions seem likely to be needing a lot of love for the forseeable future. All due respect to Po Lu for what he's already done for Emacs (including reporting lots of CC Mode bugs ;-), but that has been over a period of only two years. My impression is that the longer somebody has been an Emacs contributor, the longer they're likely to remain a long-time contributor. We could really do with a statistician to support/refute that notion. At the same time, having Android support in Emacs core would clearly be beneficial. Particularly if large-scale software development is about to start happening on Android. On whether or not to include Android support in Emacs, I feel very unsure - I can see the arguments both for and against, and feel unable to evaluate them. I suspect most contributors here likewise feel uncertain, and that is the main reason so few have so far expressed a view. If it would be practicable firstly to try out Android support separate from the Emacs code, and then move it in the event of a positive experience I would suggest that. But that would cost at least as much extra effort as simply having it separate. As I said, I don't feel able to express a strong opinion on the matter, but that's ducking the issue. My gut feeling is that the arguments for a separate Android Emacs version are stronger than those for integrated support, but that's not a judgment I could really defend very strongly. -- Alan Mackenzie (Nuremberg, Germany).