From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Need `truncate-string-to-pixel-width` and `glyph-pixel-width` functions in C Date: Thu, 24 Oct 2024 20:56:41 +0300 Message-ID: <86frolcrl2.fsf@gnu.org> References: <86sesndz8v.fsf@gnu.org> <86ed46en1q.fsf@gnu.org> <86seslddvs.fsf@gnu.org> <86msitd0oy.fsf@gnu.org> <86h691cwuv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38308"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jimmy Yuen Ho Wong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 24 19:58: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 1t426B-0009m9-BV for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Oct 2024 19:58:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t425M-00060L-VD; Thu, 24 Oct 2024 13:57:29 -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 1t425L-0005zm-P3 for emacs-devel@gnu.org; Thu, 24 Oct 2024 13:57:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t425L-0002th-Gq; Thu, 24 Oct 2024 13:57:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Fa1n5/8sfRLvwqv3pyP5rUU6dgX8PpnCs1QjPsB1Fd4=; b=iX2h0kZq2hsk PDY6E/5bujMQ5YwNal9GnpOIIGeyvU4GqadGw+05GBwHO3VD31bLcwns4tcSIGJ/mn6Od23B085lt +hN2vcSarbnTUO0funWSz2DuDd9nLX5Hh0Iwr8uyvegncZ+ea43fJ1UmfhmQ6Ltf1mgdYiev/88cE 8ZGP4uv4dGBJgNQQVhzemtahp4uwQn+GSJtoDm/ln1gx3j2pZbHu1bp2DQvZ6vsUFcY8AnzriyvHq sjoG3Vc1w6IJGrOv5DwMvWB8RxwzcddLKsr2m1+xrExxhH2k6bM8pd4HaDv7IujvgsrTSPVu0bvmf nezpNYvFf1klS9if9xfqvQ==; In-Reply-To: (message from Jimmy Yuen Ho Wong on Thu, 24 Oct 2024 17:49:27 +0100) 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:324826 Archived-At: > From: Jimmy Yuen Ho Wong > Date: Thu, 24 Oct 2024 17:49:27 +0100 > Cc: emacs-devel@gnu.org > > 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. OK, but then the Lisp program which produces that bar knows its pixel-width, and can account for it in the :align-to spec. > 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. Why would you need to truncate? and which part needs to be truncated? My suggestion is to align the s part so that it and the following pseudo-scrollbar end exactly at the window edge. With this arrangement, you shouldn't need to truncate at least the s part. This can be dome by using :align-to which counts from 'right', which is the right edge of the text area. Actually, I don't understand why you'd need to truncate anything, since the dimensions of the child frame can be calculated such that the longest completion candidate will still fit without truncation. Or what am I missing? > 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. You assumed something I didn't say and didn't have in mind. There should be no need to use truncate-lines. > 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 don't think you fully understand the code you are referring to, because it will not do what you want. E.g., check_display_width calls string-width, which you found problematic, and image.c doesn't handle layout of images. More importantly, the _only_ place in Emacs where we have code that lays out glyphs until it hits some specified coordinates is in the display engine, where it arranges text for display, one "display element" at a time. Exposing that to Lisp in a useful way is a hellishly hard job, because that code was never meant to be useful from a Lisp program, and from a POV of a Lisp programmer in certain cases behaves nonsensically. That's one of the reasons why vertical-motion has such a complicated implementation which deals with half a dozen different complications when using the display code in such way. Of course, if someone wants to write such a code, and it will be clean and correct, such patches will be welcome. But please believe me when I tell you that it is much better to try to avoid that and use existing display capabilities (which will also allow you to support this in current Emacs versions, instead of waiting for some future one). > 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. This is not about refusal. It isn't like what you are asking is easy to do, and the "Emacs devs" are just a lazy bunch. I looked at the code involved, and I currently have no idea how to implement what you have in mind so that it works in all the cases, those which you mentioned and those you didn't, and works in a way that will be useful for Lisp programs. You may think it's easy, but it isn't. Some things are even conceptually not simple, for example whether it is okay or not to break a string between U+1F3C2 and the following U+1F3FF, and if so, how to discover that subject to how the current character-composition machinery in Emacs was designed and implemented. Of course, it is possible that I'm missing something, so if someone has ideas about implementing this, let alone code, I'm all ears. But even if such ideas/code emerge, I think doing this job using existing display capabilities is a better way, because it will work immediately with existing Emacs versions, and will probably be more reliable. I still don't see why you couldn't solve the problem using :align-to and the other ideas I suggested. Last, but not least: please don't forget that Emacs is a volunteer-driven project, and the only resources we have are those of people who decide they want to work on something, for whatever reasons.