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.bugs Subject: bug#71605: 30.0.50; [PATCH] Support variable-width text in 'visual-wrap-prefix-mode' Date: Wed, 19 Jun 2024 14:45:56 +0300 Message-ID: <86iky5p34b.fsf@gnu.org> References: <868qz3ssu0.fsf@gnu.org> <201c2285-012f-fa29-03b5-78a2e26aa134@gmail.com> <86plsfqvme.fsf@gnu.org> <66e7c49d-adb6-186f-18f1-33eee9f668ad@gmail.com> <86h6dqqy63.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6396"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71605@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 19 13:47:27 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sJtmg-0001Qc-CC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Jun 2024 13:47:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJtmU-0005nM-AT; Wed, 19 Jun 2024 07:47:15 -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 1sJtmG-0005lK-9U for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 07:47:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJtmF-0005Jp-Ok for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 07:46:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJtmI-0005NX-JQ for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 07:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jun 2024 11:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71605 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 71605-submit@debbugs.gnu.org id=B71605.171879757420603 (code B ref 71605); Wed, 19 Jun 2024 11:47:02 +0000 Original-Received: (at 71605) by debbugs.gnu.org; 19 Jun 2024 11:46:14 +0000 Original-Received: from localhost ([127.0.0.1]:41040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJtlW-0005ME-2M for submit@debbugs.gnu.org; Wed, 19 Jun 2024 07:46:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJtlU-0005Lk-HX for 71605@debbugs.gnu.org; Wed, 19 Jun 2024 07:46:13 -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 1sJtlK-0005Fi-BR; Wed, 19 Jun 2024 07:46:03 -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=7IU2fjjRUp0yLDQg6dSfkpeg0nzfQvoMw/NhSjwyCPE=; b=CpMxoJD5WY23 oMj+zD7uCpvJacbe1wce2fcktDgKkuO7HBNSgUf29FVpj2s4GjRkrB5DYDrTQ9XzsEtiM/APLT0nc LgFaHQkoEyhV9HN2c8onS9o+9y5SZ6ausCZn83WrPbQdpjx8ZhsXsnyYMfDGPO2I7iGZms+KKkMeQ O75RnkaOESlMFP0JUg4Fb8ns6Vg9bsdwbvaMFVA60Q7WlmHNCNTU7m2f6qz65Kt/G+f7WUPQwABrI uEKCZRl7uemP5nPNc/2YvUNoTRL9/pFLMjhwLIJd7zhvfTLOltjJw/FIUIDFNWMKTLP+oVwkXFjcl xKyW2cjVkzeV6mZeVIX7AA==; In-Reply-To: (message from Jim Porter on Tue, 18 Jun 2024 15:17:29 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287478 Archived-At: > Date: Tue, 18 Jun 2024 15:17:29 -0700 > Cc: 71605@debbugs.gnu.org > From: Jim Porter > > On 6/18/2024 4:37 AM, Eli Zaretskii wrote: > >> Or maybe :align-to could take a string value, which would mean "use the > >> pixel-width of this string as the value". > > > > How is that different from using a column (as opposed to pixel) value > > for :align-to? > > A column wouldn't work, since for a variable-pitch font, N columns is > just N * . If the actual characters you're > trying to align to are narrower than the canonical width, they won't > line up correctly. If both the first line of the paragraph and the rest are aligned on that width, they will all line up. IOW, the idea is to make the text of all the lines :align-to to the same column number, like this: * some text some other text Then you don't care about the actual pixel width of "* ". > Po Lu also raised the issue that in some cases, different frames can be > displaying the same buffer using different fonts. Conceptually, I'm > really trying to tell the display engine, "Put a space here exactly as > wide as using whatever font you end up using." At the buffer > level, I can't provide a numeric width here that works everywhere, since > it might really be multiple numbers, one for each frame. IMNSHO, this is over-engineering, as we already have the means to do the same with existing features. Asking the display engine to measure and record somewhere the pixel width of a string is a significant complication to how the display code works, because the display routines can be called to start their job at any arbitrary place in the buffer. > Providing a number in pixels is also challenging because then I need to > be able to determine when to recompute that number. Which is why I didn't suggest that. I suggested columns because they scale with text-scale-adjust. > >>>> If I set that correctly, then the pixel-size should adjust as the > >>>> text scales. It wouldn't handle the case where the actual font > >>>> changes though. > >>> > >>> Why not? > >> > >> I was planning to set :relative-width to / > >> . If the font changes, the result of that > >> calculation can change. > > > > The idea is to set it to the multiple of the character's width, which > > will then scale with the font. > > Imagine two fonts A and B, where the only difference is that the space > character in B is twice as wide. So: > > = 15 > = 10 > = 20 > = 15 + 10 = 25 > = 15 + 20 = 35 > > If I compute :relative-width for font A, the result is 25/10 = 2.5. Then, > > 2.5 * = 25 = (good) > 2.5 * = 50 != (bad!) > > So we'd need a way of keeping the width in-sync with any font changes. I don't understand the example. If these are two different paragraphs, then their indentation cannot be guaranteed to be the same anyway, because no one can assure you all the paragraphs will use the same font. So whatever you mean by , it will always be different for different fonts, and I don't see how this can be solved for an arbitrary combination of fonts. So my suggestion is to go back to the simpler idea of using :align-to with an absolute value, either in pixels or in columns (which AFAIR is interpreted in units of the frame's default font's width), and if needed augment that by recalculation when necessary.