From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: xenodasein--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Implementing image support for kitty terminal Date: Sat, 10 Sep 2022 13:06:51 +0200 (CEST) Message-ID: References: <83y1ura4zy.fsf@gnu.org> Reply-To: xenodasein@tutanota.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15343"; 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 Sat Sep 10 13:19:02 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 1oWyVq-0003rM-0W for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Sep 2022 13:19:02 +0200 Original-Received: from localhost ([::1]:57208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWyVo-0007mc-EE for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Sep 2022 07:19:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWyK6-000506-Ux for emacs-devel@gnu.org; Sat, 10 Sep 2022 07:06:58 -0400 Original-Received: from w4.tutanota.de ([81.3.6.165]:59692) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWyK5-0001HA-2C; Sat, 10 Sep 2022 07:06:54 -0400 Original-Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 511C21060164; Sat, 10 Sep 2022 11:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1662808011; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=0qkbsxy7MkfzGRnZr3F3/9sSqmdzxEShG8DFh1MThnQ=; b=rvLTiM7GTOHuWn5V51WjsUjjQPo/nzYAUCO8F55hzh73DiJDNQuJ63/i3VClxRGo F4cE8XUZKcsk2wsdbtX5TXS1uef5+mhPtEzZM9hC4s74zHE1BqaZawVvH2V6uVY/+QH xC6fuxrGndH6NFI/vTBJ5pxnWftAgZFBZL4F1egmm64Cxbnx//cTQq67kc2ZyMmDCpE t9wPRJ3CfreK1K0Dz3B36/1KM/8Wx3fT+AHOgShQAShH5BiQs2QKwH0jcMQOhjCnqVO VUwbaEqfvfh0BQCZ3sTkKU/nd7ycz+FROdcl48N5d6faWY5fACPyybFkWEmAv75f0zL Jv8aZBGvEw== In-Reply-To: <83y1ura4zy.fsf@gnu.org> Received-SPF: pass client-ip=81.3.6.165; envelope-from=xenodasein@tutanota.de; helo=w4.tutanota.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 10 Sep 2022 07:18:02 -0400 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:295119 Archived-At: >> Are you considering to change the text terminal infrastructure for >> Emacs just to accommodate one wayward desktop app that claims to be >> a terminal and a Kindle at the same time? > Possibly. However, at least one proposal for implementing that leaves > most of the infrastructure intact. ... > If someone comes up with a suggestion for how to refactor the display > code to make its maintenance easier, I think we will welcome that. > But we cannot reject other enhancements because of the complexity of > what we have. That complexity didn't prevent us from implementing > several display-related enhancements in the recent years, and I don't > see why this particular one should be an exception. I guess the hard part is to balance the amount of new enhancements to not build up to a point where it isn't too big of a deterrent to a possible future, uh, modernization?=C2=A0 If supporting Kitty is easy within the current framework, why not; this sounds too good though.