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 09:43:43 +0300 Message-ID: <83wnadcajk.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8103"; 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 08:47:11 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 1oWXnC-0001p3-MS for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Sep 2022 08:47:10 +0200 Original-Received: from localhost ([::1]:60884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWXnB-0001A9-54 for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Sep 2022 02:47:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWXk5-0007yQ-8A for emacs-devel@gnu.org; Fri, 09 Sep 2022 02:43:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38812) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWXk4-00076h-7v; Fri, 09 Sep 2022 02:43:56 -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=W05u9W28cwARfvA/ODZ2qEQdDsXUNYztIhi/QXqIEm8=; b=a8vKotrkxyHD nO99CgtXydnabtsRDFY1yR0XIePrvJQb+7QXKjxjcr2iz03RXsZY0AiNGCRrfauakY/u9BDxfk6Wm 6HO8C7tc29RS9kKUrSbvLoHGuMdbyvzXsoGLMrzD/W2CR76evpEEzAERrrUNR7g6lDjiMBhIrdxBz UBcF9qWmtENOOp1P+vZY1r6yHsxqxq/SWDya2rDbeU8HHUzOp5L8TD0QWxkggpbNOztlTQ08/xDBj yJ8ex3RppTLTF2cnH7P6Zx5wV6UaZcdw31EHdXjxOWoxiFqDn/wBLFpt2m2qWG39l/LOJmSGtvsO+ AoPRot2LokZmF9lvCzeXQQ==; Original-Received: from [87.69.77.57] (port=3388 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 1oWXk3-0006i9-N9; Fri, 09 Sep 2022 02:43:56 -0400 In-Reply-To: <87zgf9ax01.fsf@mail.jao.io> (message from Jose A Ortega Ruiz on Fri, 09 Sep 2022 07:21:34 +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:295039 Archived-At: > From: Jose A Ortega Ruiz > Cc: tom@logand.com, emacs-devel@gnu.org > Date: Fri, 09 Sep 2022 07:21:34 +0100 > > On Fri, Sep 09 2022, Eli Zaretskii wrote: > > >> From: Jose A Ortega Ruiz > >> Cc: emacs-devel@gnu.org > >> Date: Fri, 09 Sep 2022 00:32:32 +0100 > >> > >> also, a term emacs running inside kitty or foot in wayland is very > >> noticeably faster than the graphical counterpart > > > > That advantage will almost certainly go away, at least partially, > > if/when we implement the new backend as proposed by Gerd, because some > > of that advantage is due to the simplicity of the TTY frame geometry > > and text layout, something that will be lost as soon as we support > > variable-height screen lines on TTY frames. > > hmm. in the image display protocol that kitty supports, everything can > be done, if desired, in terms of rows and columns, and the terminal > itself works, as far as i understand, in terms of character cells: > couldn't we retain that modus operandi? I think you misunderstand what Gerd proposed. He proposed abandoning the fixed-line-height assumption of the text-mode layout calculations. Thus, TTY frames could have screen lines of variable height, although their granularity will still be the height of the TTY character cell. Once screen lines are of variable height, some of the advantages of TTY display go away, because we no longer can assume that the next or previous screen line is exactly one character cell away. > for instance, displaying an image would amount (logically) to > displaying a bunch of lines of text, all of the same length, with > the only peculiarity that maybe the cells on the borders wouldn't > look completely filled. That won't work, because Emacs must know the screen layout; you cannot lie to it with impunity. For example, with your idea above, if point is in the first line of a window, and you type C-n, and the next line displays an image which takes more than one character cell's height, then what will be the line number, as it's known to Emacs, when point moves to that second line? If you tell Emacs that there are 10 lines of text in-between, instead of a single tall line, Emacs will think the next line is line 11, whereas from the user POV it's line 2. A lot of Emacs features depend on Emacs knowing exactly what's on the screen, so you cannot easily lie to it about that.