From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add function window-line-width Date: Thu, 14 Nov 2019 12:08:24 +0200 Message-ID: <83lfsi7otj.fsf@gnu.org> References: <8846a8ad-0299-1ff7-cc9a-0aaed18e76c0@gmx.at> <125a5b4a-5ac8-426f-5762-af0e91962c78@gmx.at> <83ftiycxrl.fsf@gnu.org> <2fd8c643-af51-9d98-522e-81180a3736f2@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183321"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: =?utf-8?Q?S=C3=A9bastien?= Chapuis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 14 11:09:42 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iVC4K-000lYU-RE for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 11:09:40 +0100 Original-Received: from localhost ([::1]:55286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVC4J-0005LI-DQ for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 05:09:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43195) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVC3N-0005Gr-S8 for emacs-devel@gnu.org; Thu, 14 Nov 2019 05:08:42 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVC3N-0005VY-LI; Thu, 14 Nov 2019 05:08:41 -0500 Original-Received: from [176.228.60.248] (port=1750 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVC3M-0002VX-CQ; Thu, 14 Nov 2019 05:08:41 -0500 In-reply-to: (message from =?utf-8?Q?S=C3=A9bastien?= Chapuis on Mon, 11 Nov 2019 03:02:23 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:242141 Archived-At: > From: Sébastien Chapuis > Date: Mon, 11 Nov 2019 03:02:23 +0800 > Cc: Eli Zaretskii , emacs-devel@gnu.org > > > There's always the problem that we want to reserve space for a block > > cursor at line end. > > IMO that's a case that should be handled by the user of the function, not by 'window-lines-pixel-dimensions' > itself. How can application code do anything like that? The glyph matrices aren't (and shouldn't be) exposed to Lisp. > In my few tests, 'window-lines-pixel-dimensions' returns a width with 1 and 2 glyphs more, so it's not just 1 > space for the block cursor, > there might be cases where there are more glyphs added (?). Please show those test cases. It is hard to have an effective discussion without seeing the actual use cases being mentioned. > And AFAIK, there is no way to know how many glyphs/pixels the redisplay add. The display engine does know that, of course. > Anyone who wants to have an accurate number of pixels displayed will be unable to use this function. That's a pretty string assertion; the fact that we do use the function in our own code seems to contradict it. > > Then we probably should rewrite 'window-text-pixel-size' as Eli > > suggested earlier. > > Agreed, but I would prefer to use 'window-lines-pixel-dimensions' since this is exactly the function I need. > As per the documentation [1]: > `window-text-pixel-size treats the text displayed in a window as a whole and does not care about > the size of individual lines. The following function [window-lines-pixel-dimensions] does.` What is missing in window-lines-pixel-dimensions to make it satisfy your use cases, and why? I think it will be a better fix for your needs, given the problems you have with window-lines-pixel-dimensions, and I don't think we should change the latter in radical ways.