From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#71605: 30.0.50; [PATCH] Support variable-width text in 'visual-wrap-prefix-mode' Date: Tue, 18 Jun 2024 15:17:29 -0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8388"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71605@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 19 00:19:24 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 1sJhAh-0001zw-Qx for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Jun 2024 00:19:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJhAL-0000NL-8K; Tue, 18 Jun 2024 18:19:01 -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 1sJhAJ-0000N4-Nw for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2024 18:18:59 -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 1sJhAJ-000529-Fr for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2024 18:18:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJhAM-0003Mp-3K for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2024 18:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Jun 2024 22:19: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.171874912112903 (code B ref 71605); Tue, 18 Jun 2024 22:19:02 +0000 Original-Received: (at 71605) by debbugs.gnu.org; 18 Jun 2024 22:18:41 +0000 Original-Received: from localhost ([127.0.0.1]:53874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJhA1-0003M3-CZ for submit@debbugs.gnu.org; Tue, 18 Jun 2024 18:18:41 -0400 Original-Received: from mail-pf1-f171.google.com ([209.85.210.171]:44189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJh9z-0003Lk-8n for 71605@debbugs.gnu.org; Tue, 18 Jun 2024 18:18:40 -0400 Original-Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-70436048c25so4644107b3a.0 for <71605@debbugs.gnu.org>; Tue, 18 Jun 2024 15:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718749050; x=1719353850; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=fy6P9iGMb0r4NEZjP+aRPky0unZ0i4pHV7F1ZdThpbs=; b=WI+Qx20NKbS6WD2r3ybFPWkNhSAuZMSD3E4wpsfDVz7uUG57dg//IOSzYMYAyrVBg6 CN0oBANmwqMTs0A4recy95upxsEGW3OMCnuocdw3DSbDb6d9rdzg1G4V6OeaGsOJjqED yihwlXm9ZMtb0G+FT1tSROnqr9lKvR3YlHDPBdC4W9nIsI98nfwTArn0jL2yK0lZdcpq 1FsSMT+o2z5SsQLyT6p1GaePFh2pMuz2iAWX2VhhgXXmYYeYBaqW4iwrgSbT1QcIQokb 7UJMQZcEHnEm+N9InLkpD2cqM2sBYFH71YF6NmqckYsalCWYfgUX3Iawv3JVIvBIaIWS 4Q2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718749050; x=1719353850; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fy6P9iGMb0r4NEZjP+aRPky0unZ0i4pHV7F1ZdThpbs=; b=liWA5tGJ0xh5NOGwn0Ab/7OXQquKDi2W+hScGxEfkJX4YNEyYqNT0SESCcd912QrZT BbKaw847rS2Bxys3Lqsi7bnkciF2Wsp9g5cvB0JqamxxW/MnZYUWJgIgCB2B5LPfutj+ segfopvkVG7q6+xBXzdzX04iqY0iAkAnesmwO31sLELPByUnfHz1JZWyJ/sHGMIYB+hN ScWyLV/5fuy2F7lEqZT0c2FpP4fKnzkoNvRwF3Wz4VGEpscVXJZEy0ouWMCjVHzvDi41 41B9S74ehhJaJMUEC4Z4lUhIlRJg7bu+DOmPeDyjcugB7hRGIibYCLsEJHKyGiUdlCIq 5llQ== X-Gm-Message-State: AOJu0YxWeD8aXUktkLvVH5NA4yKRaAUSpWplYumpfNKDFs3MDJP+pgIt 0iclcsdf3bG8QpSZK3TM3eb+60ExGegbfkyg5q/Upb44bF7XwFRa X-Google-Smtp-Source: AGHT+IHo18m24KmA0h0ri1tnNMMV0SP6ERE+03wRK4c6y8Tsqu1LWH7M1lLLEphN5HtpKLQbBL8dsw== X-Received: by 2002:a05:6a20:ba8f:b0:1b5:9670:33f2 with SMTP id adf61e73a8af0-1bcbb5f70b5mr828184637.39.1718749050154; Tue, 18 Jun 2024 15:17:30 -0700 (PDT) Original-Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d2e1a72fcca58-705cc96731dsm9424965b3a.55.2024.06.18.15.17.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jun 2024 15:17:29 -0700 (PDT) Content-Language: en-US In-Reply-To: <86h6dqqy63.fsf@gnu.org> 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:287460 Archived-At: On 6/18/2024 4:37 AM, Eli Zaretskii wrote: > I don't think I understand how would this do the job. Surely, the > indentation space should be visible? I mean the second-line "* " prefix would be visible but transparent. >> A face transparency attribute might do the trick, and be useful for >> other things too: > > It isn't universally supported, AFAIK. I think it would be feasible to support an opacity level of 1.0 and 0.0. opacity=0.0 could just allocate the space for the text but not actually draw the glyphs. (Whether we want to go this route is another question.) >> 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. 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. Providing a number in pixels is also challenging because then I need to be able to determine when to recompute that number. >>>> 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.