From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?S=C3=A9bastien_Chapuis?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add function window-line-width Date: Mon, 11 Nov 2019 03:02:23 +0800 Message-ID: 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: multipart/alternative; boundary="00000000000067706a059702a831" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="201030"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 10 20:03:23 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 1iTsUc-000q9i-C7 for ged-emacs-devel@m.gmane.org; Sun, 10 Nov 2019 20:03:22 +0100 Original-Received: from localhost ([::1]:44662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTsUb-0007yJ-6g for ged-emacs-devel@m.gmane.org; Sun, 10 Nov 2019 14:03:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34682) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTsTt-0007y5-UR for emacs-devel@gnu.org; Sun, 10 Nov 2019 14:02:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTsTs-0002Qd-IU for emacs-devel@gnu.org; Sun, 10 Nov 2019 14:02:37 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:36537) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iTsTs-0002Q4-4U for emacs-devel@gnu.org; Sun, 10 Nov 2019 14:02:36 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id r10so12326973wrx.3 for ; Sun, 10 Nov 2019 11:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chapu-is.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n7cSCfndWBVCxWCh55Fq+5taIt3OCrC3FliU4+1OPcc=; b=fEhsyMG9u9YcyVNAxYB4KYZdrVIhLVOfwGQnaRTRJSR+EJTu0NhrOpwqrF65oOnKpS HmQ1njOmOmZnB2Y2C0lkcwzG8XxaMTuVx9310NdyhERpiZot9p/7wvtgE2cvPIeI2Wm4 JGxrq7OJ+TLHbMwlX4U9/qfJJi75NtjLBaQTdDtdZI3SoZNpTfcFScLSMLPaNGWRld2d LwuE8xKaICoqevFZLaVUCwjgnri9QfcGRQDbAT8RTf2/TY4ixadbQY2y56cK/6PMnYfH 4jVFHIWNAsr5rF1xfmt/0i++r5GHqNG7hl9wzQw4bhchnW2Z3BMCXPucUnyPLRrgamnc quLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n7cSCfndWBVCxWCh55Fq+5taIt3OCrC3FliU4+1OPcc=; b=aJurXS1aGMnvNhACm4NgCrO4ihtIzmj1TSoi2TN6N8bqxx0akxKyU0sBsmw0TK1JuK dvL6O5DLEtF+J6YW6W7+zOxXVM/fgB1wOhJ63CeKB8th/nIZBTpfPsM7GeLW69+nsPjz O+jMg4RDdpRtoVCom04TAIzm3tkNASSlfkiXlnJSxN6VKyA3JJXm7Y39m+h0O5hZe9NW M/3R9+aHgm8PT06esdLA8j2OsF8ahzQTPj1uUVm7tIguDAoHW0hHrp8ymiZQRaVkcFyj ymQZSsGtdJH5iR0WCX+RkUtNagiQgH+ErXbTlou2vjQoT6kYdgJO2mUdDgM0qe5iloDj TC5Q== X-Gm-Message-State: APjAAAXdfUubuLAsaZ4ARaEJ/h96z2+cXsJcMx9RHGrF9Rp/3LL2fqZ0 Ivm3fV+FPgMzDuSrJzxip8/xcEaswp/bOnUpAnq/UA== X-Google-Smtp-Source: APXvYqwnVHwGBiYXe7VbBMPASYWJiqrYMDl7v9QlIkfLEzJSxCgVtOFL6O+Fjut6rj7Y6Ou30+hifaiKPyl/iVSD8us= X-Received: by 2002:adf:f80c:: with SMTP id s12mr17086991wrp.37.1573412554627; Sun, 10 Nov 2019 11:02:34 -0800 (PST) In-Reply-To: <2fd8c643-af51-9d98-522e-81180a3736f2@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42e 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:242074 Archived-At: --00000000000067706a059702a831 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. 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 (?). And AFAIK, there is no way to know how many glyphs/pixels the redisplay add= . Anyone who wants to have an accurate number of pixels displayed will be unable to use this function. > 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.` [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Size-of-Displayed= -Text.html#Size-of-Displayed-Text Thanks, Sebastien Chapuis. Le dim. 10 nov. 2019 =C3=A0 17:46, martin rudalics a =C3= =A9crit : > > A line with X characters should have the width of all thoses character= s. > > I see that 'window-largest-empty-rectangle' uses this function, the > widths > > of the rectangles it returns are smaller than they really are. > > There's always the problem that we want to reserve space for a block > cursor at line end. > > > I tested the following code: > [...] > > `(time (test1))` returns 0.000004869 > > `(time (test2))` returns 0.00376 > > Then we probably should rewrite 'window-text-pixel-size' as Eli > suggested earlier. > > martin > --00000000000067706a059702a831 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There's always the problem that we want to reserv= e 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 &#= 39;window-lines-pixel-dimensions' itself.
In my few tests, &#= 39;window-lines-pixel-dimensions' returns a width with 1 and 2 glyphs m= ore, so it's not just 1 space for the block cursor,
there mig= ht be cases where there are more glyphs added (?).
And AFAIK, the= re is no way to know how many glyphs/pixels the redisplay add.
An= yone who wants to have an accurate number of pixels displayed will be unabl= e to use this function.

> Then we probably shou= ld rewrite 'window-text-pixel-size' as Eli
> suggested earlie= r.

Agreed, but I would prefer to use 'window-lines-pixel-d= imensions' since this is exactly the function I need.
As per the doc= umentation [1]:
`window-text-pixel-size treats the text displayed in a w= indow as a whole and does not care about
=C2=A0the size of individual li= nes. The following function [window-lines-pixel-dimensions] does.`

[= 1]=C2=A0https://www.gnu.org/s= oftware/emacs/manual/html_node/elisp/Size-of-Displayed-Text.html#Size-of-Di= splayed-Text

Thanks,
Sebastien Chapuis.


Le=C2=A0dim. 10 nov. 2019 =C3=A0=C2=A017:46, martin r= udalics <rudalics@gmx.at> a = =C3=A9crit=C2=A0: