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 16:36:44 +0200 Message-ID: <83a6gorbsz.fsf@gnu.org> References: <87ilvgwfor.fsf@telefonica.net> <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> <87o854swp2.fsf@telefonica.net> <87lf0898b7.fsf@yahoo.com> <87k0fssufl.fsf@telefonica.net> <83bl14rfbd.fsf@gnu.org> <87bl14srou.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 25 15:37:23 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 1n18Ak-00012Y-P4 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 15:37:22 +0100 Original-Received: from localhost ([::1]:50782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n18Ai-0002Nf-T5 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 09:37:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n18A0-0001hf-6f for emacs-devel@gnu.org; Sat, 25 Dec 2021 09:36:36 -0500 Original-Received: from [2001:470:142:3::e] (port=51024 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 1n189z-0007WQ-LC; Sat, 25 Dec 2021 09:36:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3dhFdzP+ALW8iC3/7ECdnp/0iDQ72NxymoH6tND7C4U=; b=gXkfuIIRztaKXQ1TZ5si 2B5kGGCZX5qNGSnGsARZKM2lmVqXzvwYgqh0qj3ciANNzCSJfAUDO1uHS1EGzbCCf3OUaeH8vOYqJ NgMn/NsCXlpwvkLCd0GfwZjmWLH8dWNJ3ZVXJkSU4ptee16wh9LS0FQjDxS1UhaGNr6NzZCZtAIdd lOIyOrp5K43fMpeP1H3B/qTivJzr9BVyCB+l+snczhk7sryGRHA4Cbp1hBN2zWIqgyWAQcXODgMD5 +2Rie8oj8KSWvdrdMxqBxm3ziH+y4753pfYOJcHCMmjAXEbh9PwBR+LV204VjyDArxPcrNuPUmqDM EE1CZlJSNFrZRA==; Original-Received: from [87.69.77.57] (port=2270 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 1n189z-0000P2-FK; Sat, 25 Dec 2021 09:36:35 -0500 In-Reply-To: <87bl14srou.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Sat, 25 Dec 2021 15:08:17 +0100) 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:283230 Archived-At: > From: Óscar Fuentes > Date: Sat, 25 Dec 2021 15:08:17 +0100 > > > If you think this kind of enhancement could materialize just by > > changing the *term backends of the Emacs display, you don't have a > > clear idea about the relevant architecture aspects of that. It is > > nigh impossible to do something like that without the knowledge of > > xdisp.c and dispnew.c. I'm telling you that as the single person > > around here who has any kind of practical experience in implementing > > something like that: the TTY menus do something very similar, and that > > code gets away by the skin of its teeth, and would be probably simply > > impossible with GUI display. > > > > Throwing around such ideas without any real knowledge is simply > > irresponsible. Someone might believe you and spend some non-trivial > > time trying to implement that. > > You are overthinking something that's actually very simple: locating the > x coordinate of the n-th column and drawing a vertical line from top to > bottom of the window on each redisplay. I think you have very inaccurate idea of what a redisplay cycle looks like. > If I were the hacker implementing the proposal, I would start with the > data structures that hold what needs to be shown and with a surface: > then, do the rendering. I know it is not as straightfordward as just > throwing a bunch of text on a textbox, but what I've seen on the sources > and your claims makes me think that any attempt at reusing the legacy > code (the one that actually paints the frame's contents) would be a > waste of time. You are actually talking about redesigning the current display engine. Which is a Good Thing, I think, because it was designed 23 years ago, and nowadays we clearly see its limitations. So please keep going with this, and hopefully we will have a new display engine capable of much more, and much better matching today's technologies and expectations. But saying that this can be done by just "drawing a vertical line" is inaccurate at best. > You are talking as if the complexity, quirks and limitations of Emacs' > display engine were something good, something to be preserved, when it > is quite the contrary, ever more when so few people understands it. No, I'm saying that we shouldn't pretend we can implement features like the one you mentioned without redesigning the display engine. Just changing or replacing its terminal-specific backend will not be enough. Which is why replacing the toolkit(s) should have quite a different perspective and different goals.