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 21:03:55 +0100 Message-ID: References: <86sesndz8v.fsf@gnu.org> <86ed46en1q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000db342106252a642c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16039"; 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 22:05:29 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 1t3hbl-00046g-5v for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Oct 2024 22:05:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t3hau-00073o-Mu; Wed, 23 Oct 2024 16:04:36 -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 1t3has-000739-TI for emacs-devel@gnu.org; Wed, 23 Oct 2024 16:04:34 -0400 Original-Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t3haq-0004vh-Ts; Wed, 23 Oct 2024 16:04:34 -0400 Original-Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7b147a2ff04so12254185a.3; Wed, 23 Oct 2024 13:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729713871; x=1730318671; 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=tSQvDgtMxS02Jd0LVaQ0CNGQHkptgsZhiavvnnzDGpc=; b=eDNKli0xaCQbBxFsjt/aYYdldUM8BhKmLjm4bsuQNYF0fTSYzelzfjhKIR9o1kEJGk TzLYPhM0DdDTTcz+9SyQvptKqfJKOB/8+KC7+3bTrSfkPPfWRf2O6q8dx02DdWNjk16n oOYr/Z/g1uDzlPGIv3h51ZpykEeOslFT2zPERbeNpV5SANlkz8/I5sFNlg3+BbtBJ547 mvrLNPIpBuJC/s50La7w0rVobslyTeCjIu9TOwXDnIZMYBJKYjqoDdnzQaCVoIuwuBSS /xxfbkso8FX7sLv57E0hoBMk8gkG4qZyYIQNUGRl3ycbPR4I0PTLVFJQZgnrM7lPgWCx tuPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729713871; x=1730318671; 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=tSQvDgtMxS02Jd0LVaQ0CNGQHkptgsZhiavvnnzDGpc=; b=Q8lQy4Ab3WZvesqSN27xMYvPLnAdiBWEFP1g9bQ4T5YGsKr0y6iTfzYT1euFkFG/qd A0h9wC5RWh5YCkypfa+bS3ZRQz0AfGReXa7bPcl/lAAXhbKuf3u5PcZg+HD0H6eOtPRO 8P6ikeShCQTxhhpNxLink2NcjuubqB4x2vDdms0o0q+4JSqjRlFgrf7/qFUvhLArxbkC VeLi9mb/ilg6/iAMaJtUoGUzHOWkvLa4H/cfjQ5mLUAkdMiZxTD/syWBlpebfA/mTMAK Yr5SOls2hg2qPZdObBY2TLZl6AneZsaWuSKUO0WqmDRbnZKc+sKLMNnR0axpekuzKyoK 19lQ== X-Gm-Message-State: AOJu0YzHhZHf+8UPc2XsH4VwpJpgm0ieM9ye16E+x5+LSpGXieY5g8U/ 1krQulxyBOIRUFa7/lEhoE4FZdB+SMcg6jeB9+vkzlMoio1kupnMFoCUfNQISToQ4192Agk7rtV fy6914AJAEYtOE6Gws3Zj/ROf+N/l2/az X-Google-Smtp-Source: AGHT+IG/lwTzFoxD5zSs08zHWD+6AYWqNM6kfAHxEly10AR1BHTVqUiqp3gxG3gV1rBBiXyFxak1kNKiAMKtxvZof6Y= X-Received: by 2002:a05:6214:5b10:b0:6cb:3a7b:96b9 with SMTP id 6a1803df08f44-6ce3416cfdcmr53406196d6.15.1729713871196; Wed, 23 Oct 2024 13:04:31 -0700 (PDT) In-Reply-To: <86ed46en1q.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::729; envelope-from=wyuenho@gmail.com; helo=mail-qk1-x729.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:324805 Archived-At: --000000000000db342106252a642c Content-Type: text/plain; charset="UTF-8" > > Thanks, but that doesn't explain enough. Please tell more about the > need to truncate completion candidates "inside a confined pop up box". > If that box is displayed, why doesn't Emacs truncate the text > automatically? Or maybe I don't understand how this "pop up box", > whatever it is, is displayed? Each completion in a list of completion candidates is a triple of (candidate string, prefix, annotation), all in varying widths. Aligning these 3 columns requires calculating paddings. Since there are paddings, the padding between the candidate string and the annotation can also be arbitrarily large. Naive truncation that truncates the entire concatenated line against the width of the pop up box, which is actually the window width in a child frame, may leave some arbitrarily long empty space in the end. In addition, naive truncation does not replace extra characters in the relevant columns with ellipses to indicate truncation happened. Please look at the link in my first email for further details. > So the issue is not "pixel-wise truncation", the issue is to take > variable-width display elements into account when truncating, is that > right? > To be precise, by " truncate strings correctly and preferably in pixel precision", I mean truncation that respects pixel width constraints (and grapheme clusters, as clarified by you). Truncating variable-width display elements on GUIs necessitate the ability to calculate the widths of the individual elements, I call this the hypothetical `glyph-pixel-width`. Whether it is exposed to Elisp is less important to a hypothetical `truncate-string-to-pixel-width` for my use case. --000000000000db342106252a642c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, but that doesn't explain enough.=C2=A0 Pleas= e tell more about the
need to truncate completion candidates "inside a confined pop up box&q= uot;.
If that box is displayed, why doesn't Emacs truncate the text
automatically?=C2=A0 Or maybe I don't understand how this "pop up = box",
whatever it is, is displayed?

Each completi= on in a list of completion candidates is a triple of (candidate string, pre= fix, annotation), all in varying widths. Aligning these 3 columns requires = calculating paddings. Since there are paddings, the padding between the can= didate string and the annotation can also be arbitrarily=C2=A0large. Naive = truncation that truncates the entire concatenated line against the width of= the pop up box, which is actually the window width in a child frame, may l= eave some arbitrarily=C2=A0long empty space in the end. In addition, naive = truncation does not replace extra characters in the relevant columns with e= llipses to indicate truncation happened. Please look at the link in my firs= t email for further details.
=C2=A0
So the issue is not "pixel-wise truncation", the issue is to take=
variable-width display elements into account when truncating, is that
right?

To be precise, by "=C2=A0tr= uncate strings correctly and preferably in pixel precision", I mean tr= uncation that=C2=A0respects=C2=A0pixel width constraints (and grapheme clus= ters, as clarified by you). Truncating variable-width display elements on G= UIs necessitate the ability to calculate the widths of the individual eleme= nts,=C2=A0I call this the hypothetical `glyph-pixel-width`. Whether it is e= xposed to Elisp is less important to a hypothetical `truncate-string-to-pix= el-width` for my use case.
--000000000000db342106252a642c--