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: Re: Cleaning out old X11 toolkits? Date: Fri, 12 Feb 2021 09:09:56 +0200 Message-ID: <83v9axg3sr.fsf@gnu.org> References: <07D5E64D-DAD0-45B3-B272-627A73D7CBAE@gmail.com> <7308DB2C-27A5-4227-A1F9-9949EE558052@gmail.com> <87sg6alweo.fsf@gnus.org> <87pn1erewq.fsf@gmail.com> <87wnvlecrw.fsf@gnus.org> <83sg69o3av.fsf@gnu.org> <87mtwhctte.fsf@gnus.org> <459A0475-E3E7-4159-82DF-93809CCF1E24@gmail.com> <87eehng52n.fsf@gnus.org> <87mtwbye5b.fsf@gmail.com> <87czx7ycva.fsf@tcd.ie> <87eehmyalr.fsf@gmail.com> <877dneoewi.fsf@tcd.ie> <875z2yy6z7.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17897"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 12 08:11:40 2021 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 1lASc6-0004ZU-Vw for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 08:11:38 +0100 Original-Received: from localhost ([::1]:60336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lASc6-0005y3-2Y for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 02:11:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lASaS-0005O2-JZ for emacs-devel@gnu.org; Fri, 12 Feb 2021 02:09:57 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60763) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lASaS-0005RJ-Cs; Fri, 12 Feb 2021 02:09:56 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1304 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lASaO-00065w-Rd; Fri, 12 Feb 2021 02:09:56 -0500 In-Reply-To: (message from chad on Thu, 11 Feb 2021 14:18:27 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:264458 Archived-At: > From: chad > Date: Thu, 11 Feb 2021 14:18:27 -0800 > Cc: "Basil L. Contovounesios" , Yuan Fu , Alan Third , > emacs-devel , Stefan Monnier , > Lars Ingebrigtsen , Eli Zaretskii > > In more pragmatic terms, I would guess that it's entirely possible to excise motif/lesstif, athena, and Xaw3d > from main without anyone noticing. Whether this is worth the effort in a world leaning ever so slowly towards > Cairo and pgtk is a little hard to tell, but a quick grep through src suggests that it would at least clear up a > bunch of #ifdef spaghetti. > > Would the maintainers be interested in a branch that tried this? Would it be better to wait for pgtk to settle > first? Is there a big use-case for those toolkits of which I'm unaware? I'm not sure I understand how a branch could help. A branch is generally used by significantly fewer people than the master branch. A branch that doesn't bring any new user-visible features, and just cleans up code, is unlikely to provide motivation for anyone to try it. So I'm afraid such a branch will just sit there unused, and will not bring us any closer to a decision. I think if we want to move towards removing those toolkits, we should try a different approach. Two ideas: . analyze the bug report in debbugs DB, and see how many builds are with any of these toolkits . look at GNU/Linux distros and see if they still provide builds with any of these toolkits, and what was the last version of Emacs when they did We should also somehow analyze the usage of these toolkits on other Posix platforms, although I'm not sure I know how -- do they offer distros similar to GNU/Linux? if so, we could include them in the 2nd item above. Once we have an idea about the usage and popularity of each of these toolkits, we could decide what changes are reasonable, and make them on master.