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: Platform independent graphical display for Emacs Date: Sat, 25 Dec 2021 15:08:06 +0200 Message-ID: <83czlkrfwp.fsf@gnu.org> References: <87ilvgwfor.fsf@telefonica.net> <834k6zwvi1.fsf@gnu.org> <87h7azilmu.fsf@yahoo.com> <87sfujh4a2.fsf@yahoo.com> <877dbuhm6j.fsf@yahoo.com> <87tueyg5gc.fsf@yahoo.com> <83y24asbh4.fsf@gnu.org> <83tuexqh7w.fsf@gnu.org> <9c04ef31-96e0-1874-7385-633435a28b5f@yandex.ru> <83lf08rk27.fsf@gnu.org> <2ac64757-b8f7-e60a-4d3d-51aa1a13c812@yandex.ru> <83ilvcris5.fsf@gnu.org> <6db252bf-7f0a-5c9e-544e-f2fccb488f82@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11700"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, stefankangas@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 25 14:08:54 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 1n16n8-0002o5-Ed for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 14:08:54 +0100 Original-Received: from localhost ([::1]:38092 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n16n6-00025f-F2 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 08:08:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n16mB-0000l0-H6 for emacs-devel@gnu.org; Sat, 25 Dec 2021 08:07:55 -0500 Original-Received: from [2001:470:142:3::e] (port=49054 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n16mA-0001VP-Ti; Sat, 25 Dec 2021 08:07:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9NwENISJIewmftEsYrW5lepchS0MOIIhZFZsKZ2R2fg=; b=XtCAUv5vOhtN 4YYyd9H86RiZPs7bWawkGv1558nvIHBgtJSoxilhjo/ur+20RjE6f98GWa05fR6Yl1Jr5LqdQt9wn 9R5+Zer2U07RY2TnseW3pPM/9GBsWCdtYiyhz36QptJ/WX6I+LxQ/f/H/LoKhRDC8O0sqY/lBn/F4 vdsrUI6oH0sKOd+gNBqyWad78GPv+br+tRqp3uZinoN/F2AHRxkZ2q5OAw7E1SazSTaOIyIm5w/tt 0cBf2WZt6Tp+jHN4bT5fsjI6vGeV4hkPsmm2b+aJR0a4dlcf+fLsU+ifriR0TRBJV44wvbpj0viO6 PEVRvmGzzIjn5UAiKTSdwg==; Original-Received: from [87.69.77.57] (port=4687 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 1n16mA-0006el-SR; Sat, 25 Dec 2021 08:07:55 -0500 In-Reply-To: <6db252bf-7f0a-5c9e-544e-f2fccb488f82@yandex.ru> (message from Dmitry Gutov on Sat, 25 Dec 2021 14:59:34 +0200) 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" Xref: news.gmane.io gmane.emacs.devel:283214 Archived-At: > Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 25 Dec 2021 14:59:34 +0200 > > > Because we did have someone who volunteered, and because nothing would > > be lost on platforms of interest to us if the BeOS port bitrots. > > Which would be also true when someone initially proposes the new "single > toolkit" port for inclusion. No, it won't. The "single" part makes the crucial difference. > > Once again, a single toolkit on which all the platforms depend cannot > > be dropped. So it's a huge difference from the BeOS port. > > Once again: we would only get to that point after the "single toolkit" > port is functional, accepted by the majority of us, and probably > "adopted" by a few regular contributors as their area of interest. > > Only then we could realistically vote to drop all other ports. You are responding to what I wrote on the assumption that this was being proposed up front. > I'm sure a contributor who would propose such new port would understand > all of this. That wasn't my understanding. > > That's generally not a practical possibility, because the code changes > > very rapidly, and what you revert won't even compile in most cases. > > Yes and no: I'm sure having the previous code available will be a lot of > help. As opposed to rewriting the same port from scratch. Much more is needed than just the code which at some point did work.