From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jose A Ortega Ruiz Newsgroups: gmane.emacs.devel Subject: Re: Implementing image support for kitty terminal Date: Sat, 10 Sep 2022 01:45:53 +0100 Message-ID: <87r10kawfy.fsf@mail.jao.io> References: <87v8pz18wf.fsf@mail.jao.io> <83o7vrgimc.fsf@gnu.org> <87wnafdnee.fsf@logand.com> <835yhzgdyi.fsf@gnu.org> <87k06den1s.fsf@logand.com> <87illxy5ir.fsf@mail.jao.io> <87sfl1d1wi.fsf@logand.com> <87czc5y1wp.fsf@mail.jao.io> <878rmtcwrv.fsf@logand.com> <87a679xx0v.fsf@mail.jao.io> <83zgf9cc9i.fsf@gnu.org> <87zgf9ax01.fsf@mail.jao.io> <83wnadcajk.fsf@gnu.org> <87wnacbnq4.fsf@mail.jao.io> <83wnacbk2o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4375"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tom@logand.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 10 02:47:49 2022 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 1oWoex-00010N-Q4 for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Sep 2022 02:47:48 +0200 Original-Received: from localhost ([::1]:40668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWoew-0000mM-KM for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Sep 2022 20:47:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWodE-0007vC-BK for emacs-devel@gnu.org; Fri, 09 Sep 2022 20:46:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37790) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWodD-0001ku-Cd; Fri, 09 Sep 2022 20:45:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=0J5pY7/51WHVQlU+EEUmcOZP50hCXlqT7kjx+NW5JYE=; b=TEezQBNJ3RXIk40QKUGX KMsB2wYPYpUCeejbjVw/yoOCam05C6vqk9sbk88+jNFDAA5CAJIYwHHBLgRkd3TFiHcvRCPTaB07f a0ikd/HX5/AbLONBr1q5M/J7Bq0ThDwwfYYKeXkVUNOahlovo10RgDm90Y63FBraKoEq2Z81l+lDs qS63WgPkcd0FOJvLpxQrOTZUjLOFCrDAYKirR9klRojSoFrKZXJwvpARoz7tAEmHCpGj0t3bSfjGb 2NcqzelSfU6fPEo/j8hvhEzk9QRibEhTVjfoljdBAnHW98ySZUSl6a1go2uJjmxTBo+uhA/d1emU9 GaEYn6qovNUy4A==; Original-Received: from cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net ([92.233.85.247]:51250 helo=rivendell.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWodC-0001N1-I2; Fri, 09 Sep 2022 20:45:59 -0400 Original-Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 0aecc521; Sat, 10 Sep 2022 00:45:54 +0000 (UTC) In-Reply-To: <83wnacbk2o.fsf@gnu.org> X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: 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:295095 Archived-At: On Fri, Sep 09 2022, Eli Zaretskii wrote: [...] > But you do want to support text and images in the same buffer, don't > you? So the following situation: > > tttttttttttttttttttt (1) > IIIIIII > IIIIIII > IIIIIII > tttt IIIIIII ttttttt (2) > tttttttttttttttttttt (3) > > where "t" is text is "I" is an image, should be supported, yes? no, not necessarily. i'd be already pretty happy even if that wouldn't be possible. for my uses cases, rendering that as > tttttttttttttttttttt (1) > IIIIIII > IIIIIII > IIIIIII > IIIIIII > tttt ttttttt (2) > tttttttttttttttttttt (3) would be good enough. moreover, there are few cases of images inserted by even current graphical emacs (at least in my use cases) with text flowing on the sides (i remember even having to advice eww at some point to get inline images). > So now, if point is on the top-most text line (1), and the user types > C-n, don't you want point to the text on the line that displays the > image, line (2)? This is what happens on GUI frames, and I very much > doubt that users will be happy to see the cursor somewhere between > lines (1) and (2). And even if they do like that, what would be the > position of point in that case, i.e. what will "C-x =" display? well, i cannot speak for other users. for me, something like the above, even if far from perfect, would be a big improvement over no images at all. >> Yes. I am proposing we tell emacs that what's on the screen is some >> lines of xs-text and making that, actually, true in every sense except >> that we also tell kitty to display those rows differently at the very >> end, when emacs is done with its text display duties. > > That will break too much of both user expectations and Emacs features, > whereby every position on the screen where we put the cursor has some > buffer address. What you suggest is a trick that may make display > easier (and I'm not even sure in this part), but it will require many > changes all over the rest of Emacs, because Emacs isn't prepared to > deal with such disconnect between the screen coordinates and the text > it displays. fair enough. that's the kind of warning i was looking for, to avoid wasting time chasing wild geese. if even an imperfect hack is going to need such an effort, it's not worth it. thanks, jao -- There are two ways to write error-free programs; only the third one works. - Alan Perlis, Epigrams on Programming