From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jimmy Yuen Ho Wong Newsgroups: gmane.emacs.devel Subject: Re: Need `truncate-string-to-pixel-width` and `glyph-pixel-width` functions in C Date: Wed, 23 Oct 2024 14:52:53 +0100 Message-ID: References: <86sesndz8v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f0b2a606252535ad" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37385"; 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 Oct 23 15:54:16 2024 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 1t3boW-0009ZZ-7K for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Oct 2024 15:54:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t3bnq-00033A-Q4; Wed, 23 Oct 2024 09:53:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3bno-000328-N8 for emacs-devel@gnu.org; Wed, 23 Oct 2024 09:53:32 -0400 Original-Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t3bnn-0007iZ-1Y; Wed, 23 Oct 2024 09:53:32 -0400 Original-Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6cb82317809so44272956d6.0; Wed, 23 Oct 2024 06:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729691609; x=1730296409; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EmjTKVeR9JSDF0tt4h6oFZla9T15b87xAVFnzBAEEDA=; b=USa7YSupsVyxMHwQkzTkkjvPMBSDBPjwD5nELKuHIfaVsiyo3dv5Qlyht3OyTKjGaq kkRwLNgu11+UpwriRHScKPZIJmEPcpdbkA30s0Ad80euz2Gtc1ZJB2O0LTbt4gFb53LJ TaSmBLBkYRTLqMvXnBqguBzMEYT8FDu2agqLOxnAJ/O6KymeeF1OEdGhhEfSLOiHILxm kRnux7VANldsc6Bfc0HjLoFZbAwy1ENgi+z77ybXiT/zLI17aS9Lw+9Evk/LJPhkgQRV UWYXaFcknG9ore+g5xxY7NZFpJJl8oYUs1WPWlJIb1tB2bSRWA/HC+zi8s4Y9irOt1XW mtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729691609; x=1730296409; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EmjTKVeR9JSDF0tt4h6oFZla9T15b87xAVFnzBAEEDA=; b=oDqX8P6d7X4YX4XwO+T2oho04vUaip02emJ9VLwDItl2jmFL5m+GHJHInEPjJNj2l3 2C6UcL/2McLT5HnQ/lVUX4RvaugItnpU4qQvHNVB2l+rkYupKfzEPM/HL7AHE0wQo0sI S/60IUzx+EvwmkaZZ4den2A9tOrH7kZhmE9xcxr2qgE8lEtPD9t2a8WlmdAiBo1op0iH Tt279P197FEFDa/nta7vBkRopfYprSucRPWmh4SuKqqoP2Hm/nqDttXUGs0joSsBRoAE MjiCSmDca5GTivcU6HQGAlpwzyj9bjmEUH3CYdVzuKRibc5z2c8pCo3843Pdnnsg+Wtg zI/w== X-Gm-Message-State: AOJu0Yz6mba9R4zqfm8KoHAveAK12sx5FMCqJ1mBZs/LFR1Caq84ijQO vTKDk4fwh3j7I6FzQsXi28LzpwLyqthOD0c5GbuQbXygPMgrv+nMT5TgQURONBWrisKL0skpAzc tsuI8XXLOJhoTx/M2E7h5RC8Qcy7L5cE1 X-Google-Smtp-Source: AGHT+IGASqsvfC2Yvt+Tu/f4U2JDMS6mKMHECTEdpKfgHdc0dlsJi1uvFJaQuEfOhsZosKFTOsYU52zDtFdKHW/aNRw= X-Received: by 2002:a05:6214:5c42:b0:6ce:26d0:c7b4 with SMTP id 6a1803df08f44-6ce342f3731mr29560036d6.44.1729691609245; Wed, 23 Oct 2024 06:53:29 -0700 (PDT) In-Reply-To: <86sesndz8v.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::f36; envelope-from=wyuenho@gmail.com; helo=mail-qv1-xf36.google.com 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324790 Archived-At: --000000000000f0b2a606252535ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 23, 2024 at 9:01=E2=80=AFAM Eli Zaretskii wrote: > I know next to nothing about Corfu, so I have hard time understanding > what you are trying to do and why. Basically, the Emacs display > engine already truncates stuff it displays, so it is completely > unclear to me why you'd need to do that in Lisp. > Corfu is like Company, it's a completion frontend that formats a list of completion candidates to fit inside a confined pop up box. > In particular, "truncate strings in pixel precision" makes no sense to > me, since strings on display are made of characters (more accurately, > "grapheme clusters"), so any reasonable truncation will always work at > the grapheme-cluster granularity, not at pixel granularity. > As described, `truncate-string-to-width` doesn't even truncate at grapheme cluster granularity correctly. A `truncate-string-to-pixel-width` function is needed because propertized strings may consist of display space text properties, images, emojis in a different font, and faces in variable fonts, which all affect glyph widths, you can't simply assume every glyph will take up 1 column. As a result, when you calculate some `end-column` and whether it has reached the width constraint in pixels, one would necessarily need to know the exact width in pixels for each glyph. Converting the width constraint in pixels to columns in order to supply it as the second parameter to a correctly implemented `truncate-string-to-width` amounts to the exact same procedure. Therefore, either a `truncate-string-to-pixel-width` or `glyph-pixel-width` function is needed, because `string-pixel-width` is very expensive. --000000000000f0b2a606252535ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 23, 2024 at 9:01= =E2=80=AFAM Eli Zaretskii <eliz@gnu.org<= /a>> wrote:
I know next to nothing about Corfu, so I have hard time understanding
what you are trying to do and why.=C2=A0 Basically, the Emacs display
engine already truncates stuff it displays, so it is completely
unclear to me why you'd need to do that in Lisp.
<= br>Corfu is like Company, it's a completion frontend that formats a lis= t of completion candidates to fit inside a confined pop up box.
=C2=A0
In particular, "truncate strings in pixel precision" makes no sen= se to
me, since strings on display are made of characters (more accurately,
"grapheme clusters"), so any reasonable truncation will always wo= rk at
the grapheme-cluster granularity, not at pixel granularity.

As described, `truncate-string-to-width` doesn't e= ven truncate at grapheme cluster granularity correctly.

A `truncate-= string-to-pixel-width` function is needed because propertized strings may c= onsist of display space text properties, images, emojis in a different font= , and faces in variable fonts, which all affect glyph widths, you can't= simply assume every glyph will take up 1 column. As a result, when you cal= culate some `end-column` and whether it has reached the width constraint in= pixels, one would necessarily need to know the exact width in pixels for e= ach glyph. Converting the width constraint in pixels to columns in order to= supply it as the second parameter to a correctly implemented `truncate-str= ing-to-width` amounts to the exact same procedure. Therefore, either a `tru= ncate-string-to-pixel-width` or `glyph-pixel-width` function is needed, bec= ause `string-pixel-width` is very expensive.

--000000000000f0b2a606252535ad--