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: Thu, 24 Oct 2024 17:49:27 +0100 Message-ID: References: <86sesndz8v.fsf@gnu.org> <86ed46en1q.fsf@gnu.org> <86seslddvs.fsf@gnu.org> <86msitd0oy.fsf@gnu.org> <86h691cwuv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000457f6906253bcbc8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39430"; 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 Thu Oct 24 18:51:04 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 1t4139-000A4D-VA for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Oct 2024 18:51:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t412H-0002Ki-SR; Thu, 24 Oct 2024 12:50:09 -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 1t412F-0002Ik-DI for emacs-devel@gnu.org; Thu, 24 Oct 2024 12:50:07 -0400 Original-Received: from mail-qk1-x72d.google.com ([2607:f8b0:4864:20::72d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t412D-0002Am-Nr; Thu, 24 Oct 2024 12:50:07 -0400 Original-Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-7b161fa1c7bso70561585a.0; Thu, 24 Oct 2024 09:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729788604; x=1730393404; 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=fhbQJGfFg/8h9eoLGiF/CFOaBxWoHh9Dg/6KOH8rrcM=; b=aEalg1nl/KBg08fu4olpeCBDgH77w0LA56unR6olrbzdhL4NhsDAKsoioYR7F1VOxs pY9y9R2gAgtXjAWkZL1VFbSizEtwdQPd015P8/IiOoGvIv9xLLZi0Zq+jvkV6dWfDwmi LXK8m1WPBTzck8s1D+7ySsuk9V/uSXHlg13BBEbmdQYjcid7jJjvLavCRYZFW+Yms2Qo dnW/k/95ZrBBUs+XagnrbitjP6nSZqnXJWLUIyqeESh/vhQ8JOdkOCpRDmrCrUjrfl5S Y2jNfFrngq5d4Z4Q/zfMe9hZPd2yR3za0AAS77GgWJ/0R93sx2hJc4C+/1M5hG4Sc7PX h+sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729788604; x=1730393404; 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=fhbQJGfFg/8h9eoLGiF/CFOaBxWoHh9Dg/6KOH8rrcM=; b=XukM4wFY8dI/EYyncucxY8vd5v2sXsbcANguoOH9CVYxfaC6TjOr9R5SVlgDbfXgyv lrXGJmGMk5Mx4iEoPGwfkYdcwx9LPV3sUocQ2pwNtmfUbPZ32FQj6AIFBSlxTvhUAgvd mQVOv35VBkeJ/+/hKnkMzk3DDynTYCEBGkOPdeXGFJAgCb05/cYvs+6sHlYA8KfNSnCF Gw2s+lYAxPUxnF1qt3pAMtwDSPyqmmkHXhGg3L7G/F4EyMcVDTFjdL4XY3fqzJgOoSoL Q+BLNGLHwPc7UEkCHDCmNPdLHpipr0MYfeQOu/GkPUGPOvMfNj6J0gNtV3h+JtfsNHwt GdvA== X-Gm-Message-State: AOJu0Yw/ZQUCHox4Z5Dldcyop1hJa5sdV7slEzSrAiTmKfFTotvYDC0n eAzWOG3WHykjyg/QA3taY/ZVf1cYyp1R8tpvkzsFzoTil+Ql3tQ6FHde2nUOhVPnD6h/Y6DD5tu c3vw0n3vJpKFbFQtAM8lj5IQbUwm75FuB X-Google-Smtp-Source: AGHT+IFkpf1pH4eJeyq3KNYIAG8Lc6lDG1nmKPb3UW0wvWaHOkORJlxHmQx2HeZbURgKF/VbdkNGXK9f/SjMNqcgxw8= X-Received: by 2002:a0c:f408:0:b0:6cc:37bb:40b with SMTP id 6a1803df08f44-6d09268bcdbmr29902816d6.37.1729788603888; Thu, 24 Oct 2024 09:50:03 -0700 (PDT) In-Reply-To: <86h691cwuv.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::72d; envelope-from=wyuenho@gmail.com; helo=mail-qk1-x72d.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:324824 Archived-At: --000000000000457f6906253bcbc8 Content-Type: text/plain; charset="UTF-8" > > I guess I don't understand the issue you are describing. Where does > window system come into play here? What are "UI elements that Emacs > thinks are content", and where are they in the screenshots shown in > https://github.com/minad/corfu/pull/508 ? And where in my suggestion > did I propose anything that would cause "truncation by window system"? > That thin white bar on the right of the box from the third screenshot onwards is actually a string with a display space property in pixels, not a real scroll bar. Using :align-to in the padding between the candidate and annotation is not a problem, the problem is if the concatenated line is too long, I'll need to truncate. There are 2 options - `truncate-string-to-width`, which is bugged, or set the `truncate-line` buffer local to t and let Emacs' window system do its magic, which will be performant and correct, and I can even replace the arrow in an ellipsis, but truncation will start to truncate off the emulated scroll bar. > Lisp programs are not supposed to do layout calculations, plain and > simple. The reason is that layout calculations are impossible without > having a window with lots of stuff that determines how text is > displayed. So doing that on strings is meaningless. > As I described in my first email, this can almost be achieved from the existing Elisp functions and C functions exposed Elisp. The performance problem associated with resolving a font WRT the anonymous face and face list craziness can be done in C, and already exists. The width of the display space and string replacement text properties can be calculated by `check_display_width` in `indent.c`, and rest is surely somewhere in `image.c`. I hope you are not telling me that Emacs devs still refuse to give people the ability to align text in pixel precisions programmatically at the end of 2024. Browsers have had this ability for almost 30 years. --000000000000457f6906253bcbc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess I don't understand the issue you are describ= ing.=C2=A0 Where does
window system come into play here?=C2=A0 What are "UI elements that Em= acs
thinks are content", and where are they in the screenshots shown in https://github.com/minad/corfu/pull/508 ?=C2=A0 And where= in my suggestion
did I propose anything that would cause "truncation by window system&q= uot;?

That thin white bar on the right = of the box from the third screenshot onwards is actually a string with=C2= =A0a display space property in pixels, not a real scroll bar.

Using = :align-to in the padding between the candidate and annotation is not a prob= lem, the problem is if the concatenated line is too long, I'll need to = truncate. There are 2 options - `truncate-string-to-width`, which is bugged= , or set the `truncate-line` buffer local to t and let Emacs' window sy= stem do its magic, which will be performant and correct, and I can even rep= lace the arrow in an ellipsis, but truncation will start to truncate off th= e emulated scroll bar.
=C2=A0
Lisp programs are not supposed to do layout calculation= s, plain and
simple.=C2=A0 The reason is that layout calculations are impossible without=
having a window with lots of stuff that determines how text is
displayed.=C2=A0 So doing that on strings is meaningless.
<= div>
As I described in my first email, this can almost be achieved from = the existing Elisp functions and C functions exposed Elisp. The performance= problem associated with resolving a font WRT the anonymous face and face l= ist craziness can be done in C, and already exists. The width of the displa= y space and string replacement text properties can be calculated by `check_= display_width` in `indent.c`, and rest is surely somewhere in `image.c`. I = hope you are not telling me that Emacs devs still refuse to give people the= ability to align text in pixel precisions programmatically at the end of 2= 024. Browsers have had this ability for almost 30 years.
--000000000000457f6906253bcbc8--