From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Fri, 16 Jun 2023 17:19:05 -0400 Message-ID: References: <83v8fnslfz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cc792105fe45bcca" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21284"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 16 23:20:03 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 1qAGrS-0005Nn-LJ for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Jun 2023 23:20:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAGqo-0000M7-Sm; Fri, 16 Jun 2023 17:19:22 -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 1qAGqm-0000Lb-PL for emacs-devel@gnu.org; Fri, 16 Jun 2023 17:19:21 -0400 Original-Received: from mail-yw1-x112e.google.com ([2607:f8b0:4864:20::112e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qAGql-0003VG-0L for emacs-devel@gnu.org; Fri, 16 Jun 2023 17:19:20 -0400 Original-Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-5700b15c12fso13829117b3.1 for ; Fri, 16 Jun 2023 14:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686950357; x=1689542357; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=5ZPspSx/xFjtIFqQ3YZSpandoaFmhrebQf7WO0uPsvg=; b=rQKtqtzlUbU1FAA37WX3+iwrxz0EU0fajKqk/uckmZQVBYkE8foi6kIoZGbNboc7vj 9vF4Yh/8Q7/3wKstgfAkqToDpxvD/jiiexo133iV7XfIeezR0RmPmN49vPnfwIsuSODb HSPkFU/JGYZWZMFMXEEUNtIowfm9JW/jpoNGIJYN5CrMTznAZd6M6LqWa4mnXd4kuACd fJN8ESitIyWSXQihL5zeBJQ8wwqMNaLECL7bpFMjcN2Si8LSnHetTxf+IfoXkwgN38WF +1i4VIFrw/dXFS7KJnQZhQrhnViArdZpsyWVRX6px2R15/1syuIhH4FJjA1fFwVJnBH/ 9w/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686950357; x=1689542357; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5ZPspSx/xFjtIFqQ3YZSpandoaFmhrebQf7WO0uPsvg=; b=FMHdlEGvDyUnm4sdO8CmQIyoM7poietWOQf4bJDqMpu4+CiIUT2W/TJaW/K8PEAR1S gifBk8nHfsnGg2XqJMkOI3a0OF4GZWrOqZkZ5ZEK06Yaa1py3OgvO6EkMyGYmmzW3XHc AUE8zm7PnxWL0DUqPYVrdrjEFJB/JG2H27GqPD0rzjdXW0fr52RefCsAOVUk1ikpVBCZ p3c7s9Yi/2bTMJKQMhlTjcVB9OqC/2fTUT9pJFn0eaLneDcs2VumPLBhg0VSqWuZdGjb CGqTyXsLAoyyK1oIdJXRaIm2Po7Er+7WSLw6C91h2P7yRX5r8vA8wNC6lZIcRtpKZI4Z lT9w== X-Gm-Message-State: AC+VfDxlimAIxukMvrZ89cW7YT6MgQddsJtRe5d5DdV3taxlKJm7bhtg w36iG8EnhQ70mqzh2qBOn7KDIcgLYZGSzHrqlUyI+ZL6hog= X-Google-Smtp-Source: ACHHUZ5d5JPSsPHXisO3Op34+eN4nx6yM+2/KBObPSmp79CBTv1zxbA3ksHx9Vq4pZVfuOrr+stBMK9i9Iz62I536oE= X-Received: by 2002:a81:5211:0:b0:570:88a8:9862 with SMTP id g17-20020a815211000000b0057088a89862mr266120ywb.38.1686950357267; Fri, 16 Jun 2023 14:19:17 -0700 (PDT) In-Reply-To: <83v8fnslfz.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::112e; envelope-from=yandros@gmail.com; helo=mail-yw1-x112e.google.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:306840 Archived-At: --000000000000cc792105fe45bcca Content-Type: text/plain; charset="UTF-8" We've seen a couple positions put forward that I will paraphrase as "I personally see strong potential in Emacs for Android, although I don't/wouldn't really use it right away." As near as I can tell, these positions are tangential to Eli's point which I will summarize as "The Android port is great, and we should probably give it _some_ support, but maybe that level is lower than everything expressed and implied by incorporating it directly into the mainline emacs repository?" I am personally sympathetic to both views, and (at the risk of forking/hijacking the thread a bit), I would even go so far as to say that Emacs as a project might benefit from spinning out at least the Android port (which is new and very maintained, but has a very high bus factor) and also the NS port (which is not new, shows some downsides of high bus-factor parts, and has at least one well-maintained alternative outside the mainline Emacs repo: the mac port). As a technical matter, it seems like it's probably easier to maintain some abstraction barriers along OS and window-system code by virtue of having a single repo that supports 3-5 "variants", but in practice that _seems_ to have mostly resulted in treating a quite old "posix-y-unix with X11" as the baseline, and then adapting everything to that. This seems (again, I'm not an expert here) to have caused some continuing pain with respect to GTK and the pgtk port (particularly in the very high incidence of people using pgtk in wayland+X environments where it's not supported, kinda works, and breaks in not-so-rare corner cases). Taking the NS port as an example, if the mainline were to drop support for the ns port, this would nudge some macOS users over to the mac port, strand some users of quite old macOS versions, and isolate the users of the GNUStep port. My belief is that the mac port is already quite popular, the people stuck on old mac OS X versions are already stuck with library and compiler version issues, and the GNUStep port has very little actual usage (I wouldn't be surprised to learn that "testing GNUStep support" is the single largest user-base of GNUStep" at this point.) Before discussing whether these tradeoffs are worth it or not, is anything I've said above obviously wrong, under-informed, or out of date? ~Chad --000000000000cc792105fe45bcca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've seen a couple positions put forward that I will = paraphrase as "I personally see=C2=A0 strong potential in Emacs for An= droid, although I don't/wouldn't really use it right away." As= near as I can tell, these positions are tangential to Eli's point whic= h I will summarize as "The Android port is great, and we should probab= ly give it _some_ support, but maybe that level is lower than everything ex= pressed and implied by incorporating it directly into the mainline emacs re= pository?"

I am personally sympathetic to both view= s, and (at the risk of forking/hijacking the thread a bit), I would even go= so far as to say that Emacs as a project might benefit from spinning out a= t least the Android port (which is new and very maintained, but has a very = high bus factor) and also the NS port (which is not new, shows some downsid= es of high bus-factor parts, and has at least one well-maintained alternati= ve outside the mainline Emacs repo: the mac port).

As a technical matter, it seems like it's probably easier to maintain = some abstraction barriers along OS and window-system code by virtue of havi= ng a single repo that supports 3-5 "variants", but in practice th= at _seems_ to have mostly resulted in treating a quite old "posix-y-un= ix with X11" as the baseline, and then adapting everything to that. Th= is seems (again, I'm not an expert here) to have caused some continuing= pain with respect to GTK and the pgtk port (particularly in the very high = incidence of people using pgtk in wayland+X environments where it's not= supported, kinda works, and breaks in not-so-rare corner cases).

Taking the NS port as an example, if the mainline were to d= rop support for the ns port, this would nudge some macOS users over to the = mac port, strand some users of quite old macOS versions, and isolate the us= ers of the GNUStep port. My belief is that the mac port is already quite po= pular, the people stuck on old mac OS X versions are already stuck with lib= rary and compiler version issues, and the GNUStep port has very little actu= al usage (I wouldn't be surprised to learn that "testing GNUStep s= upport" is the single largest user-base of GNUStep" at this point= .)
=C2=A0=C2=A0
Before discussing whether these tradeof= fs are worth it or not, is anything I've said above obviously wrong, un= der-informed, or out of date?=C2=A0

~Chad
--000000000000cc792105fe45bcca--