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: Wed, 07 Sep 2022 21:09:40 +0100 Message-ID: <875yhzymij.fsf@mail.jao.io> References: <87v8pz18wf.fsf@mail.jao.io> <83o7vrgimc.fsf@gnu.org> <87fsh3yq81.fsf@mail.jao.io> <837d2fgef0.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="5389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 07 22:11:27 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 1oW1OQ-0001Hi-6j for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Sep 2022 22:11:26 +0200 Original-Received: from localhost ([::1]:41504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oW1OO-0007kI-I3 for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Sep 2022 16:11:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oW1Mm-0006uQ-7B for emacs-devel@gnu.org; Wed, 07 Sep 2022 16:09:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oW1Ml-0003LC-Ge; Wed, 07 Sep 2022 16:09:43 -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=wIpS5Lt3ylmUH5SMw9xFknelyzh50k8ekj8kS8AM2xU=; b=ksYPhB8ClouhYMXWg9xW f/uxKPmPsWUECcms2NXCaeocNc1BubAxBaFA1RyeeDDy945a2+GLmRFg40nhnEB1dKOOCtjTrkE/0 yl56VO3K+/EITIGyoUymlLJ/lTm8nPgfRaKV4wyG1uqHmzBKo9Mi+3sG7PfNxk3Dzi6OwIARRITxe cAX+ekbWeZK5bdBpFJUAwUnm5PV25r3ppwU0pQPMNrGu6n4YSTUi8mpsdZv8zDvxL5MT0EQIE85IR jSuowqhWG8HH1U5XnXhGgHbno/PbxS09eX1RYxAhqYNpqLjMezBtcyha154/nXS3LFbei+l9EG/G8 ORRSkJq8H3/eOA==; Original-Received: from cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net ([92.233.85.247]:46018 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 1oW1Mk-0004C2-KK; Wed, 07 Sep 2022 16:09:43 -0400 Original-Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 2ffcdf78; Wed, 7 Sep 2022 20:09:40 +0000 (UTC) In-Reply-To: <837d2fgef0.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:294877 Archived-At: On Wed, Sep 07 2022, Eli Zaretskii wrote: [...] > This is a different level: the level of actually delivering the stuff > to the glass. I think it's much easier than what was bothering me. I > was talking about the level of layout: the one that knows how much > space each "display element" (character, image, stretch of white > space, etc.) takes on display. On TTY frames, there's a built-in > assumption that every display element takes just one pixel in the > vertical direction, and each screen line takes one pixel on display. > That will have to change for image support, I presume. in x terminal emulators, by "pixel" here you mean one terminal "cell" (the extend of a displayed ascii char), right? >> I am assuming here that the display engine (for a tty) knows somehow >> that it's printing a very lage "character" that is going to spawn >> several rows and columns, and also that we can always tell how wide and >> tall the window around point is when we display this "character". > > That's exactly the problem: it currently assumes that no display > element takes more than one row, and that each row is exactly one > pixel (= one character height) tall. aha, i see. so what's needed, for instance, is a way of managing blocks of such display elements, that are always rendered all at once... or are there better ways of accomplishing the same? jao -- Be regular and orderly in your life so that you may be violent and original in your work. -Gustave Flaubert, novelist (1821-1880)