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: Implementing image support for kitty terminal Date: Fri, 09 Sep 2022 19:15:27 +0300 Message-ID: <83wnacbk2o.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10999"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tom@logand.com, emacs-devel@gnu.org To: Jose A Ortega Ruiz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 09 18:18:21 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 1oWghw-0002eD-Q6 for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Sep 2022 18:18:21 +0200 Original-Received: from localhost ([::1]:40892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWghv-0001Yi-Lz for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Sep 2022 12:18:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWgfN-00006N-49 for emacs-devel@gnu.org; Fri, 09 Sep 2022 12:15:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36666) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWgfM-0004Tc-6P; Fri, 09 Sep 2022 12:15:40 -0400 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=CanSMImxnCrhmGLjZBge3V8XIZre150w8T0x9q8pGBU=; b=OPawtg2NT5lv G9RH4JOGT2v85xzy5PbEzyYY2Amn/bIAnYJCdQ50trwTX7irZPmGZZzVYLV4kwyLEI7jYcHweRJOZ QTKpZ0fBJwf8FJHr6LINiqSZ4CvLwnhrPQGYlNgkQHZM4VTCM4SfyHLcNzhsCKA1LnF+cf2yYznc9 lDnOGMS8GW4sx0Dtp86S7Zc5+4VdnkClGYXF8Q15oc+91kz9Bs6uyN7j0GswbkNT1Fw17jAJR12K5 wzJSHEG/hvImv47KYqLZEWDTAuqp60+ATUcS9iEmP11TZfEttYuKmpLYEp1wWFSEkifW3rg88BxW2 XmGy1WJdui1OLDkl0fKLpQ==; Original-Received: from [87.69.77.57] (port=3067 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 1oWgfH-0003uK-35; Fri, 09 Sep 2022 12:15:38 -0400 In-Reply-To: <87wnacbnq4.fsf@mail.jao.io> (message from Jose A Ortega Ruiz on Fri, 09 Sep 2022 15:56:35 +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:295082 Archived-At: > From: Jose A Ortega Ruiz > Cc: tom@logand.com, emacs-devel@gnu.org > Date: Fri, 09 Sep 2022 15:56:35 +0100 > > Say that, in that line, i have an image, which emacs knows about because > there's, say, a text property with 4 rows x 5 columns as the image > extent (which we derive from knowing the image size and the terminal > cell size, in pixels). For movement and display purpose, we tell Emacs > to interpret that as the block of pure text > > xxxx > xxxx > xxxx > xxxx > xxxx > > and emacs, initially, displays that, as a normal tty would, with point > at the beginning of the block. Now, it computes how many lines are > visible after any required scrolling, and then asks kitty to draw, on > the visible rectangle, the corresponding part of the image. > > All movements and positioning would happen as if all that is being > displayed are blocks of text. Of course that means that line numbers > won't treat images as spawning just one line, but several. I find that > actually an advantage from the user's point of view, because the images > are taking more than one line in the glass, so to me it's very natural > that emacs tells me that, at the beginning of the image, line is no. 2, > and, at the end, line is no. 20. 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? 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? > 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.