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: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Thu, 03 Dec 2020 17:13:08 +0200 Message-ID: <83k0tygby3.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <86tutfwhr6.fsf@akirakyle.com> <87h7pfb76z.fsf@gnus.org> <86h7peqkt5.fsf@akirakyle.com> <83tutdsc8i.fsf@gnu.org> <86eeker01y.fsf@akirakyle.com> <83wny5naf5.fsf@gnu.org> <86o8jh9cij.fsf@akirakyle.com> <83czzwkmwk.fsf@gnu.org> <86lfeja49y.fsf@akirakyle.com> <87czzu7y5r.fsf@logand.com> <86zh2vvi55.fsf@akirakyle.com> <87ft4ncnl7.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36146"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akira@akirakyle.com, emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 03 16:14:55 2020 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 1kkqJr-0009GU-1e for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 16:14:55 +0100 Original-Received: from localhost ([::1]:56122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkqJq-0003p9-2e for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 10:14:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkqIY-0002qL-8e for emacs-devel@gnu.org; Thu, 03 Dec 2020 10:13:34 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45123) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkqIT-0005fO-HW; Thu, 03 Dec 2020 10:13:33 -0500 Original-Received: from [176.228.60.248] (port=1643 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kkqIS-0007I2-Tc; Thu, 03 Dec 2020 10:13:29 -0500 In-Reply-To: <87ft4ncnl7.fsf@logand.com> (message from Tomas Hlavaty on Thu, 03 Dec 2020 09:15:16 +0100) 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:260222 Archived-At: > From: Tomas Hlavaty > Date: Thu, 03 Dec 2020 09:15:16 +0100 > Cc: emacs-devel@gnu.org > > > It seems like unless you're going to teach Emacs to entirely draw > > itself to the framebuffer, there will always be glitches like the > > cursor messing up images since TUI Emacs won't be aware of what pixels > > of the framebuffer have been drawn over independently of the linux VT > > displaying lines of Emacs' characters. > > The cursor could be turned off. > > Are there other glitches which cannot be solved? Even turning the cursor off doesn't guarantee that Emacs will not trigger overwriting of the images. For example, sometimes Emacs moves the cursor by writing newline characters, which could potentially overwrite the image if the console implements that by writing spaces or clearing each line to EOL.