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: Mon, 17 Jun 2024 11:44:47 -0700 Message-ID: <66e7c49d-adb6-186f-18f1-33eee9f668ad@gmail.com> References: <868qz3ssu0.fsf@gnu.org> <201c2285-012f-fa29-03b5-78a2e26aa134@gmail.com> <86plsfqvme.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="22050"; 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 Mon Jun 17 20:46:19 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 1sJHMv-0005SM-3b for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Jun 2024 20:46:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJHMg-0000VO-V6; Mon, 17 Jun 2024 14:46:02 -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 1sJHMf-0000V2-H7 for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:46:01 -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 1sJHMe-0002zs-RF for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJHMg-0000JI-0W for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:46: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: Mon, 17 Jun 2024 18:46:01 +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.17186499571174 (code B ref 71605); Mon, 17 Jun 2024 18:46:01 +0000 Original-Received: (at 71605) by debbugs.gnu.org; 17 Jun 2024 18:45:57 +0000 Original-Received: from localhost ([127.0.0.1]:35379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJHMb-0000Iq-0S for submit@debbugs.gnu.org; Mon, 17 Jun 2024 14:45:57 -0400 Original-Received: from mail-pj1-f43.google.com ([209.85.216.43]:52480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJHMY-0000Ia-Fy for 71605@debbugs.gnu.org; Mon, 17 Jun 2024 14:45:55 -0400 Original-Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2c4c7eb425fso3731780a91.1 for <71605@debbugs.gnu.org>; Mon, 17 Jun 2024 11:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718649886; x=1719254686; 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=1mqzTT2ftJrw+OmqPOv3oEYs+m3oejSxsjpYYVTuUng=; b=mt50fzacyh02jhMmeVnH9uojw8xjODePiZIHJwlGcTn203w/BibabBkcIwZYqjtnTT ZpxlZk8OITRIaAuaqYh1JW2sJMsy9kE3ajVB025A4h3AfYDgvfnV2AOrKs2np8nCd7Rl uiMABO8kIBPsGltE0YnZ+kYt//6cbe1Ki1KCudJXDKRbQw4cMwuD2xvjxp4VXVrp+vLQ qq1tYhp07hFDMklX0udB8MrJtanxUYs1UcDtNC6fPAcoXDoUi8Idb9RT0dzTCrKmFbCH 8yGC0kNmE38wCRBKM9yCBn9RIQ7Zd3fdXLih/IeHPbU7r/IW6EqcAHydiY3aCqJmQ4La Ai5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718649886; x=1719254686; 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=1mqzTT2ftJrw+OmqPOv3oEYs+m3oejSxsjpYYVTuUng=; b=gOL4k/DOautE0cYFPXOZIaxnf/iA8XoVxtPWCItsq9zg/dOyq4OhcwoM4y85GzwEib sNfss0SITmMriDhZvu1ol2q07B1IF0iinUp+VZmILYs0tyJQz8xur7aZ5/Cd/f1QdE07 k48zFNVG47OoNbM7lYwf+drRFqtSkgc5UuPvViVzSXZ7L6UEfGKFQkEXc5xyPqjUZDXN 3DPguTOApn0DLMAWs85Z2bSkKD2F/pquIb32ZE7IbiCt8+2q6YPGKBsHi8bfxeBWL06E JJdjxLbY6u8KZmajrOxgQqmfNd/OWNZdv0wG7TryvNBg8zJXAwmD7woU4jnn08bcSWqH saMg== X-Gm-Message-State: AOJu0YziOu+WEGOsu5bVrsadeet2DZDcN/OFyG+IIiEeEHwjeWtP4UQK iNdvXNhk3uUsyRnuuIrh6GjU5ricFnohHQThzDmN9ozg870dUGyzrII3Uw== X-Google-Smtp-Source: AGHT+IH2tGZLzm82pQ7LOXm25mon/rub9aEL8heRAqjSD4b0WrQcLK5fGyHAUKV9jCJ6ElTbZ9nblA== X-Received: by 2002:a17:90a:fa06:b0:2c2:c148:c961 with SMTP id 98e67ed59e1d1-2c4dbd44db6mr9148799a91.48.1718649886562; Mon, 17 Jun 2024 11:44:46 -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 98e67ed59e1d1-2c4a76aa3f4sm11541072a91.53.2024.06.17.11.44.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Jun 2024 11:44:46 -0700 (PDT) Content-Language: en-US In-Reply-To: <86plsfqvme.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:287417 Archived-At: Replying to your individual points below, but in the other subthread, I had the idea that maybe a better way to do this would be for the wrap prefix to always be the first-line prefix but to make it transparent when desired. So for the "* some text" example, the wrap-prefix would be "* " but fontified(?) such that you can't see it. A face transparency attribute might do the trick, and be useful for other things too: . Or maybe :align-to could take a string value, which would mean "use the pixel-width of this string as the value". On 6/17/2024 11:20 AM, Eli Zaretskii wrote: >> Date: Mon, 17 Jun 2024 10:42:56 -0700 >> Cc: 71605@debbugs.gnu.org >> From: Jim Porter >> >> I tried using :align-to, and it doesn't seem to take effect for the >> 'wrap-prefix' text property. I haven't looked closely at why that >> doesn't work, but even if it did, I think it might make things more >> complex than they already are. > > What exactly did you try? I might be misremembering, but I'm not > aware of any limitations wrt use of :align-to in wrap-prefix. In > fact, the ELisp reference manual explicitly mentions :align-to in its > description of wrap-prefix. My minimal test case is to open a buffer, put some random text in (long enough that it would wrap), and then call: (put-text-property (point-min) (point-max) 'wrap-prefix '(space :align-to 4)) Nothing changes for me. If I replace :align-to with :width, I see the continuation lines get indented by 4 characters. >> The 'face-change' idea could work, or here's another possibility: what >> about using :relative-width? > > :relative-width could work, but you'd need to make sure it takes the > width from a fixed character, otherwise different paragraphs won't > align the same. In this case, the first character is always a space so that's ok. >> 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. >>>> -@defun string-pixel-width string >>>> +@defun string-pixel-width string &optional buffer [snip] >> Maybe this should take the face-remapping-alist directly? Or maybe we >> should pass in a window? > > If you can pass a window, you can use window-text-pixel-size instead. I think 'window-text-pixel-size' would compute the size of the text already in the buffer, and I was looking for a function that told the width of some text if I were to later display it in that window. In any case, I might not need to use this function at all depending on how I do things... >> Yeah, though the FCP argument is always the prefix we constructed, so we >> know what the display-spec looks like if it's present. > > Sure, but that means the code is fragile, and you need to comment > prominently that if the form of the display spec changes in the > future, this code will need to be adapted. Assuming I keep going down this route, I'll be sure to comment this extensively.