Received: (at 76107) by debbugs.gnu.org; 20 Mar 2025 20:46:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 20 16:46:27 2025 Received: from localhost ([127.0.0.1]:59121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tvMmZ-0005Bd-5w for submit <at> debbugs.gnu.org; Thu, 20 Mar 2025 16:46:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37290) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tvMmU-0005BC-6k for 76107 <at> debbugs.gnu.org; Thu, 20 Mar 2025 16:46:25 -0400 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 <eliz@HIDDEN>) id 1tvMmL-0006rm-LA; Thu, 20 Mar 2025 16:46:14 -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=3g5Tr4ieGok+MnlmH8WYmJRJuT/glfFlP6fEIkjbnh4=; b=rLDOP9fkILfp cZ9faf+LFse+suohkCmnKCvhtuGxG/7hl/Lsx9Aa+Jmh4+mJn2aD6xKnNfpC+6e1946AmmCRVDSDn +nJE6njY0JvnXsP+kNO66HFWcA6kp8kC3e6WZYjej3ssP5n11x+9QpTsAQGH57WziCdVsm8aAFHSO 5MXtglR/TiJdNLfVjcpOoOGROmDFIHIttS1sGUA8SoU8kZ7s5sh1IAeR/uZ7tKZ5ZsfbPzEWDgkcV l70UMTqW/EKYIUHW3mMLBtp+mWo7Z1QxJTzVU3X1fqvwXp8S/tleSGgQ+liwiJHXxpFRLre9Rbz6u zLcK0nuRXGMpT0n6f9IwDw==; Date: Thu, 20 Mar 2025 22:46:11 +0200 Message-Id: <86cyebmnvw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87bjtvaakk.fsf@HIDDEN> (message from Thuna on Thu, 20 Mar 2025 18:14:35 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> <86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> <86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN> <87o6yga49p.fsf@HIDDEN> <86h647psbt.fsf@HIDDEN> <87ecyv9jzq.fsf@HIDDEN> <868qp0ne8g.fsf@HIDDEN> <87bjtvaakk.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Thu, 20 Mar 2025 18:14:35 +0100 > > >> So far, I have only had two related issues: The width calculation is > >> incorrect when dealing with characters which are not full-sized (they > >> are being calculated as though they were full-sized) > > > > Sorry, I don't understand: is this due to my patch? My patch isn't > > supposed to touch the case of characters, only that of inline images. > > Was this problem present before my patch? If not, can you show an > > example of it? > > No, sorry, I didn't mean to imply that. This was happening before as > well, but it's similar enough, so I figured I would bring it up in case > a small tweak is enough to fix it. Ah, okay. But in that case, this is the intended behavior: current-column disregards the pixel size of the characters, and counts each character as one column regardless of its size on display. > > Hmm... you say "there is an image from line start to point", but in > > the example you show the image is not at the beginning of a line. Did > > I misunderstand what you are describing? > > I was referring to an image being present somewhere in the line before > the point, but the patch seems to have fixed it, so that's fine. OK, then the one-line addition to the patch that I sent should solve this.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 20 Mar 2025 17:14:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 20 13:14:46 2025 Received: from localhost ([127.0.0.1]:58747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tvJTh-0004LJ-Tg for submit <at> debbugs.gnu.org; Thu, 20 Mar 2025 13:14:46 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:54397) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tvJTf-0004L0-9I for 76107 <at> debbugs.gnu.org; Thu, 20 Mar 2025 13:14:43 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-43948f77f1aso7127465e9.0 for <76107 <at> debbugs.gnu.org>; Thu, 20 Mar 2025 10:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742490877; x=1743095677; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=R9bSyr/Kqy73vrbPUV+adwxsniBBUxV064PY3Jdsr7o=; b=d38+0/d9d1ychmk157pqB9KevSWgPut89/6/2i5TWjf0phFL0cD38nlRXt7SQ1L4M2 Im3ONNtDggXlgiAeAaX9KvRVCnJV34W52tIiWy63sQyqb/CUqvneDPiWAwkl3LPpizwo v7uAShL36qxfLiZ6xL/74sFOSNxor1YWw3OcNExSns/V5ptoBKblUAE+nF5eWa0Wp6vU 1l3KiUyVd6fVwp2hrL//aXJ0C/3dKTvoE0e+0msdsnapZ/rMzbKrTi+yK4GYqbNsNmDQ aXFLrVI64s6f61Rqk1i+j45CrhZ3uQzby1ru2i8Nj4ltrB2dikTNH9MgPu0DVoZyrIx7 U6BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742490877; x=1743095677; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R9bSyr/Kqy73vrbPUV+adwxsniBBUxV064PY3Jdsr7o=; b=dTUbmF1eIvC9+XYXYRSuADICAQ43CUdbNPLcZLdcczMAxA00F+OtGjBBmaWTyksgtT D7OiG2jSolkVee+iOWLfN4alHwKwQHNbphMIQuOUL/Kl/ocNorNYKhRWz/iIk5ARJpIu jUqXVjDwGz0yUnTtuxJzcczQoLSfTZz8xnw+7YjgVv4kYAOWprYA11UEtUB/p29RvT7h pJueEQ1bpuodIoZTJRr+J9FF6Zajx9nrOTUNtcLqzuFieIbWiutkDbI+YLm+vu9xpacj qmxkg9q0m2nPaSkp+Wxe4MpA0/YQ6njNhTxzh+4RGIk57Q3FRQrbyIlY0A8Z34Pf7O33 HrTw== X-Gm-Message-State: AOJu0YwdJxYQ7X1E58vGm5SfrwcYJGg7AUdAZHkYwq/wYcnkuVFRbvjO ldlY2VjyIbvKbgo/838Qm1Nr51pt2Oxk5akfjb1mlsEz9SSa0Gbb53PRjra1LptbPA== X-Gm-Gg: ASbGnctEawFeCSIPteqRrpWS1OHFYUy36IPbhDIedbqFy9pQDv6MZqWx64wHwaWCat1 3VqF6wM/m7Q1XtbqQB4OyuuHJP7qC8De3QzWIEHWQ4N1jS+fNSpZJdEZKMgRue6/y37kEHLuk0y Q/54hGkVq6E/Bvh2EIpqhu9Nb+WcHgiL7SoWFkyIchXZwXuWgT8oW7Vd0ObaYb2X0gN7lxXaf+L 4qN/owmRiws9H/11H4F5xRgxuOWR2qO7NXZ2qpo+ciaUzVpfTMpG505eJfuEBY/WBZfIIC3coyi hNeoGM0BoxqNxymxeulsOcGEfLqxGfjOYY/6lO3ZePSe X-Google-Smtp-Source: AGHT+IF+BHFi3EyaVMpBSDdTJRmtFg/nKIWywh3EirmYQB910o2pa1nyp1xjeyFFO1b0CekB0EZ0nA== X-Received: by 2002:a05:6000:1acf:b0:390:f6cd:c89f with SMTP id ffacd0b85a97d-3997f937b55mr327663f8f.53.1742490876487; Thu, 20 Mar 2025 10:14:36 -0700 (PDT) Received: from thuna-lis3 ([178.249.211.70]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3997f99579bsm153430f8f.19.2025.03.20.10.14.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Mar 2025 10:14:36 -0700 (PDT) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <868qp0ne8g.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> <86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> <86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN> <87o6yga49p.fsf@HIDDEN> <86h647psbt.fsf@HIDDEN> <87ecyv9jzq.fsf@HIDDEN> <868qp0ne8g.fsf@HIDDEN> Date: Thu, 20 Mar 2025 18:14:35 +0100 Message-ID: <87bjtvaakk.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) >> So far, I have only had two related issues: The width calculation is >> incorrect when dealing with characters which are not full-sized (they >> are being calculated as though they were full-sized) > > Sorry, I don't understand: is this due to my patch? My patch isn't > supposed to touch the case of characters, only that of inline images. > Was this problem present before my patch? If not, can you show an > example of it? No, sorry, I didn't mean to imply that. This was happening before as well, but it's similar enough, so I figured I would bring it up in case a small tweak is enough to fix it. > Hmm... you say "there is an image from line start to point", but in > the example you show the image is not at the beginning of a line. Did > I misunderstand what you are describing? I was referring to an image being present somewhere in the line before the point, but the patch seems to have fixed it, so that's fine.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 20 Mar 2025 11:17:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 20 07:17:23 2025
Received: from localhost ([127.0.0.1]:55634 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tvDtq-0005Wl-EH
for submit <at> debbugs.gnu.org; Thu, 20 Mar 2025 07:17:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:55794)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tvDtn-0005WV-Qh
for 76107 <at> debbugs.gnu.org; Thu, 20 Mar 2025 07:17:20 -0400
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 <eliz@HIDDEN>)
id 1tvDti-00059A-H1; Thu, 20 Mar 2025 07:17:14 -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=Bym8lmVQ9kIsae04KLvaIVRHUp3maQad0gPwG+4Z/P8=; b=YQtWbgvXg8cz
tUmOnbs4zx67wKWKnaKhFYiQqgHmFwFPg86rFMIH14xFDEUzZAEAkyoJUIIYYUayBU5Qfl05YtV0s
pAVIrHlxnqK0jFfQyuIyBCaSRxCeF/5CPZqP6QyIb1rK25xw3oUeDQMY3oHKvCJ8oaI3aLEY/Mr5Y
p3zR3IoP+/bb7sMiv+0ctmXW8y8dmjZpXCHVisJZzje24a2P/xtdMBMVk78fFdBYaNAKhr3Dnb0WL
/Qz9CXp25Y53vyj596uPuXHy4SW0OCF7NBB89rEbIGlwtejuCrDJDw/WPsA94OQwNLYB5Ld9GqIk7
YaNyGC/E7PEeFljIRhORfg==;
Date: Thu, 20 Mar 2025 13:17:03 +0200
Message-Id: <868qp0ne8g.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Thuna <thuna.cing@HIDDEN>
In-Reply-To: <87ecyv9jzq.fsf@HIDDEN> (message from Thuna on Tue, 18 Mar
2025 02:59:37 +0100)
Subject: Re: bug#76107: Consider image specs when scanning for a column
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
<87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN>
<86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN>
<86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN>
<87o6yga49p.fsf@HIDDEN> <86h647psbt.fsf@HIDDEN> <87ecyv9jzq.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Thuna <thuna.cing@HIDDEN>
> Cc: 76107 <at> debbugs.gnu.org
> Date: Tue, 18 Mar 2025 02:59:37 +0100
>
> I have been using the patch for a while now. I have just been using it
> for regular tasks, so I have not been explicitly testing any edge cases.
>
> I have not yet had any crashes, and as far as I can see, image sizes are
> being calculated correctly.
Thanks, that's good news.
> So far, I have only had two related issues: The width calculation is
> incorrect when dealing with characters which are not full-sized (they
> are being calculated as though they were full-sized)
Sorry, I don't understand: is this due to my patch? My patch isn't
supposed to touch the case of characters, only that of inline images.
Was this problem present before my patch? If not, can you show an
example of it?
> and left margin[1] is being included in the column number, but only
> when there is an image from line start to point.
>
> For the second situation, here's the MRE:
> 1. emacs -q
> 2. Switch to a new buffer, turn on org-mode, insert the text
> > foo \( \mathbb{R}^{*} \)
> 3. Call org-latex-preview on the latex fragment.
> 4. Eval (current-column) at the start of line, end of "foo", and the end
> of line, you should see 0, 3, and 6.
> 5. Turn on display-line-numbers-mode, and repeat above, you should now
> see 0, 3, and 10.
>
> Alternatively, you could have the buffer contents be
> > --------
> > * Foo
> > foo \( \mathbb{R}^{*} \)
> and turn on org-indent-mode (but not display-line-numbers-mode). You'll
> then see that the column at the end of the latex preview is the same as
> if it were calculated from the left edge of the buffer (using the dashes
> as reference).
Hmm... you say "there is an image from line start to point", but in
the example you show the image is not at the beginning of a line. Did
I misunderstand what you are describing?
Anyway, I think I fixed this subtle issue in the patch below, which
should _replace_ the previous one. If you want to apply the new
change incrementally, then just add this one line:
it.hpos = 1;
after this line in the patched code you were using until now:
it.last_visible_x = 1000000; /* prevent image clipping */
> [1] That's probably what it is? The specific thing I am
> referring to is org-indent-mode and display-line-numbers-mode, which I
> assume works using left margin.
No, that's not the margin. In org-indent-mode, the whitespace is the
line-prefix, and in display-line-numbers-mode it's the space reserved
for the line numbers.
Thanks again for testing this improvement. Here's the full patch
relative to the current master:
diff --git a/src/indent.c b/src/indent.c
index 01cea22..cb09f3e 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -466,13 +466,21 @@ current_column (void)
}
+static void restore_window_buffer (Lisp_Object);
+
/* Check the presence of a display property and compute its width.
+ POS and POS_BYTE are the character and byte positions of the
+ display property and COL is the column number at POS.
If a property was found and its width was found as well, return
its width (>= 0) and set the position of the end of the property
in ENDPOS.
- Otherwise just return -1. */
+ Otherwise just return -1.
+ WINDOW is the window to use when it is important; nil stands for
+ the selected window. */
static int
-check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
+check_display_width (Lisp_Object window,
+ ptrdiff_t pos, ptrdiff_t pos_byte, ptrdiff_t col,
+ ptrdiff_t *endpos)
{
Lisp_Object val, overlay;
@@ -482,30 +490,80 @@ check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
int width = -1;
Lisp_Object plist = Qnil;
- /* Handle '(space ...)' display specs. */
- if (CONSP (val) && EQ (Qspace, XCAR (val)))
- { /* FIXME: Use calc_pixel_width_or_height. */
- Lisp_Object prop;
- EMACS_INT align_to_max =
- (col < MOST_POSITIVE_FIXNUM - INT_MAX
- ? (EMACS_INT) INT_MAX + col
- : MOST_POSITIVE_FIXNUM);
-
- plist = XCDR (val);
- if ((prop = plist_get (plist, QCwidth),
- RANGED_FIXNUMP (0, prop, INT_MAX))
- || (prop = plist_get (plist, QCrelative_width),
- RANGED_FIXNUMP (0, prop, INT_MAX)))
- width = XFIXNUM (prop);
- else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
- && XFLOAT_DATA (prop) <= INT_MAX)
- width = (int)(XFLOAT_DATA (prop) + 0.5);
- else if ((prop = plist_get (plist, QCalign_to),
- RANGED_FIXNUMP (col, prop, align_to_max)))
- width = XFIXNUM (prop) - col;
- else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
- && (XFLOAT_DATA (prop) <= align_to_max))
- width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ if (CONSP (val))
+ {
+ Lisp_Object xcar = XCAR (val);
+
+ /* Handle '(space ...)' display specs. */
+ if (EQ (Qspace, xcar))
+ { /* FIXME: Use calc_pixel_width_or_height. */
+ Lisp_Object prop;
+ EMACS_INT align_to_max =
+ (col < MOST_POSITIVE_FIXNUM - INT_MAX
+ ? (EMACS_INT) INT_MAX + col
+ : MOST_POSITIVE_FIXNUM);
+
+ plist = XCDR (val);
+ if ((prop = plist_get (plist, QCwidth),
+ RANGED_FIXNUMP (0, prop, INT_MAX))
+ || (prop = plist_get (plist, QCrelative_width),
+ RANGED_FIXNUMP (0, prop, INT_MAX)))
+ width = XFIXNUM (prop);
+ else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
+ && XFLOAT_DATA (prop) <= INT_MAX)
+ width = (int)(XFLOAT_DATA (prop) + 0.5);
+ else if ((prop = plist_get (plist, QCalign_to),
+ RANGED_FIXNUMP (col, prop, align_to_max)))
+ width = XFIXNUM (prop) - col;
+ else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
+ && (XFLOAT_DATA (prop) <= align_to_max))
+ width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ }
+ /* Handle images. */
+ else if (EQ (Qimage, xcar)
+ || EQ (Qslice, xcar)
+ /* 'insert-sliced-image' creates property of the form
+ ((slice ...) image ...) */
+ || (CONSP (xcar) && EQ (Qslice, XCAR (xcar))))
+ {
+ specpdl_ref count = SPECPDL_INDEX ();
+ struct window *w = decode_live_window (window);
+
+ /* If needed, set the window's buffer temporarily to the
+ current buffer and its window-point to POS. */
+ if (XBUFFER (w->contents) != current_buffer)
+ {
+ Lisp_Object oldbuf
+ = list4 (window, w->contents,
+ make_fixnum (marker_position (w->pointm)),
+ make_fixnum (marker_byte_position (w->pointm)));
+ record_unwind_protect (restore_window_buffer, oldbuf);
+ wset_buffer (w, Fcurrent_buffer ());
+ set_marker_both (w->pointm, w->contents, pos, pos_byte);
+ }
+
+ struct text_pos startpos;
+ struct it it;
+ SET_TEXT_POS (startpos, pos, pos_byte);
+ void *itdata = bidi_shelve_cache ();
+ record_unwind_protect_void (unwind_display_working_on_window);
+ display_working_on_window_p = true;
+ start_display (&it, w, startpos);
+ it.last_visible_x = 1000000; /* prevent image clipping */
+ /* Forcing HPOS non-zero prevents the display code from
+ generating line/wrap-prefix and line numbers, which
+ will skew the X coordinate we use below. */
+ it.hpos = 1;
+ /* The POS+1 value is a trick: move_it_in_display_line
+ will not return until it finished processing the entire
+ image, even if it covers more than one buffer position. */
+ move_it_in_display_line (&it, pos + 1, -1, MOVE_TO_POS);
+ /* The caller wants the width in units of the frame's
+ canonical character width. */
+ width = ((double)it.current_x / FRAME_COLUMN_WIDTH (it.f)) + 0.5;
+ bidi_unshelve_cache (itdata, 0);
+ unbind_to (count, Qnil);
+ }
}
/* Handle 'display' strings. */
else if (STRINGP (val))
@@ -652,7 +710,7 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol,
{ /* Check display property. */
ptrdiff_t endp;
- int width = check_display_width (scan, col, &endp);
+ int width = check_display_width (window, scan, scan_byte, col, &endp);
if (width >= 0)
{
col += width;
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 18 Mar 2025 01:59:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 17 21:59:49 2025
Received: from localhost ([127.0.0.1]:33915 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tuMFB-0002wY-6Q
for submit <at> debbugs.gnu.org; Mon, 17 Mar 2025 21:59:49 -0400
Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:58757)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>)
id 1tuMF8-0002vV-M3
for 76107 <at> debbugs.gnu.org; Mon, 17 Mar 2025 21:59:47 -0400
Received: by mail-wm1-x333.google.com with SMTP id
5b1f17b1804b1-43ce71582e9so18365895e9.1
for <76107 <at> debbugs.gnu.org>; Mon, 17 Mar 2025 18:59:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1742263180; x=1742867980; darn=debbugs.gnu.org;
h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=DTqbAc5aCnKhnevw8V1/tHumYG6S4lAGh+p3/aQKkIo=;
b=i4Tfh6ekUUE+CQScwapGCppZpWl3hOpg75UkRDFP5imRwF5qlB5+8WMk3WhWzXu8e5
48ZEstwSmWDbzorOYPHrGPCjhEtcMkdEBRzFAGQgCxYf2hbV8Wai7de6PPMIX0/10X+c
XQpgM1YRLUWK11fivrbOrjRDajba4YknsOEcuhPPmeRoFET94k9DXO0o5VoxlzIrAnDS
pOEr/NjA5e2c65ByQGYmkJ7x9M4nFRUZ4bM2PZqppXMDxzKvb1fyPUiLI02JaWHsl48D
ivVLwnnSxASEw5I/LICOPn7bEHkMw1eA7twE7/SuHApWu2md7XOZF4/oGtCIo3WlSZlq
drUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1742263180; x=1742867980;
h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=DTqbAc5aCnKhnevw8V1/tHumYG6S4lAGh+p3/aQKkIo=;
b=NtCo5jepNQjbb5zJg50GKbcBUgdbNV6zeaXLEqqs3YRLu1UToqX91BbBKhyAKcV7DD
Skej5zuA41drh1ru/WHGO611qV0lQ5K9jFBvfbLdkTSTGrQ+xvXM0XiY/LUQW7vR4TIq
h10nHmqgvSi4bLhKToaVDvB+N3teZzXNzKQ/19EDDS5+jgyKJ7ZZ3yA6znrzKJegTebi
lAcRSVGwmVTG2nnqRUY6yDK+/KZntxyAnNC+4amR4Sf1wtOK9pUvlIP7g6gTuqjft6uS
AdRP8BgEZc1hrguRirKBt/OmLB+Mv0aMxfNDWU53JrdWjBbhXhOzwEr6TdWjLFqwLen4
pzHg==
X-Gm-Message-State: AOJu0Yz3pCnWHSpG0J6TPx5baUPljJTpUbIy3FrdnvalPw9egA7yKJIa
oXb4EcjZS65EkHwN+zUgzxVa2y0aaJMfRLlkIhr2dihdfsq7OIoxj0k5rP/LIUOYPg==
X-Gm-Gg: ASbGnct8NDghX0YUyU78QIwbVxJaJ1m1R2QfSOAa43oJWapeLaBBFysRwMuCfiautBq
gFK5sLQSo6OO5MjbMbDaAcRJFFeMLx4qWm4x7NowhZ3ipQjDcGWy3fBxxW8ZYkqGYiq93YtcTRG
KUyq9w3HQj7LnT/VHPgy+8vBTXPoN4TJ3dUbVvWERF15yrnCaZeHnAETPQJNwYDLNyONWbznr11
ZpgNnbirtPBN1Kdig70YSKyNDzv3yhgs9uItsPsVxVA7CHMusHh7tSdOFf8s5SdbXmCmzeAJNfm
Y4jrGy+hc28OMiGNMKCXwNg9Ud2gm6QZNuQ4SQ5q4fRo
X-Google-Smtp-Source: AGHT+IHs63HvUppEmCKl8h45QP2Ab6VeoVHATSn9ij6EOMCrICLF88XJawfDfSGIcpK8fEgwV1HVJQ==
X-Received: by 2002:a05:600c:4e86:b0:43d:54a:221c with SMTP id
5b1f17b1804b1-43d3b9a928cmr2948015e9.18.1742263179332;
Mon, 17 Mar 2025 18:59:39 -0700 (PDT)
Received: from thuna-lis3 ([178.249.211.70]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-43d1fe2927fsm119918275e9.18.2025.03.17.18.59.38
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 17 Mar 2025 18:59:38 -0700 (PDT)
From: Thuna <thuna.cing@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76107: Consider image specs when scanning for a column
In-Reply-To: <86h647psbt.fsf@HIDDEN>
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
<87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN>
<86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN>
<86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN>
<87o6yga49p.fsf@HIDDEN> <86h647psbt.fsf@HIDDEN>
Date: Tue, 18 Mar 2025 02:59:37 +0100
Message-ID: <87ecyv9jzq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
I have been using the patch for a while now. I have just been using it
for regular tasks, so I have not been explicitly testing any edge cases.
I have not yet had any crashes, and as far as I can see, image sizes are
being calculated correctly.
So far, I have only had two related issues: The width calculation is
incorrect when dealing with characters which are not full-sized (they
are being calculated as though they were full-sized), and left margin[1]
is being included in the column number, but only when there is an image
from line start to point.
For the second situation, here's the MRE:
1. emacs -q
2. Switch to a new buffer, turn on org-mode, insert the text
> foo \( \mathbb{R}^{*} \)
3. Call org-latex-preview on the latex fragment.
4. Eval (current-column) at the start of line, end of "foo", and the end
of line, you should see 0, 3, and 6.
5. Turn on display-line-numbers-mode, and repeat above, you should now
see 0, 3, and 10.
Alternatively, you could have the buffer contents be
> --------
> * Foo
> foo \( \mathbb{R}^{*} \)
and turn on org-indent-mode (but not display-line-numbers-mode). You'll
then see that the column at the end of the latex preview is the same as
if it were calculated from the left edge of the buffer (using the dashes
as reference).
[1] That's probably what it is? The specific thing I am
referring to is org-indent-mode and display-line-numbers-mode, which I
assume works using left margin.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 5 Mar 2025 12:36:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 05 07:36:49 2025
Received: from localhost ([127.0.0.1]:36007 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tpnzU-0007eW-Tj
for submit <at> debbugs.gnu.org; Wed, 05 Mar 2025 07:36:49 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:60858)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tpnzS-0007eH-9b
for 76107 <at> debbugs.gnu.org; Wed, 05 Mar 2025 07:36:46 -0500
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 <eliz@HIDDEN>)
id 1tpnzM-00032Q-Vz; Wed, 05 Mar 2025 07:36:41 -0500
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=gjtpTk0xThdFNtLv7kVbT8Roh9bC5P2RRPt4S/ssik8=; b=jrp1mjE6tGGS
+X/6VFs2uRwfkD4l3Jo8UVAZgMGiJjrk9rzIR4a3HbDlh+dyg16l9HogzpcpKIGkWxOIwAltWJPNV
7TXqb6fzo9DNKE5rsNM4DhZ/aqkg3nnThBfD5KHnRATWEH+IC4H/js89nUj+YIxuSHbK7yy2lSrl/
Gzc1oEE1meDZET0PLKQANaQ3aSXPABLEDysH/3zgUfn3jwatfUqlq9uXP2DBdHManYu6QGylFWwDr
TpgXKwORPYlv9vma2Ejl3Dl0Npk5Bkgt62elmGrasG+56/YblHY72/jcidMWF471Aa5p68MdEOS6O
tkUyjpW9KnZ4jgECf2bgOg==;
Date: Wed, 05 Mar 2025 14:36:38 +0200
Message-Id: <86h647psbt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Thuna <thuna.cing@HIDDEN>
In-Reply-To: <87o6yga49p.fsf@HIDDEN> (message from Thuna on Tue, 04 Mar
2025 22:13:06 +0100)
Subject: Re: bug#76107: Consider image specs when scanning for a column
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
<87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN>
<86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN>
<86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN>
<87o6yga49p.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Thuna <thuna.cing@HIDDEN>
> Cc: 76107 <at> debbugs.gnu.org
> Date: Tue, 04 Mar 2025 22:13:06 +0100
>
> > Ping! Did you have time to try the patch I suggested?
> Sorry, I wasn't able to find the time.
>
> I also couldn't apply the patch, could you attach it as a separate file?
The patch is below, thanks in advance for any feedback.
diff --git a/src/indent.c b/src/indent.c
index 01cea22..c90d2f0 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -466,13 +466,21 @@ current_column (void)
}
+static void restore_window_buffer (Lisp_Object);
+
/* Check the presence of a display property and compute its width.
+ POS and POS_BYTE are the character and byte positions of the
+ display property and COL is the column number at POS.
If a property was found and its width was found as well, return
its width (>= 0) and set the position of the end of the property
in ENDPOS.
- Otherwise just return -1. */
+ Otherwise just return -1.
+ WINDOW is the window to use when it is important; nil stands for
+ the selected window. */
static int
-check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
+check_display_width (Lisp_Object window,
+ ptrdiff_t pos, ptrdiff_t pos_byte, ptrdiff_t col,
+ ptrdiff_t *endpos)
{
Lisp_Object val, overlay;
@@ -482,30 +490,76 @@ check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
int width = -1;
Lisp_Object plist = Qnil;
- /* Handle '(space ...)' display specs. */
- if (CONSP (val) && EQ (Qspace, XCAR (val)))
- { /* FIXME: Use calc_pixel_width_or_height. */
- Lisp_Object prop;
- EMACS_INT align_to_max =
- (col < MOST_POSITIVE_FIXNUM - INT_MAX
- ? (EMACS_INT) INT_MAX + col
- : MOST_POSITIVE_FIXNUM);
-
- plist = XCDR (val);
- if ((prop = plist_get (plist, QCwidth),
- RANGED_FIXNUMP (0, prop, INT_MAX))
- || (prop = plist_get (plist, QCrelative_width),
- RANGED_FIXNUMP (0, prop, INT_MAX)))
- width = XFIXNUM (prop);
- else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
- && XFLOAT_DATA (prop) <= INT_MAX)
- width = (int)(XFLOAT_DATA (prop) + 0.5);
- else if ((prop = plist_get (plist, QCalign_to),
- RANGED_FIXNUMP (col, prop, align_to_max)))
- width = XFIXNUM (prop) - col;
- else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
- && (XFLOAT_DATA (prop) <= align_to_max))
- width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ if (CONSP (val))
+ {
+ Lisp_Object xcar = XCAR (val);
+
+ /* Handle '(space ...)' display specs. */
+ if (EQ (Qspace, xcar))
+ { /* FIXME: Use calc_pixel_width_or_height. */
+ Lisp_Object prop;
+ EMACS_INT align_to_max =
+ (col < MOST_POSITIVE_FIXNUM - INT_MAX
+ ? (EMACS_INT) INT_MAX + col
+ : MOST_POSITIVE_FIXNUM);
+
+ plist = XCDR (val);
+ if ((prop = plist_get (plist, QCwidth),
+ RANGED_FIXNUMP (0, prop, INT_MAX))
+ || (prop = plist_get (plist, QCrelative_width),
+ RANGED_FIXNUMP (0, prop, INT_MAX)))
+ width = XFIXNUM (prop);
+ else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
+ && XFLOAT_DATA (prop) <= INT_MAX)
+ width = (int)(XFLOAT_DATA (prop) + 0.5);
+ else if ((prop = plist_get (plist, QCalign_to),
+ RANGED_FIXNUMP (col, prop, align_to_max)))
+ width = XFIXNUM (prop) - col;
+ else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
+ && (XFLOAT_DATA (prop) <= align_to_max))
+ width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ }
+ /* Handle images. */
+ else if (EQ (Qimage, xcar)
+ || EQ (Qslice, xcar)
+ /* 'insert-sliced-image' creates property of the form
+ ((slice ...) image ...) */
+ || (CONSP (xcar) && EQ (Qslice, XCAR (xcar))))
+ {
+ specpdl_ref count = SPECPDL_INDEX ();
+ struct window *w = decode_live_window (window);
+
+ /* If needed, set the window's buffer temporarily to the
+ current buffer and its window-point to POS. */
+ if (XBUFFER (w->contents) != current_buffer)
+ {
+ Lisp_Object oldbuf
+ = list4 (window, w->contents,
+ make_fixnum (marker_position (w->pointm)),
+ make_fixnum (marker_byte_position (w->pointm)));
+ record_unwind_protect (restore_window_buffer, oldbuf);
+ wset_buffer (w, Fcurrent_buffer ());
+ set_marker_both (w->pointm, w->contents, pos, pos_byte);
+ }
+
+ struct text_pos startpos;
+ struct it it;
+ SET_TEXT_POS (startpos, pos, pos_byte);
+ void *itdata = bidi_shelve_cache ();
+ record_unwind_protect_void (unwind_display_working_on_window);
+ display_working_on_window_p = true;
+ start_display (&it, w, startpos);
+ it.last_visible_x = 1000000; /* prevent image clipping */
+ /* The POS+1 value is a trick: move_it_in_display_line
+ will not return until it finished processing the entire
+ image, even if it covers more than one buffer position. */
+ move_it_in_display_line (&it, pos + 1, -1, MOVE_TO_POS);
+ /* The caller wants the width in units of the frame's
+ canonical character width. */
+ width = ((double)it.current_x / FRAME_COLUMN_WIDTH (it.f)) + 0.5;
+ bidi_unshelve_cache (itdata, 0);
+ unbind_to (count, Qnil);
+ }
}
/* Handle 'display' strings. */
else if (STRINGP (val))
@@ -652,7 +706,7 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol,
{ /* Check display property. */
ptrdiff_t endp;
- int width = check_display_width (scan, col, &endp);
+ int width = check_display_width (window, scan, scan_byte, col, &endp);
if (width >= 0)
{
col += width;
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 4 Mar 2025 21:13:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 04 16:13:17 2025 Received: from localhost ([127.0.0.1]:33215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tpZZl-0000Tt-8K for submit <at> debbugs.gnu.org; Tue, 04 Mar 2025 16:13:17 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:43411) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tpZZi-0000Te-Fd for 76107 <at> debbugs.gnu.org; Tue, 04 Mar 2025 16:13:14 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5e4cbade42aso361832a12.1 for <76107 <at> debbugs.gnu.org>; Tue, 04 Mar 2025 13:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741122788; x=1741727588; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=ngp+eq3w1mRbCpipfAbOYnVxsOxoq864NIbUlUIWZZc=; b=Q4dY/h5FL/8fEddYvP1XnkbMCAie+sw+j/rd7B3sAFZaShssT3zbXqQb229beISQVO Jfvtp1s91DbV804MvjuAd/rvmO2/xOCeIAdnm2nHHmUswOLwCWeCaBWH7/Iyre2tQBUk baXDDP2Iki+YoBhLUDukTMDH8c7qVMwIA1tmfRO1BxRN4x/dE7JfANoaSYb+ucnzsUGy fmdmYGpUlza1iStQDG1jCy3k7KFYXPP18P5vEWW5I+09Po+RXYckYbsnNZytPVd64zEn 4qrb8AGirjPv2lyt51ekLODM656TxVTxUdl7w8B0ZGpDDJxgfxTU3IDuA3f+vb/k/22n tt2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741122788; x=1741727588; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ngp+eq3w1mRbCpipfAbOYnVxsOxoq864NIbUlUIWZZc=; b=NFBBj/TC2BBDeZl+NazWJRY2/u6Q7ABfGd4WJhOxnvUWM7lAECbMaQLrS1T/z8ku3h XiXYE/YjuFAjnqKjhQo7dSLSdiVxcvTIcazBzYspb6s/bUKEXV+azZzGzOLvKU6oLW1z YAxhwsZ1VeEFmOpbrF+kpcFk/63ExJ/ILGl3exYOknLzd5TPKseKtEXxlQE2JJkMnk59 acZc148sa5O9NzGzKjAXX+B9RNdJdTXz1w7Zr2qjuG3in07zxPHYc/QhJEVR3+9V12aI irtHjSO/5EWn9ptvayyZ+Zhv/5cFwe5YOEIfi3euryIfPv5hNXbegKwvSWtaUzLd4anL ArNg== X-Gm-Message-State: AOJu0YyM7etsod4fZrsMwDadAjCo1MiookUyeHviuz/qInnUUI+brCK6 um+VVg9H6cgPuLrXL8Q9uRCEYCcSDRIuJ9CyVixFBOwXcGXaNdRGlbea/hko2vik2g== X-Gm-Gg: ASbGnctjuCERdzFU9R+MPoKU2SosAvg8Sg9F547ny0zmUfq0rpyuzTwYS/NrlVQAptl 1Lxm65Lj8Jsr4kK0nl0+mzKRkSkxx+TSkTTdXUbYTkvhHieQZuydiEuVyxcQ2LJw44febeKKXwG TxXeiv8djKR6gFHnpvDXMflUAUDG2DpcVGhpCiozkdWuIT0IiZiuFbrBPzncEcIUY0kEOSu2JLZ Iu29WOgRuFAaBNCDiGyqBT1iMHbodJpC4ka6olNMBw8MT8CJoNAgSDnBD8XGNgyEH7AH5MCF4yo TaHK45VMYD8POnPEGBW7Puto4RFq2w8V5kzZIW9aznCy X-Google-Smtp-Source: AGHT+IGttLPkNHY/MXVWoIxMCjplL2X/+bzsAt7c93ZZ+nZ5cj3XlQ9yehPjzXu21HqKMsCONJWjwg== X-Received: by 2002:a17:907:1c9e:b0:ac0:4364:407e with SMTP id a640c23a62f3a-ac20ecf9663mr53589866b.4.1741122787784; Tue, 04 Mar 2025 13:13:07 -0800 (PST) Received: from thuna-lis3 ([178.249.211.77]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac1eec40e84sm193591966b.23.2025.03.04.13.13.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Mar 2025 13:13:07 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86senxosxj.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> <86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> <86a5apgdvb.fsf@HIDDEN> <865xlbfvwy.fsf@HIDDEN> <86senxosxj.fsf@HIDDEN> Date: Tue, 04 Mar 2025 22:13:06 +0100 Message-ID: <87o6yga49p.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Ping! Did you have time to try the patch I suggested? Sorry, I wasn't able to find the time. I also couldn't apply the patch, could you attach it as a separate file?
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 1 Mar 2025 12:07:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 07:07:50 2025
Received: from localhost ([127.0.0.1]:34693 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1toLdE-0006JX-5O
for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 07:07:50 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:45594)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1toLdC-0006Iy-Jb
for 76107 <at> debbugs.gnu.org; Sat, 01 Mar 2025 07:07:47 -0500
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 <eliz@HIDDEN>)
id 1toLd5-0006FR-RT; Sat, 01 Mar 2025 07:07:41 -0500
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=ku0anVGEFpP1DeSqKFsBqUcOy0N2Tc4IHpCYc8HO9QA=; b=lVSIiPJUAiT2
tPfzqmhqAM69L9TdUq01nj2NfOLwMjrFE0cMlWE7FCxiDQ9FGRfmVnF9TqA2+pFXay7DoteEkYHn2
iU6ek3miDy9f38hb4gUpDeGZG+ByA/V5kHPZruTHTQKnLy1PFnvBp14x3HUVbvFr3uaS5G05R94Av
Uvrvt5tpKTHPwvfN6ark6jkQdy4utR3RE42K+m1SMhMpMOy6eej7FpCruRtsGrrDqA9QljPfFq7OK
VwD3M6R1LCGPfXKnvWfjn4hqdIOnBxsZVww+bXvbC23KTmncJEe07apcDbye0G0kBpcTle5nOlN8Y
a6T7hAmOsf5RB3AD0dtQkQ==;
Date: Sat, 01 Mar 2025 14:07:36 +0200
Message-Id: <86senxosxj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: thuna.cing@HIDDEN
In-Reply-To: <865xlbfvwy.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 15
Feb 2025 10:34:53 +0200)
Subject: Re: bug#76107: Consider image specs when scanning for a column
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
<87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN>
<86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> <86a5apgdvb.fsf@HIDDEN>
<865xlbfvwy.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Ping! Did you have time to try the patch I suggested?
> Cc: 76107 <at> debbugs.gnu.org
> Date: Sat, 15 Feb 2025 10:34:53 +0200
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > Cc: 76107 <at> debbugs.gnu.org
> > Date: Fri, 14 Feb 2025 09:54:48 +0200
> > From: Eli Zaretskii <eliz@HIDDEN>
> >
> > > From: Thuna <thuna.cing@HIDDEN>
> > > Cc: 76107 <at> debbugs.gnu.org
> > > Date: Thu, 13 Feb 2025 22:45:54 +0100
> > >
> > > > Please tell me if you are or will be working on this, or you are
> > > > waiting for me to do it? I'd like to avoid duplicate work.
> > > I am trying stuff, but the code looks roughly like what I sent before.
> > > It would probably be faster for you to do it.
> >
> > OK, I will work on this.
>
> The proposed patch is below.
>
> You were right: the idea of using produce_image_glyph was not a good
> one, as the code would be too tedious. So I've decided to go with
> higher-level functions instead, as you see below.
>
> I did very little testing of the patch, so please test is as well as
> you can, both with images and slices. The problem here is that image
> and slice specs can have different forms, so the code in
> check_display_width should detect at least the important and popular
> ones, and I'm not sure what's below is sufficient.
>
> If you have any trouble with the patched Emacs, like crashes or
> incorrect results from current-column or move-to-column, please tell
> and show a recipe for reproducing the problems.
>
> Thanks.
>
> diff --git a/src/indent.c b/src/indent.c
> index 01cea22..c90d2f0 100644
> --- a/src/indent.c
> +++ b/src/indent.c
> @@ -466,13 +466,21 @@ current_column (void)
> }
>
>
> +static void restore_window_buffer (Lisp_Object);
> +
> /* Check the presence of a display property and compute its width.
> + POS and POS_BYTE are the character and byte positions of the
> + display property and COL is the column number at POS.
> If a property was found and its width was found as well, return
> its width (>= 0) and set the position of the end of the property
> in ENDPOS.
> - Otherwise just return -1. */
> + Otherwise just return -1.
> + WINDOW is the window to use when it is important; nil stands for
> + the selected window. */
> static int
> -check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
> +check_display_width (Lisp_Object window,
> + ptrdiff_t pos, ptrdiff_t pos_byte, ptrdiff_t col,
> + ptrdiff_t *endpos)
> {
> Lisp_Object val, overlay;
>
> @@ -482,30 +490,76 @@ check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
> int width = -1;
> Lisp_Object plist = Qnil;
>
> - /* Handle '(space ...)' display specs. */
> - if (CONSP (val) && EQ (Qspace, XCAR (val)))
> - { /* FIXME: Use calc_pixel_width_or_height. */
> - Lisp_Object prop;
> - EMACS_INT align_to_max =
> - (col < MOST_POSITIVE_FIXNUM - INT_MAX
> - ? (EMACS_INT) INT_MAX + col
> - : MOST_POSITIVE_FIXNUM);
> -
> - plist = XCDR (val);
> - if ((prop = plist_get (plist, QCwidth),
> - RANGED_FIXNUMP (0, prop, INT_MAX))
> - || (prop = plist_get (plist, QCrelative_width),
> - RANGED_FIXNUMP (0, prop, INT_MAX)))
> - width = XFIXNUM (prop);
> - else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
> - && XFLOAT_DATA (prop) <= INT_MAX)
> - width = (int)(XFLOAT_DATA (prop) + 0.5);
> - else if ((prop = plist_get (plist, QCalign_to),
> - RANGED_FIXNUMP (col, prop, align_to_max)))
> - width = XFIXNUM (prop) - col;
> - else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
> - && (XFLOAT_DATA (prop) <= align_to_max))
> - width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
> + if (CONSP (val))
> + {
> + Lisp_Object xcar = XCAR (val);
> +
> + /* Handle '(space ...)' display specs. */
> + if (EQ (Qspace, xcar))
> + { /* FIXME: Use calc_pixel_width_or_height. */
> + Lisp_Object prop;
> + EMACS_INT align_to_max =
> + (col < MOST_POSITIVE_FIXNUM - INT_MAX
> + ? (EMACS_INT) INT_MAX + col
> + : MOST_POSITIVE_FIXNUM);
> +
> + plist = XCDR (val);
> + if ((prop = plist_get (plist, QCwidth),
> + RANGED_FIXNUMP (0, prop, INT_MAX))
> + || (prop = plist_get (plist, QCrelative_width),
> + RANGED_FIXNUMP (0, prop, INT_MAX)))
> + width = XFIXNUM (prop);
> + else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
> + && XFLOAT_DATA (prop) <= INT_MAX)
> + width = (int)(XFLOAT_DATA (prop) + 0.5);
> + else if ((prop = plist_get (plist, QCalign_to),
> + RANGED_FIXNUMP (col, prop, align_to_max)))
> + width = XFIXNUM (prop) - col;
> + else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
> + && (XFLOAT_DATA (prop) <= align_to_max))
> + width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
> + }
> + /* Handle images. */
> + else if (EQ (Qimage, xcar)
> + || EQ (Qslice, xcar)
> + /* 'insert-sliced-image' creates property of the form
> + ((slice ...) image ...) */
> + || (CONSP (xcar) && EQ (Qslice, XCAR (xcar))))
> + {
> + specpdl_ref count = SPECPDL_INDEX ();
> + struct window *w = decode_live_window (window);
> +
> + /* If needed, set the window's buffer temporarily to the
> + current buffer and its window-point to POS. */
> + if (XBUFFER (w->contents) != current_buffer)
> + {
> + Lisp_Object oldbuf
> + = list4 (window, w->contents,
> + make_fixnum (marker_position (w->pointm)),
> + make_fixnum (marker_byte_position (w->pointm)));
> + record_unwind_protect (restore_window_buffer, oldbuf);
> + wset_buffer (w, Fcurrent_buffer ());
> + set_marker_both (w->pointm, w->contents, pos, pos_byte);
> + }
> +
> + struct text_pos startpos;
> + struct it it;
> + SET_TEXT_POS (startpos, pos, pos_byte);
> + void *itdata = bidi_shelve_cache ();
> + record_unwind_protect_void (unwind_display_working_on_window);
> + display_working_on_window_p = true;
> + start_display (&it, w, startpos);
> + it.last_visible_x = 1000000; /* prevent image clipping */
> + /* The POS+1 value is a trick: move_it_in_display_line
> + will not return until it finished processing the entire
> + image, even if it covers more than one buffer position. */
> + move_it_in_display_line (&it, pos + 1, -1, MOVE_TO_POS);
> + /* The caller wants the width in units of the frame's
> + canonical character width. */
> + width = ((double)it.current_x / FRAME_COLUMN_WIDTH (it.f)) + 0.5;
> + bidi_unshelve_cache (itdata, 0);
> + unbind_to (count, Qnil);
> + }
> }
> /* Handle 'display' strings. */
> else if (STRINGP (val))
> @@ -652,7 +706,7 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol,
>
> { /* Check display property. */
> ptrdiff_t endp;
> - int width = check_display_width (scan, col, &endp);
> + int width = check_display_width (window, scan, scan_byte, col, &endp);
> if (width >= 0)
> {
> col += width;
>
>
>
>
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 15 Feb 2025 08:35:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 15 03:35:07 2025
Received: from localhost ([127.0.0.1]:53271 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tjDdi-0005qv-Mx
for submit <at> debbugs.gnu.org; Sat, 15 Feb 2025 03:35:07 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:59994)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tjDdf-0005qE-Oz
for 76107 <at> debbugs.gnu.org; Sat, 15 Feb 2025 03:35:04 -0500
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 <eliz@HIDDEN>)
id 1tjDda-0004Ob-FQ; Sat, 15 Feb 2025 03:34:58 -0500
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=evrsHWNij8TjQTPEMNlS4i1zGJrsxDtmMHJ/gvv7ANs=; b=g/pdhDkLd+50
VxlD+1IaApIAXjBFwwukXP4nXyTYH+/XMHQgB80k90E+GDkBM1yA/n8HrE0s9Qvi+E5FDgkEmWsTr
UI4xJTdbXOWsgDYtCdW5J+SMwskqrMDe7OGJUhCf22T/6cjfyFf6RudMQxHkBgk/iqveLQgbf8SJr
Zu+L/hW4FhPMfD2hG49QXywTDCW1A0LLErnE8Wv62d8ljy4hTSlgA94vqaTtp7xA2j6g7REYOJ/dB
RgQ4bwzoQi66N9KDpJxvPqbbyYd/0McZ700KyUUMVDw/cRvR0d0ny/kHVJWgx0/GHCgAL55cxOBJZ
qSzx4V7C1kyZnHe092O7rA==;
Date: Sat, 15 Feb 2025 10:34:53 +0200
Message-Id: <865xlbfvwy.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: thuna.cing@HIDDEN
In-Reply-To: <86a5apgdvb.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 14
Feb 2025 09:54:48 +0200)
Subject: Re: bug#76107: Consider image specs when scanning for a column
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
<87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN>
<86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> <86a5apgdvb.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: 76107 <at> debbugs.gnu.org
> Date: Fri, 14 Feb 2025 09:54:48 +0200
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > From: Thuna <thuna.cing@HIDDEN>
> > Cc: 76107 <at> debbugs.gnu.org
> > Date: Thu, 13 Feb 2025 22:45:54 +0100
> >
> > > Please tell me if you are or will be working on this, or you are
> > > waiting for me to do it? I'd like to avoid duplicate work.
> > I am trying stuff, but the code looks roughly like what I sent before.
> > It would probably be faster for you to do it.
>
> OK, I will work on this.
The proposed patch is below.
You were right: the idea of using produce_image_glyph was not a good
one, as the code would be too tedious. So I've decided to go with
higher-level functions instead, as you see below.
I did very little testing of the patch, so please test is as well as
you can, both with images and slices. The problem here is that image
and slice specs can have different forms, so the code in
check_display_width should detect at least the important and popular
ones, and I'm not sure what's below is sufficient.
If you have any trouble with the patched Emacs, like crashes or
incorrect results from current-column or move-to-column, please tell
and show a recipe for reproducing the problems.
Thanks.
diff --git a/src/indent.c b/src/indent.c
index 01cea22..c90d2f0 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -466,13 +466,21 @@ current_column (void)
}
+static void restore_window_buffer (Lisp_Object);
+
/* Check the presence of a display property and compute its width.
+ POS and POS_BYTE are the character and byte positions of the
+ display property and COL is the column number at POS.
If a property was found and its width was found as well, return
its width (>= 0) and set the position of the end of the property
in ENDPOS.
- Otherwise just return -1. */
+ Otherwise just return -1.
+ WINDOW is the window to use when it is important; nil stands for
+ the selected window. */
static int
-check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
+check_display_width (Lisp_Object window,
+ ptrdiff_t pos, ptrdiff_t pos_byte, ptrdiff_t col,
+ ptrdiff_t *endpos)
{
Lisp_Object val, overlay;
@@ -482,30 +490,76 @@ check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
int width = -1;
Lisp_Object plist = Qnil;
- /* Handle '(space ...)' display specs. */
- if (CONSP (val) && EQ (Qspace, XCAR (val)))
- { /* FIXME: Use calc_pixel_width_or_height. */
- Lisp_Object prop;
- EMACS_INT align_to_max =
- (col < MOST_POSITIVE_FIXNUM - INT_MAX
- ? (EMACS_INT) INT_MAX + col
- : MOST_POSITIVE_FIXNUM);
-
- plist = XCDR (val);
- if ((prop = plist_get (plist, QCwidth),
- RANGED_FIXNUMP (0, prop, INT_MAX))
- || (prop = plist_get (plist, QCrelative_width),
- RANGED_FIXNUMP (0, prop, INT_MAX)))
- width = XFIXNUM (prop);
- else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
- && XFLOAT_DATA (prop) <= INT_MAX)
- width = (int)(XFLOAT_DATA (prop) + 0.5);
- else if ((prop = plist_get (plist, QCalign_to),
- RANGED_FIXNUMP (col, prop, align_to_max)))
- width = XFIXNUM (prop) - col;
- else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
- && (XFLOAT_DATA (prop) <= align_to_max))
- width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ if (CONSP (val))
+ {
+ Lisp_Object xcar = XCAR (val);
+
+ /* Handle '(space ...)' display specs. */
+ if (EQ (Qspace, xcar))
+ { /* FIXME: Use calc_pixel_width_or_height. */
+ Lisp_Object prop;
+ EMACS_INT align_to_max =
+ (col < MOST_POSITIVE_FIXNUM - INT_MAX
+ ? (EMACS_INT) INT_MAX + col
+ : MOST_POSITIVE_FIXNUM);
+
+ plist = XCDR (val);
+ if ((prop = plist_get (plist, QCwidth),
+ RANGED_FIXNUMP (0, prop, INT_MAX))
+ || (prop = plist_get (plist, QCrelative_width),
+ RANGED_FIXNUMP (0, prop, INT_MAX)))
+ width = XFIXNUM (prop);
+ else if (FLOATP (prop) && 0 <= XFLOAT_DATA (prop)
+ && XFLOAT_DATA (prop) <= INT_MAX)
+ width = (int)(XFLOAT_DATA (prop) + 0.5);
+ else if ((prop = plist_get (plist, QCalign_to),
+ RANGED_FIXNUMP (col, prop, align_to_max)))
+ width = XFIXNUM (prop) - col;
+ else if (FLOATP (prop) && col <= XFLOAT_DATA (prop)
+ && (XFLOAT_DATA (prop) <= align_to_max))
+ width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
+ }
+ /* Handle images. */
+ else if (EQ (Qimage, xcar)
+ || EQ (Qslice, xcar)
+ /* 'insert-sliced-image' creates property of the form
+ ((slice ...) image ...) */
+ || (CONSP (xcar) && EQ (Qslice, XCAR (xcar))))
+ {
+ specpdl_ref count = SPECPDL_INDEX ();
+ struct window *w = decode_live_window (window);
+
+ /* If needed, set the window's buffer temporarily to the
+ current buffer and its window-point to POS. */
+ if (XBUFFER (w->contents) != current_buffer)
+ {
+ Lisp_Object oldbuf
+ = list4 (window, w->contents,
+ make_fixnum (marker_position (w->pointm)),
+ make_fixnum (marker_byte_position (w->pointm)));
+ record_unwind_protect (restore_window_buffer, oldbuf);
+ wset_buffer (w, Fcurrent_buffer ());
+ set_marker_both (w->pointm, w->contents, pos, pos_byte);
+ }
+
+ struct text_pos startpos;
+ struct it it;
+ SET_TEXT_POS (startpos, pos, pos_byte);
+ void *itdata = bidi_shelve_cache ();
+ record_unwind_protect_void (unwind_display_working_on_window);
+ display_working_on_window_p = true;
+ start_display (&it, w, startpos);
+ it.last_visible_x = 1000000; /* prevent image clipping */
+ /* The POS+1 value is a trick: move_it_in_display_line
+ will not return until it finished processing the entire
+ image, even if it covers more than one buffer position. */
+ move_it_in_display_line (&it, pos + 1, -1, MOVE_TO_POS);
+ /* The caller wants the width in units of the frame's
+ canonical character width. */
+ width = ((double)it.current_x / FRAME_COLUMN_WIDTH (it.f)) + 0.5;
+ bidi_unshelve_cache (itdata, 0);
+ unbind_to (count, Qnil);
+ }
}
/* Handle 'display' strings. */
else if (STRINGP (val))
@@ -652,7 +706,7 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol,
{ /* Check display property. */
ptrdiff_t endp;
- int width = check_display_width (scan, col, &endp);
+ int width = check_display_width (window, scan, scan_byte, col, &endp);
if (width >= 0)
{
col += width;
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 14 Feb 2025 07:55:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 14 02:55:18 2025 Received: from localhost ([127.0.0.1]:46872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiqXd-0004Wm-Sj for submit <at> debbugs.gnu.org; Fri, 14 Feb 2025 02:55:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35920) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tiqXb-0004RF-2e for 76107 <at> debbugs.gnu.org; Fri, 14 Feb 2025 02:55:16 -0500 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 <eliz@HIDDEN>) id 1tiqXV-0000Cz-83; Fri, 14 Feb 2025 02:55:09 -0500 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=c4nyBvS4NI3afizIto41/Z8/GAYEGLsbOm1+B4Y0OT0=; b=k9wSrdkQxiN2 Qr/gpVEdUiGzJW/qKnHVKD/cMdnRkyJYr++hzU+Y/umSPzwxrplAKr660i7ZC1tQSpGv0C1x+RiWM W9nOOKsho3eb2tP1QxYRfNsGvVu9ZxuyE+I3FMTvfiyXzk/WXCImQh8Nw1Rxp2Xu/0S+UW757zfLn kdCdqu8TuZZGe6sY5supMqba86dbq3O6ptvOqQbUDBNWOMRpACs/j3GE0ztuaiNQolX7wjgPJpjna vveAsVFooV6KFhYiymk5e1B2hDWyh7PJwbg7yKFYMHNHMQQgStg6PQ80PMWPT/u6rdZDmtUenZhOt ZI8xwt6OLEPdL4BczY2tmA==; Date: Fri, 14 Feb 2025 09:54:48 +0200 Message-Id: <86a5apgdvb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87v7tda57x.fsf@HIDDEN> (message from Thuna on Thu, 13 Feb 2025 22:45:54 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> <86ikpei46v.fsf@HIDDEN> <87v7tda57x.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Thu, 13 Feb 2025 22:45:54 +0100 > > > Please tell me if you are or will be working on this, or you are > > waiting for me to do it? I'd like to avoid duplicate work. > I am trying stuff, but the code looks roughly like what I sent before. > It would probably be faster for you to do it. OK, I will work on this. > I have two main problems, in case these help in some way: > > 1. When the current buffer isn't displayed in any window, you need > _something_ for `w', but I don't know what. Maybe make a copy(?) of > the selected window and display the buffer there? I don't see > anything that would achieve that in window.c, though. The selected window (or the window in which the current buffer is displayed, if any, as an optimization) should do, yes. > 2. `gui_produce_glyphs' (which as I understand is a general version of > `produce_image_glyph') doesn't seem to be moving CHARPOS, and I don't > know how to recover that information from `it'. Why do you need to move CHARPOS? The character position should be set to the beginning of the display property whose value is the image spec, if the position at all matters. Anyway, I will work on this soon.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 13 Feb 2025 21:46:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 16:46:04 2025 Received: from localhost ([127.0.0.1]:45889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tih24-0003j6-2J for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 16:46:04 -0500 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:56363) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tih22-0003iO-2U for 76107 <at> debbugs.gnu.org; Thu, 13 Feb 2025 16:46:02 -0500 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ab7d58aa674so208554266b.0 for <76107 <at> debbugs.gnu.org>; Thu, 13 Feb 2025 13:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739483156; x=1740087956; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=2fZYl5KOY2Gx/JULgrzyk0jKYkjEYZ5MgjRjsBibMDI=; b=MOLRcadXlaAiR+vES+eh01umuuDFslDBFse4I0o1BsKfz0oJ6kA6X1KpDBfwIoIPGp otN6IwrYZwJ0bR4pC3QDc4pR1QgI0mwZsu0kd3zmecXNBsdCdBeW7Zb32g/v3sa12/+e GH9kLhcKESe5/PJ67BLBaKi1xdUX+EC6RdNfK4ieWa0WznqVZIUexFUO9MD4mVVDpuN5 XmE+JHztyvDYaalWyuOG9QX+Y3/YV95pCdy9D9z4xoeI28INYehQ12kzHMIuw8uqRT1G z5bjpT/9ZmMoD1B9MehxWhtc+Ro3Lctc5Dn6CvZFluRvu9yKovAkfv+/aNL33v2hG2r+ ktqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739483156; x=1740087956; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2fZYl5KOY2Gx/JULgrzyk0jKYkjEYZ5MgjRjsBibMDI=; b=cu/OMQ7BbYuqVOVPZcJRVg1/pMr5UJu748B06PBPKI3Lint3cPvidOCaGnh4DhMaR+ JGUFGpRxV6wJhGvUGSOld1gLmYQcSbMqej5ED0U70cuE8VEze4pjyKbt7/fxVXWRXUut 49m/FHMOT0Q7brbE7lahvmNdzO1mjIQ4WxKumjKoDu2rQw51WIHZDr3gHrGrY1KBf9Fu vTHqpYf1RPRaa/m8VnKSxG2xE26mw2W5Nft1YI2MOW0v21pBagReUFXln9so7OxoZjwp PR4HmR6Dol0OXGTDWVu4v/MbkbMoaQiy77V4+oTxjRL5pNfDCGq/cXdVXfKX++Li956Y T/jw== X-Gm-Message-State: AOJu0Yx7rkdpNyk1vMHLcuPpI9B2rHYyb56hxpDtINz51nM6wY+F+64J Sf2yuLkUiJ8SOfE7Pd7VEYC4jOQUsD9ms5FJK5c6rHyS/AzfXbtV3opaQboV/3jKCg== X-Gm-Gg: ASbGncukir/y/lCZBpPMvHmyECKMJG2siLhtjmGuGTJDVosxaE+GukighERjIVL83LC c2NzR2NIcBEpv0ZvvOEp62n65C1RZMs2ljdvm0FPX8g6y9h0ZMzVG5dSX0pvB1L473IEONWiyd/ Du28ecL8lUw2PnsFfqvdBmbxzyX0RznieBQwFo22M9E+Pa41iDA3+/Sy3SjlSFfH2ZvDC8BQHmW NnzTf5afNLD4RIvBhIflmy6wkTQXRZtw12rO+8Vjn/KgA8mMmKWrzKjcKbhAQLeOiikpTIXZncQ MUdsyX1/XJnaFGg= X-Google-Smtp-Source: AGHT+IF1OLHaZ5+fWmKTlPRqNgbRuDGtouQu28TqG7QgazJFvXMqFv7PTMbsTtI4bvC+3pIKgHzbuw== X-Received: by 2002:a17:907:7d9f:b0:ab6:f68c:746e with SMTP id a640c23a62f3a-ab7f34afa7dmr851717866b.41.1739483155551; Thu, 13 Feb 2025 13:45:55 -0800 (PST) Received: from thuna-lis3 ([178.249.211.77]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aba5339dd63sm206126466b.151.2025.02.13.13.45.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2025 13:45:55 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86ikpei46v.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> <86ikpei46v.fsf@HIDDEN> Date: Thu, 13 Feb 2025 22:45:54 +0100 Message-ID: <87v7tda57x.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Please tell me if you are or will be working on this, or you are > waiting for me to do it? I'd like to avoid duplicate work. I am trying stuff, but the code looks roughly like what I sent before. It would probably be faster for you to do it. I have two main problems, in case these help in some way: 1. When the current buffer isn't displayed in any window, you need _something_ for `w', but I don't know what. Maybe make a copy(?) of the selected window and display the buffer there? I don't see anything that would achieve that in window.c, though. 2. `gui_produce_glyphs' (which as I understand is a general version of `produce_image_glyph') doesn't seem to be moving CHARPOS, and I don't know how to recover that information from `it'.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 13 Feb 2025 09:29:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 04:29:09 2025 Received: from localhost ([127.0.0.1]:40399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiVWu-0002YJ-MU for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 04:29:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46258) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tiVWr-0002Xg-Rx for 76107 <at> debbugs.gnu.org; Thu, 13 Feb 2025 04:29:06 -0500 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 <eliz@HIDDEN>) id 1tiVWj-00010g-My; Thu, 13 Feb 2025 04:29:00 -0500 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=DszToxdcUCLYoHlcYFYs/C1gKJBuAaTU2OpzkXIBYlQ=; b=ri4MXaRYuI0z aBze8XqWd7XcPBNyYZLRkuXJlB/yemsZzpLX9GdwerkcLri2U3+T6Wv17Vx10Ky/mXPu6144YpIyw +wYozx3q61dbMG3bUHK7DK/31Xaf8xwsFjU7jgC5pWrOtochVwhApH3XIYkbLkdNX9y/cqflT5IKL D6AneiCzA9ehhoebrouSlPaMG/Lyrz+HF1JhZWyhoyo7tcCfBSTS8O3csDJTkKo5SFpmbqRpf72VH p+QfzzeQseu4YrRw47ijs2Npa8xvGgs13htjeA39Nn1xbm0JdkW4h5M8ccGgxl/At8cvZbx6RUFyg I6cQhDuag854ox8Knfz1SQ==; Date: Thu, 13 Feb 2025 11:28:40 +0200 Message-Id: <86ikpei46v.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: thuna.cing@HIDDEN In-Reply-To: <86seolycnx.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 10 Feb 2025 18:42:10 +0200) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> <86seolycnx.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 76107 <at> debbugs.gnu.org > Date: Mon, 10 Feb 2025 18:42:10 +0200 > From: Eli Zaretskii <eliz@HIDDEN> > > > Still, here's my best shot. I have attached a version of > > `scan_for_column' which uses `move_it_in_display_line', which I've > > written with my very limited understanding of how this is all supposed > > to work. I can't even test it, since I don't know how I would go about > > recovering all the `prev*' values, but is it at least _somewhat_ in the > > right direction? > > It is in the right direction, yes. But I see now that we can make it > even simpler: we don't need move_it_in_display_line, we only need to > call produce_image_glyph (after setting up the 'struct it' object as > produce_image_glyph expects). Then the width of the image on display > will be in it->pixel_width, and all that's left is convert that to > columns. > > Then we just need to call this new code from check_display_width when > we find an image display property. The rest of the code in > scan_for_column is okay and doesn't need to be replaced with move_it_* > functions. > > So if you can implement this idea, feel free to show the resulting > patch. Alternatively, wait for a few days until I find enough free > time to sit down and code this myself. Please tell me if you are or will be working on this, or you are waiting for me to do it? I'd like to avoid duplicate work.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 76107) by debbugs.gnu.org; 10 Feb 2025 16:42:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 10 11:42:20 2025 Received: from localhost ([127.0.0.1]:52181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thWrU-0004Mr-BX for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 11:42:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53846) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1thWrR-0004Ma-FV for 76107 <at> debbugs.gnu.org; Mon, 10 Feb 2025 11:42:18 -0500 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 <eliz@HIDDEN>) id 1thWrM-0005zu-6F; Mon, 10 Feb 2025 11:42:12 -0500 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=J0GXK/ryGFEObKpG+9z64wt5KXE3vVqrq5wZrBewWlU=; b=NhxSGAMC9Z9t 024+H/dqmext3cXYsYCp2b4S8G+uS7MRj4UuEvUdPStlCOBWkF3+XRw1e08n6e8WjStbkrWWMdBPz oMQBIngsQTIYG0RAA13cz5Pmf/BqX7IoZuHpalcnngGJr9PkjjC9aGlPSIHbh8NwZ9RIy3Kaw5JxA 77gbzIi43nVOc0FFuOqmKKzVaeX04/wVGnCHDASarE1xQ+CvABS6VhS93H/C9cB6I8StP43xZSnS+ vvZg7qDGShkFSrhwDPX7hbdiPif1UGBxxNATaWYDQRPkDTRfa1fB3b37rQdOsw3N4hK7m1xxs8sVS t4wVtTquVUri8ywwwLssXw==; Date: Mon, 10 Feb 2025 18:42:10 +0200 Message-Id: <86seolycnx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87bjv9hlpx.fsf@HIDDEN> (message from Thuna on Mon, 10 Feb 2025 16:18:34 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN> <87bjv9hlpx.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Mon, 10 Feb 2025 16:18:34 +0100 > > I've attached the code for handle_single_display_spec and > produce_image_glyph, with (what I found to be) irrelevant code elided > and with my comments of what's happening where. If there's nothing else > that's happening between these two steps (and I don't think there is - I > at least can't find any), then the display width (of unsliced images) is > exactly what Fimage_size returns, with the exception of width added due > to `box' face attributes. Ok, so you have already discovered that the box attribute can change the dimensions. My point was exactly that: using the display code will make sure we don't risk such omissions. > I understand where you're coming from, I also do not want to leave > behind an unmaintainable mess. But I do not know xdisp.c enough to > actually be able to make use of it, and I cannot imagine that anyone > else has the motivation. > > Still, here's my best shot. I have attached a version of > `scan_for_column' which uses `move_it_in_display_line', which I've > written with my very limited understanding of how this is all supposed > to work. I can't even test it, since I don't know how I would go about > recovering all the `prev*' values, but is it at least _somewhat_ in the > right direction? It is in the right direction, yes. But I see now that we can make it even simpler: we don't need move_it_in_display_line, we only need to call produce_image_glyph (after setting up the 'struct it' object as produce_image_glyph expects). Then the width of the image on display will be in it->pixel_width, and all that's left is convert that to columns. Then we just need to call this new code from check_display_width when we find an image display property. The rest of the code in scan_for_column is okay and doesn't need to be replaced with move_it_* functions. So if you can implement this idea, feel free to show the resulting patch. Alternatively, wait for a few days until I find enough free time to sit down and code this myself. > I think you misunderstood me; what I mean here is that if there is a > "specialized" fill-paragraph that handles display features, then that > should be _the_ fill-paragraph, and not be its own separate thing. Agreed, but only if the resulting fill-paragraph will not be significantly slower. And it could be significantly slower, since the move_it_* functions are slower than just walking the buffer text one character at a time. If using the "specialized" fill-paragraph becomes significantly slower due to support of images, it would make sense not to use that method if the buffer is known to be devoid of images.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at 76107) by debbugs.gnu.org; 10 Feb 2025 15:18:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 10 10:18:50 2025
Received: from localhost ([127.0.0.1]:51943 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thVYf-0005aO-HA
for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 10:18:50 -0500
Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:45409)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>)
id 1thVYc-0005a7-BC
for 76107 <at> debbugs.gnu.org; Mon, 10 Feb 2025 10:18:47 -0500
Received: by mail-ed1-x52d.google.com with SMTP id
4fb4d7f45d1cf-5de47cf9329so5296657a12.3
for <76107 <at> debbugs.gnu.org>; Mon, 10 Feb 2025 07:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1739200719; x=1739805519; darn=debbugs.gnu.org;
h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=OKhtJlfdHTtrY0uI9/v44wC7bxMPRt5fkGrTZnRQkmg=;
b=iSzJFVgzD/biCqR1Y8z20DiM5LFh0i1T1RnTirYkw56KV/yr73xbumOM2myqzkErt8
EyBNcw74+w7xxzlyYXy5aCF1OpMb6OMpJF/MflLVXtxEXXrn4MC7YC0yl2kF36+tjwmz
hT68iT3sqd8MbuauxwmXTl9vL9ROif3An82iSkMmt9IKYVtN85fvLGfugkxr0WITJ7sY
tRucxfpwR4/p9I4ugTTzE5VMFNTtUKP0zoPqkJNHK3rkA4mM9mqs+ICBRn8QJUZmxnLh
+/vhtqR1WZqoqeDiuxJt5XnNuLLAz8ssFHTQje5wIDNctYukTgCyYJWf/khk2IMsBYG3
hVyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1739200719; x=1739805519;
h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=OKhtJlfdHTtrY0uI9/v44wC7bxMPRt5fkGrTZnRQkmg=;
b=KchfwFsJZmAc9J7DbpU2IXwJTrshQSDWhaqOfXUP9vADMONTLJ+M6uLibYVDHRXj59
tYI4abbqyiQJNzhgmXCoBy0reY9MvV/osgcqby5EZoqkw5CnkEUJv1C7W0cjh45TcN5Y
UPqT9cyEXPOBavgipYZ6EHt9l3/+lqGlSOUgNQ1o5EMK0S93OE5j6+j9Xqw6HNg6elG6
Rogtxr4E/ISNzliTRTZBCttEnP5qOBfYZPWAitPQYYbv8v611kugJFpQcjMmxEmF41yh
q/7FYYRE5EvdrFl1ZuuG0Q2os5IXQm9Hya1Y0QuxCz88n3va57YXH+3CWlQfzlFxf+Tm
Hqsg==
X-Gm-Message-State: AOJu0YyBAyxfM1iC1fVSW2De+0Ao/m4wywgIh6DEXXnRYx1WUWUxOc9L
0WlrhmXT0HiEgooPmDkXXOgKesYH0545zwp2gXxy+OA9fe2FN3tPtizTwALxBaU=
X-Gm-Gg: ASbGnct1MItxdqPt8VZj13jlQdnJhD70sU8+9LpFsLfxgssNz2iFLkstPrsy68RV61G
w6ncqY/dllnWgLp7SO6nQonC2m36xfkk5lKF5ioZP8rJ2XHTHGPDqtOPtHzUdVu3RmR7cUi0L8S
iyANjUpk0MhFizSyRFNtSSlW67hfQSIaRBmIslV0h5q+5XlNg5AUfvqZKnwTHgxrxW4J1PQPe7k
vHkKHbrWfQ1F6VqeF0QGrjVXhv6ZZHUmRLPrYpObw3gqTs1WcqsyvhcUcieKWp9SiQzHuPz5xyj
eLeHm7ddqi2lwdmJ
X-Google-Smtp-Source: AGHT+IEOw73MyY3CGta/2GAjEOAAVxLQxbYW26Hz5a08EFDjJCaIXpsPimZ3sRyuCHb1870/RpO9qw==
X-Received: by 2002:a05:6402:40c7:b0:5de:4a8b:4c9b with SMTP id
4fb4d7f45d1cf-5de9a3dc1dcmr115370a12.15.1739200718893;
Mon, 10 Feb 2025 07:18:38 -0800 (PST)
Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id
4fb4d7f45d1cf-5de5f3f92ccsm4885412a12.66.2025.02.10.07.18.37
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 10 Feb 2025 07:18:38 -0800 (PST)
From: Thuna <thuna.cing@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76107: Consider image specs when scanning for a column
In-Reply-To: <86cyfr1toq.fsf@HIDDEN>
References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN>
<87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN>
<87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN>
<87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN>
<87frkogjz5.fsf@HIDDEN> <86cyfr1toq.fsf@HIDDEN>
Date: Mon, 10 Feb 2025 16:18:34 +0100
Message-ID: <87bjv9hlpx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76107
Cc: 76107 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
> Look at the way images are processed in xdisp.c (starting at
> handle_single_display_spec and then in produce_image_glyph and its
> subroutines). It isn't a single place, and the processing is complex.
> Because of this complex processing spread over several functions, I
> have hard time believing that just calling image-size will produce a
> reliable result, and I don't see how will you prove it does produce a
> reliable result without a lot of testing, unless you use the same code
> as the display engine does. Which is why I suggested to use other
> functions, which do use the display code for this purpose.
I've attached the code for handle_single_display_spec and
produce_image_glyph, with (what I found to be) irrelevant code elided
and with my comments of what's happening where. If there's nothing else
that's happening between these two steps (and I don't think there is - I
at least can't find any), then the display width (of unsliced images) is
exactly what Fimage_size returns, with the exception of width added due
to `box' face attributes. The calculation is simple even when the image
is sliced:
width = min(<slice width>, <image width> - <slice x>)
[+ <image hmargin>, if slice is leftmost]
[+ <image hmargin>, if slice is rightmost]
It is still meaningful to not duplicate the calculations being done, but
I don't think that the way to go is for the width calculators to use the
display code but for the display code to use the width calculators. The
important question for me is this: Does the _actual_ width of a glyph
depend on where it is located in the display? If not (and I imagine
not), then we should not need to simulate the display.
> I'm sorry, but please look at this from my POV: I don't want us to be
> left with a semi-working implementation that we will need to keep
> fixing and maintaining for the years to come. Adding support for
> images to move-to-column means we promise it to work correctly and
> will be expected to fix any inaccuracy people report. Using the
> display code frees us from this problem, because that's what Emacs
> uses to display the images in the first place, so it will always be as
> correct as what we show on display. [...] I don't understand why you
> insist so much on going with Fimage_width and not with the method I
> proposed, I don't think the code will be much more complex.
I understand where you're coming from, I also do not want to leave
behind an unmaintainable mess. But I do not know xdisp.c enough to
actually be able to make use of it, and I cannot imagine that anyone
else has the motivation.
Still, here's my best shot. I have attached a version of
`scan_for_column' which uses `move_it_in_display_line', which I've
written with my very limited understanding of how this is all supposed
to work. I can't even test it, since I don't know how I would go about
recovering all the `prev*' values, but is it at least _somewhat_ in the
right direction?
> So from my POV, either using posn-col-row and vertical-motion in a
> specialized fill-paragraph-function, or using move_it_* functions in
> check_display_width for measuring the column size of an image, are the
> ways of making this improvement that I very much prefer. The latter
> is I think a simpler and better solution, because it doesn't have the
> complications with continuation lines.
>
>> > So if we want fill-paragraph to work in the presence of images and
>> > other display features, we need to have a specialized
>> > fill-paragraph-function which uses posn-col-row instead of
>> > current-column and vertical-motion instead of move-to-column.
>>
>> If we can have a version of fill-paragraph which can calculate image
>> widths, then that should just be _the_ fill-paragraph function.
>
> Images are not the only display complication that current-column and
> move-to-column doesn't handle. For example, they don't support
> xwidgets, and also produce incorrect results when there are display
> strings with embedded newlines. Because of that, fill-paragraph
> doesn't work properly in the presence of these display features.
> Therefore, adding images to it will still not make it work correctly
> in all the cases.
I think you misunderstood me; what I mean here is that if there is a
"specialized" fill-paragraph that handles display features, then that
should be _the_ fill-paragraph, and not be its own separate thing.
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename="commented xdisp.c code.c"
Content-Description: Commented xdisp.c code
static int
handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object,
Lisp_Object overlay, struct text_pos *position,
ptrdiff_t bufpos, int display_replaced,
bool frame_window_p, bool enable_eval_p)
{
Lisp_Object form;
Lisp_Object location, value;
struct text_pos start_pos = *position;
void *itdata = NULL;
/* If SPEC is a list of the form `(when FORM . VALUE)', evaluate FORM.
If the result is non-nil, use VALUE instead of SPEC. */
// ...
/* Handle `(height HEIGHT)' specifications. */
// ...
/* Handle `(space-width WIDTH)'. */
// ...
/* Handle `(min-width (WIDTH))'. */
// ...
// ===== This code sets it->slice to the values we see in the (slice ...) spec =====
/* Handle `(slice X Y WIDTH HEIGHT)'. */
if (CONSP (spec)
&& EQ (XCAR (spec), Qslice))
{
Lisp_Object tem;
if (it)
{
if (!FRAME_WINDOW_P (it->f))
return 0;
if (tem = XCDR (spec), CONSP (tem))
{
it->slice.x = XCAR (tem);
if (tem = XCDR (tem), CONSP (tem))
{
it->slice.y = XCAR (tem);
if (tem = XCDR (tem), CONSP (tem))
{
it->slice.width = XCAR (tem);
if (tem = XCDR (tem), CONSP (tem))
it->slice.height = XCAR (tem);
}
}
}
}
return 0;
}
/* Handle `(raise FACTOR)'. */
// ...
/* Don't handle the other kinds of display specifications
inside a string that we got from a `display' property. */
// ...
/* Characters having this form of property are not displayed, so
we have to find the end of the property. */
// ...
/* Stop the scan at that end position--we assume that all
text properties change there. */
// ...
/* Handle `(left-fringe BITMAP [FACE])'
and `(right-fringe BITMAP [FACE])'. */
// ...
/* Prepare to handle `((margin left-margin) ...)',
`((margin right-margin) ...)' and `((margin nil) ...)'
prefixes for display specifications. */
// ...
/* After this point, VALUE is the property after any
margin prefix has been stripped. It must be a string,
an image specification, or `(space ...)'.
LOCATION specifies where to display: `left-margin',
`right-margin' or nil. */
bool valid_p = (STRINGP (value)
|| ((it ? FRAME_WINDOW_P (it->f) : frame_window_p) && valid_image_p (value))
|| (CONSP (value) && EQ (XCAR (value), Qspace))
|| ((it ? FRAME_WINDOW_P (it->f) : frame_window_p)
&& valid_xwidget_spec_p (value)));
if (valid_p && display_replaced == 0)
{
// ...
/* Save current settings of IT so that we can restore them
when we are finished with the glyph property value. */
// ...
if (STRINGP (value))
// ...
else if (CONSP (value) && EQ (XCAR (value), Qspace))
// ...
else if (valid_xwidget_spec_p (value))
// ...
else // This is the (image ...) case
{
specpdl_ref count = SPECPDL_INDEX ();
// ========== This code just sets it->image_id ==========
it->what = IT_IMAGE;
specbind (Qinhibit_quit, Qt);
it->image_id = lookup_image (it->f, value, it->face_id);
unbind_to (count, Qnil);
it->position = start_pos;
it->object = NILP (object) ? it->w->contents : object;
it->method = GET_FROM_IMAGE;
*position = start_pos;
}
return retval;
}
/* Invalid property or property not supported. Restore
POSITION to what it was before. */
*position = start_pos;
return 0;
}
static void
produce_image_glyph (struct it *it)
{
struct image *img;
struct face *face;
int glyph_ascent, crop;
struct glyph_slice slice;
// ...
// ========== This recovers image from it->image_id that we set earlier ===========
img = IMAGE_FROM_ID (it->f, it->image_id);
// ...
slice.x = slice.y = 0;
slice.width = img->width;
if (FIXNUMP (it->slice.x))
slice.x = XFIXNUM (it->slice.x);
else if (FLOATP (it->slice.x))
slice.x = XFLOAT_DATA (it->slice.x) * img->width;
// ...
if (FIXNUMP (it->slice.width))
slice.width = XFIXNUM (it->slice.width);
else if (FLOATP (it->slice.width))
slice.width = XFLOAT_DATA (it->slice.width) * img->width;
// ========== At this point slice.x is the slice property's X value, =========
// ========== if it exists, or 0, which is the left edge of the image. =========
// ...
if (slice.x >= img->width)
slice.x = img->width; // <----------------------------------------------+
// ... |
if (slice.x + slice.width >= img->width) // |
slice.width = img->width - slice.x; // |
// ... |
// |
// ========== If slice.x >= img->width, we would return here, so ======|=======
// ========== slice.x <= img->width and we can forget about setting ======|=======
// ========== it here: ---------------------------------------------------+=======
if (slice.width == 0 || slice.height == 0)
return;
// ========== Therefore slice.x is still the slice property's X value if ========
// ========== it exists and 0 otherwise. ========
// ========== Instead, slice.width is now trimmed if it would overflow. ========
// ========== If we have no slice property, at this point slice.width is ========
// ========== be img->width. ========
// ...
// ========== it->pixel_width = slice.width (if no slice property, img->width) =======
it->pixel_width = slice.width;
// ========== If we go to the left edge add img->hmargin to it->pixel_width ========
if (slice.x == 0)
it->pixel_width += img->hmargin;
// ========== If we go to the right edge add img->hmargin to it->pixel_width ========
if (slice.x + slice.width == img->width)
it->pixel_width += img->hmargin;
// When there's a slice property:
// - If the slice is (only) the rightmost one:
// => it->pixel_width = img->width - it->slice.width + img->hmargin
// - If the slice is (only) the leftmost one:
// => it->pixel_width = it->slice.width + img->hmargin
// - If the slice covers the entire width of the image:
// => it->pixel_width = img->width + 2 * img->hmargin <--+
// When there's no slice property: | This is what Fimage_size returns
// => it->pixel_width = img->width + 2 * img->hmargin <--+
// ...
if (face->box != FACE_NO_BOX)
{
// ...
if (face->box_vertical_line_width > 0)
{
if (it->start_of_box_run_p && slice.x == 0)
it->pixel_width += face->box_vertical_line_width;
if (it->end_of_box_run_p && slice.x + slice.width == img->width)
it->pixel_width += face->box_vertical_line_width;
}
}
// ...
// The code below is irrelevant for our purposes, since we're trying
// to calculate the width _before_ we wrap. I'll leave the comment
// from xdisp.c as well:
/* Automatically crop wide image glyphs at right edge so we can draw
the cursor on same display row. But don't do that under
word-wrap, unless the image starts at column zero, because
wrapping correctly needs the real pixel width of the image. */
if ((it->line_wrap != WORD_WRAP
|| it->hpos == 0
/* Always crop images larger than the window-width, minus 1 space. */
|| it->pixel_width > it->last_visible_x - FRAME_COLUMN_WIDTH (it->f))
&& (crop = it->pixel_width - (it->last_visible_x - it->current_x),
crop > 0)
&& (it->hpos == 0 || it->pixel_width > it->last_visible_x / 4))
{
it->pixel_width -= crop;
slice.width -= crop;
}
// Finally there's some glyph code, which I don't know what to do
// with.
// ...
}
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename="scan_for_column alternative.c"
Content-Description: scan_for_column implementation
static void
scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol,
ptrdiff_t *prevpos, ptrdiff_t *prevbpos, ptrdiff_t *prevcol)
{
struct it *it;
ptrdiff_t prev_pos, prev_bpos, prev_col, charpos, bytepos, to_x;
struct window *w;
eassert (WINDOWP (selected_window));
w = XWINDOW (selected_window);
charpos = find_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, NULL, &bytepos, 1);
init_iterator (it, w, charpos, bytepos, NULL, DEFAULT_FACE_ID);
it->line_wrap = WORD_WRAP;
to_x = goalcol ? *goalcol * WINDOW_FRAME_COLUMN_WIDTH (w) : MOST_POSITIVE_FIXNUM;
move_it_in_display_line (it, -1, to_x, MOVE_TO_X);
*endpos = IT_CHARPOS (*it);
*goalcol = it->current_x / WINDOW_FRAME_COLUMN_WIDTH (w);
}
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 9 Feb 2025 07:08:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 09 02:08:48 2025 Received: from localhost ([127.0.0.1]:42770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1th1Qt-00069i-HB for submit <at> debbugs.gnu.org; Sun, 09 Feb 2025 02:08:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45914) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1th1Qr-00069S-8q for 76107 <at> debbugs.gnu.org; Sun, 09 Feb 2025 02:08:46 -0500 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 <eliz@HIDDEN>) id 1th1Ql-0002JM-VJ; Sun, 09 Feb 2025 02:08:39 -0500 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=oG8sCs74rk2AY4iVG/RYjYntF3tQqPbRZDrDMDPLBH8=; b=HanIQG11HCzn I2S6R30xfpdF2P0iAoCRzVTDHed1gAukFiguQO34SzjJKrKAPWNr/0gcbiLlb+fDPy36/U9w8gVtX 9R+47mBcuHxwdz1QJNgj88RgFTnQXBcXZoRYPzePy84OFnGnzy5rY4eHQ7EAEGrUXIxmDfTEc0Y8N 2wlNOyRXiMqLYiSYJFCkECy4syMC9FfY5BWjdJPmBFIvVK5X+hq6wPsoaNL/41xryTYfJShA0cTpA /YJNtLuWTR5OTEhE3x2Svz2NKoEMKPyUpLM4TvhC1JYyDRuyW4SQcSj0zug7O8H5E1bVLinKHb1px veNoyNt/6fKHyDI70MVdkA==; Date: Sun, 09 Feb 2025 09:08:37 +0200 Message-Id: <86cyfr1toq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87frkogjz5.fsf@HIDDEN> (message from Thuna on Sat, 08 Feb 2025 23:17:02 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> <87frkogjz5.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Sat, 08 Feb 2025 23:17:02 +0100 > > > I understand the reason now, but my opinion is still the same: proper > > support for columns requires simulating the display, > > I would _really_ appreciate it if you would point me to the problem > point where calculating the image sizes (not the visible section - the > _whole_ thing) becomes infeasible without access to the full display (or > a simulation thereof). Look at the way images are processed in xdisp.c (starting at handle_single_display_spec and then in produce_image_glyph and its subroutines). It isn't a single place, and the processing is complex. Because of this complex processing spread over several functions, I have hard time believing that just calling image-size will produce a reliable result, and I don't see how will you prove it does produce a reliable result without a lot of testing, unless you use the same code as the display engine does. Which is why I suggested to use other functions, which do use the display code for this purpose. > > and the two functions I mentioned already do that. > > I am not very familiar with events, but I don't see any way to do what > `move-to-column' does using any of the things you mentioned. The call (vertical-motion '(COLUMN . 0)) will move point to the specified COLUMN in the current screen line. If you don't have to handle continuation lines, this is all you need; otherwise, you need some more code using display--line-is-continued-p, because vertical-motion moves only within the current screen line, and will stop at line continuation. Similarly, the call (car (posn-col-row (posn-at-point POS))) will return the visual column of the buffer position POS. (If this is on a continuation line, you need to add the columns of the previous continued lines.) Both of these functions use display code to calculate the column, so they take images into account. I'm sorry, but please look at this from my POV: I don't want us to be left with a semi-working implementation that we will need to keep fixing and maintaining for the years to come. Adding support for images to move-to-column means we promise it to work correctly and will be expected to fix any inaccuracy people report. Using the display code frees us from this problem, because that's what Emacs uses to display the images in the first place, so it will always be as correct as what we show on display. So from my POV, either using posn-col-row and vertical-motion in a specialized fill-paragraph-function, or using move_it_* functions in check_display_width for measuring the column size of an image, are the ways of making this improvement that I very much prefer. The latter is I think a simpler and better solution, because it doesn't have the complications with continuation lines. I don't understand why you insist so much on going with Fimage_width and not with the method I proposed, I don't think the code will be much more complex. > > So if we want fill-paragraph to work in the presence of images and > > other display features, we need to have a specialized > > fill-paragraph-function which uses posn-col-row instead of > > current-column and vertical-motion instead of move-to-column. > > If we can have a version of fill-paragraph which can calculate image > widths, then that should just be _the_ fill-paragraph function. Images are not the only display complication that current-column and move-to-column doesn't handle. For example, they don't support xwidgets, and also produce incorrect results when there are display strings with embedded newlines. Because of that, fill-paragraph doesn't work properly in the presence of these display features. Therefore, adding images to it will still not make it work correctly in all the cases. > > I don't see a good reason for adding semi-working image support to > > current-column and move-to-column. > > Yes, I also don't want to have a semi-working result, but what part is > not working, other than `slice' support? > > As far as I can see, in xdisp.c, `calc_pixel_width_or_height' is what > determines the display width of the image, which returns the basically > same thing Fimage_width does. If there is some other step that I'm > missing, could you _please_ tell me where or what it is? See the two functions mentioned above, handle_single_display_spec and produce_image_glyph. If you use the move_it_* functions, they call these automatically.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 8 Feb 2025 22:17:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 08 17:17:15 2025 Received: from localhost ([127.0.0.1]:41793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgt8V-0008Dg-5C for submit <at> debbugs.gnu.org; Sat, 08 Feb 2025 17:17:15 -0500 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]:42455) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tgt8S-0008DO-2h for 76107 <at> debbugs.gnu.org; Sat, 08 Feb 2025 17:17:12 -0500 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-ab744d5e567so608213166b.1 for <76107 <at> debbugs.gnu.org>; Sat, 08 Feb 2025 14:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739053026; x=1739657826; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=vno4NaKF4P8uzpr/LImw2RPPU5WFp9GdnP5D2WZbDU8=; b=ayMQQ25UbgxfU1GBKfoZy70DrQjU8ObgLy8xSmFJbtLBGe9pYS2KfoP5PohazYOJZK faUZapxMJ9I5VACFtqEV/tS2WpMI9MpxPpggD8Mz8zgB0h33E5jLUKEm7HodDfQnmMNJ 9nNrP/1g0slT4mydXpeqDrzlsFc1xb/nRL/ZPRP4Htv9A1C2nfuG0otSRbRE/jZ2gj8b /4NHI4KAumnJSta6MEa9nSxREgPZxk6vYZHPJnVcV4NPA0OiVzOIfGOuYpZhNRLiJF/u 5Wgs0HWd17123828xSVzFn/CtdaSmk+a3c440o2M8jmb7z3cu8UJrVh/EAIeN+ngJSOk 3lyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739053026; x=1739657826; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vno4NaKF4P8uzpr/LImw2RPPU5WFp9GdnP5D2WZbDU8=; b=jWqVeMfAyWW+QONULZpIzFbI24bwedJtuq4LFcDvyI9akyqOLJ6hr2lOAov90wke/H aAAoixhuLrRZz9hb2fufCo150xr0WRUK05CDOtAwvRjfXAdGr/Q4cWXgll0GEA9KK6M4 5/6vuncme/t2gHRGVQnmJLalrOgJX8iku3a/6iw3r7mkyURbQw8o5oLxEE0xVBFIBldZ /I+Tk5dR0fOTNhvTL88elCkLLGEX+uko617gmMH7oqovWk+qeuKEHN48zzTenzfXX7AC 6eAH1ZBGiBXC8DWmnYr913XU6ogiiShiuLybgvVKDPY1UXe6Fa7yOorOs7QjMytilQRh NUww== X-Gm-Message-State: AOJu0YznEdNRqKjiY58hwMda/PNjINm+j+m4CwDmU2k0KPxOGQVVTpfX zw13gG/xxS17j8BY3pTfnco8/grdfL9e3gae+TaC46FppAiFOMFnNX+gI/1zIq/HmA== X-Gm-Gg: ASbGncs3FRjwtV+S3Q1eCHizCK8wFuP8YlgwLUdPsjw8VIhA+Y2Wlb9qtvJIvbPqZJ6 /lPchJ5+2HFGwN8ZRpaQqFAgOl5KZu4VMAxGBkTv6GKu+oqT3lt5isMwkJKt9Q+oyfMFARjajZP B8/PJvDL9gtkSd/9QbLk7wm2gLNSi5mkZcKqIlWxVarfQ7apSXjhF8j2OvvfXhpG1JMAEEsyRm6 skmn7rAQs04dlhjMUoPr1deThlhwSDMT+tf76R80Axrgo+gHfOXHvRcUihrZQAqs+riKh5k05QK JUUnNSgXRZAXfjil X-Google-Smtp-Source: AGHT+IHJUeKUjl2yla3Er2ONyBE/84dJW2sAcFc5TKihqdGekhCCwC1l5Myl8wOJTUPcIjh5AzP2RA== X-Received: by 2002:a17:907:7d91:b0:aa6:489e:5848 with SMTP id a640c23a62f3a-ab789c84fdbmr819621066b.25.1739053023790; Sat, 08 Feb 2025 14:17:03 -0800 (PST) Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab7736464c8sm551256966b.166.2025.02.08.14.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Feb 2025 14:17:03 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86msew1bid.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> <86msew1bid.fsf@HIDDEN> Date: Sat, 08 Feb 2025 23:17:02 +0100 Message-ID: <87frkogjz5.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > I understand the reason now, but my opinion is still the same: proper > support for columns requires simulating the display, I would _really_ appreciate it if you would point me to the problem point where calculating the image sizes (not the visible section - the _whole_ thing) becomes infeasible without access to the full display (or a simulation thereof). > and the two functions I mentioned already do that. I am not very familiar with events, but I don't see any way to do what `move-to-column' does using any of the things you mentioned. > So if we want fill-paragraph to work in the presence of images and > other display features, we need to have a specialized > fill-paragraph-function which uses posn-col-row instead of > current-column and vertical-motion instead of move-to-column. If we can have a version of fill-paragraph which can calculate image widths, then that should just be _the_ fill-paragraph function. > I don't see a good reason for adding semi-working image support to > current-column and move-to-column. Yes, I also don't want to have a semi-working result, but what part is not working, other than `slice' support? As far as I can see, in xdisp.c, `calc_pixel_width_or_height' is what determines the display width of the image, which returns the basically same thing Fimage_width does. If there is some other step that I'm missing, could you _please_ tell me where or what it is?
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 8 Feb 2025 19:29:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 08 14:29:07 2025 Received: from localhost ([127.0.0.1]:41564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgqVn-0005hY-Gg for submit <at> debbugs.gnu.org; Sat, 08 Feb 2025 14:29:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45928) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tgqVk-0005gy-KS for 76107 <at> debbugs.gnu.org; Sat, 08 Feb 2025 14:29:05 -0500 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 <eliz@HIDDEN>) id 1tgqVf-0003LI-8o; Sat, 08 Feb 2025 14:28:59 -0500 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=UX7w0WS1YSrxH4yssLle09ZUpTW+CIN0tb7xvteqMgY=; b=PoryQtX4RUAp dxkv0Cq3oE9Q9x2CbIJZRwqH+VGPbqp7JOVtfdRPiPvdAE0hOI7kfrv+cLqNV92z5tf9LzmYLXpqV o4zUJWLBTihwkE2n6RmtaTVhGTCmwfJ0PC5WCHpIJrWQSUER6LDJ2QF/EyR7/m971C3PNiP7asHDr lQncR5sN3rh7uc9EVN5RrCOQqQL0UxHvBz/NbuJ+11Nw7SZLXVXMFbLifQ1Fr/YTVIKytE6kL7oGg qh49jXA9v0sDzMljYlnAK6TxHSp9vmnqM3Fi0pXJ22psYQ/ESYkV6x7WOVY2oJb+/Mt6/I3BS8UT9 XE5SNIRJaKOmbAZgebWHFg==; Date: Sat, 08 Feb 2025 21:28:58 +0200 Message-Id: <86msew1bid.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87jza0gt8y.fsf@HIDDEN> (message from Thuna on Sat, 08 Feb 2025 19:56:45 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> <87jza0gt8y.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Sat, 08 Feb 2025 19:56:45 +0100 > > > Maybe you are right. But anyway, this is not the main point I was > > trying to make. The main point is that using image-size is not > > accurately reproduce the actual horizontal coordinate on the screen. > > > > Can you tell why you need image support in current-column and friends? > > E.g., why posn-col-row and vertical-motion cannot do what you need? > > I'm trying to get fill-paragraph (and visual-fill-column-mode) to work > properly in Org buffers with lots of previewed inline latex fragments. > fill-paragraph internally uses move-to-column, so that's what I'm > patching. This isn't limited to Org, though. Better image handling (or > at all) by default is a good thing to have in general. I understand the reason now, but my opinion is still the same: proper support for columns requires simulating the display, and the two functions I mentioned already do that. So if we want fill-paragraph to work in the presence of images and other display features, we need to have a specialized fill-paragraph-function which uses posn-col-row instead of current-column and vertical-motion instead of move-to-column. I don't see a good reason for adding semi-working image support to current-column and move-to-column.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 8 Feb 2025 18:56:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 08 13:56:57 2025 Received: from localhost ([127.0.0.1]:41482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgq0f-0004D2-5g for submit <at> debbugs.gnu.org; Sat, 08 Feb 2025 13:56:57 -0500 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:49156) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tgq0b-0004Cj-Vn for 76107 <at> debbugs.gnu.org; Sat, 08 Feb 2025 13:56:55 -0500 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5dcef33eeceso5799539a12.2 for <76107 <at> debbugs.gnu.org>; Sat, 08 Feb 2025 10:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739041007; x=1739645807; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=aJYFB1glgxqzcvG+7hx38DHAAGADFoCSY+ZLGSwUVo4=; b=LLregt238HLveEZQ+gz2g2GrKdc2EDAIT0BGBBsIAjawwWHGWzN9zi5krhCjr6Qvje JPzfqr7gQPpaZre4yUJ3UVKMrIJtgDr+YdDcibRrbNCtZcyKl0obcreTUoGEnwCKKrmC YeRGDheIjzdSOlotIOUeEQ478U3RkfJyZGFvKHtfQCgTGunmCTKREn2t1wNCXEtDqRGv sveRgo4QMtpBAMcszJe9eMVSU7hyO2dlG+RZJDC9oJWt1nit5HdAVyVmvRaELVBLzNDk XjkIC2rNe0eYXMlxBm7WvDJ5MxHj6gZ1dKUgr8nphxqAYmq0jSNf6cEHMchJoclUpuje dHlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739041007; x=1739645807; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aJYFB1glgxqzcvG+7hx38DHAAGADFoCSY+ZLGSwUVo4=; b=cy2I7Q1CI7TfFPBCSV8i5sgnk0Mg048YVU2WZ8tYQYwbXdCnKIgMrOYjcM4UZS2rNV SzVA0qB2iq1KKKG5bWbUk22GRJ84Q6BZChAqRhr+1PJ4W6UHctXwFcMOoJQYdZ8QXYUb vYkyXQHZmHb9IiEPVpPOABKuLK0UN1OHsgPT2gPrTod4Ix6w0it8FUioSi2HY/VisumG 9oNbhSUE648zz8Ty/pUz0C/sG/MTE5feAbhGzPW3/8OD2tTszVuPrL9bNFgq3OKMRheA Ivefh4lF0FiK1pV/HQKJPjihZ0pfLgM3g4tLUwv+qllwYcprdbIQFxRBkt1YAv+sFBF7 6ABw== X-Gm-Message-State: AOJu0YzEFk5vqRTdANtpJLlfzivDAoYe1UdOVm2zks9q+8oDjAf3kahu OO8SgS0vGpUoZRGu8OD4t8NJA1jQDPvAnfbTpFBGjyj2aPCPNptxA6x39H2yjw+TMQ== X-Gm-Gg: ASbGncsvwLAQjP3cFf8oju+48jfzDeVkCPEN8dgQ6Q+Sj/UrxSRyaLq8GKdYbPCpoCi rtrKaecMzTmFlYGxl5vsYxSLhnRZVtBQaAXBM2b3mZIYoEp0klO/jc+zqMf2CB87So4qRBAwM5K VFLQq7BA2RCi+oeyQ9WgW14jxpLcQpw1QRXJDn2H/gGosUUOebGRJejMHUkIzX84A0IujDo+C6D BAIhr3HvTlY0srvyCxlzca0OvYwx97OOVQJnM1SuAOWcsoEM+TDuoXURnj4WzIA5hewzxtQCqw4 rU5yVFvU4JD2jx9P X-Google-Smtp-Source: AGHT+IEZeOhg02VYqyHtknPADYnVvozMF1Fp9+Xqv38Nly6zH3uaQyk2ote5x+pHqCgXvLOsKowwlQ== X-Received: by 2002:a05:6402:400e:b0:5dc:51bd:4419 with SMTP id 4fb4d7f45d1cf-5de45070648mr9137829a12.16.1739041007155; Sat, 08 Feb 2025 10:56:47 -0800 (PST) Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5de3d310fe1sm3937532a12.67.2025.02.08.10.56.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Feb 2025 10:56:45 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86o6zd4jhv.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> <86o6zd4jhv.fsf@HIDDEN> Date: Sat, 08 Feb 2025 19:56:45 +0100 Message-ID: <87jza0gt8y.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Maybe you are right. But anyway, this is not the main point I was > trying to make. The main point is that using image-size is not > accurately reproduce the actual horizontal coordinate on the screen. > > Can you tell why you need image support in current-column and friends? > E.g., why posn-col-row and vertical-motion cannot do what you need? I'm trying to get fill-paragraph (and visual-fill-column-mode) to work properly in Org buffers with lots of previewed inline latex fragments. fill-paragraph internally uses move-to-column, so that's what I'm patching. This isn't limited to Org, though. Better image handling (or at all) by default is a good thing to have in general.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 7 Feb 2025 19:56:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 07 14:56:08 2025 Received: from localhost ([127.0.0.1]:36674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgUSO-0001pu-H8 for submit <at> debbugs.gnu.org; Fri, 07 Feb 2025 14:56:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33532) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tgUSL-0001ov-FA for 76107 <at> debbugs.gnu.org; Fri, 07 Feb 2025 14:56:06 -0500 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 <eliz@HIDDEN>) id 1tgUSG-0000ht-3I; Fri, 07 Feb 2025 14:56:00 -0500 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=628A1A/MGWoiEcn0oRNs0J/b1Rvx5yhqk1tLFx/nZvI=; b=UOrz/0ITcbEq rG1/kUIJthbpXEvuVS4ykBpbLqcZzlVzXxYpghhnWBekQwdUdKed9rKYFg8tE29Yi+mRX6vyCdXhh o1FOOZsCq8h5ALwKl0ro9hh1oOHNE2qMoy12tZtOTQQ1Gi2YHaCv7lp0S22iw0C8D6KmrGRpGPrBN BK/e2CPClljO6h8WT65KvwD0udkr1bhOx6yWDmxVL5Zr8AFg3eBg3mrSzyaBfKf2mdpWRr9YGuOZF R7qMZ+AbTKbvKEx9/I8qf3fqi6rbAjB9cSewk4zZB6Qnhr0gGvM8GPFMwQUFKKjcm0o5KUGQZ4T0c aeSqr7PKZiFtpLX8fxdd/w==; Date: Fri, 07 Feb 2025 21:55:56 +0200 Message-Id: <86o6zd4jhv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87pljthd1f.fsf@HIDDEN> (message from Thuna on Fri, 07 Feb 2025 18:37:00 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> <87pljthd1f.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Fri, 07 Feb 2025 18:37:00 +0100 > > > But everything is _not_ visible. For example, if the image is at the > > left edge of the window and the window is hscrolled, part of the image > > will be invisible, and the columns of characters after it will be > > incorrect. > > Maybe I have this all wrong, but shouldn't we be scanning from the very > beginning of the line, and not just the _visible_ beginning? > > When we have a row with the contents > > "some long text with a lot of characters that we need to scroll to see properly" > > and we have it hscrolled until the visible row starts at "characters", > current-column at the start of "characters" is still 29 and not 0. > > Similarly, I would think that given > > "#<image :width 10em>foo bar" > > with the buffer hscrolled until it only shows "foo bar", we would want > current-column at the start of "foo" to be 10 and not 0, even though the > display width of the image is 0 (since it's not visible), because the > "actual" width of the image (that is, what its width _would_ be if we > could see it all) is 10. Maybe you are right. But anyway, this is not the main point I was trying to make. The main point is that using image-size is not accurately reproduce the actual horizontal coordinate on the screen. Can you tell why you need image support in current-column and friends? E.g., why posn-col-row and vertical-motion cannot do what you need?
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 7 Feb 2025 17:37:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 07 12:37:12 2025 Received: from localhost ([127.0.0.1]:36331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgSHw-0003YU-1z for submit <at> debbugs.gnu.org; Fri, 07 Feb 2025 12:37:12 -0500 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:46451) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tgSHs-0003Y8-NA for 76107 <at> debbugs.gnu.org; Fri, 07 Feb 2025 12:37:10 -0500 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ab78d9c5542so159001166b.1 for <76107 <at> debbugs.gnu.org>; Fri, 07 Feb 2025 09:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738949822; x=1739554622; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=90bvNekmcoAPdR6ZJxmNlkpOgkCUlewdNq2LZlmYcxk=; b=Z7FpQgVDvE9D5k6IL+hTOlltNsJ+IjI1Pbi8Fb7x6su9J7Z9q+eX5K1du400LZUWTx oBcZMeMy36heVxsBpq2TyqkXH+5YB7Wmg6TeK/m3nY0P3yzQ9afqSaSEafDdDg1xy0GT xk00eqcldTDYIJfaPK0NjUg+fZgbwUezmr+RWxJ87gRD9X6OTMYHeYCkZTCbrlgr90LW 6wM0A88SnvL6t+rTsnSUT2SBVA89ck4Z+Zjei0DgyMdE5tYBdXWnj2hs5bGcZQ8MFz97 ajdxxV3ZQhrp1sLaz5+N+vdplfojzLefL+iKhklA70btOjqNRVfN7NGc+qzjHHSAbhLi L0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738949822; x=1739554622; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=90bvNekmcoAPdR6ZJxmNlkpOgkCUlewdNq2LZlmYcxk=; b=dlquswix1PrkMSwM4A3AIgMgM4Ic3Noh0TF49R0F277djfnNXl4u0LM7F4G0dqdY/U jZrvwJrEI5CN8VJ/jF1Mi+VN363ZZbRfxEdx3h7QrkG0ZY9m2icQPlGBU0n2kZEY7sUJ vwy3zzr9yvIgPAUb9RfUgxkrg7S2hO3F7znHhbJqYMM1R2LqKJDaxPS9hHFIHJq5X74w BikfxVEmqlVSkXrSS4rdkwuABEqBjXM4sKJpj7YdNwcpv+mEe1JfhI12ULuv3p7vU2Ww Bx3oeVxtgorF/1pLoO9P/RkMJjojQmSok9wc3MaJI5VSpmekBYo62mtmbQHqFci6+zec DQdg== X-Gm-Message-State: AOJu0YygiMBR6Xsuzy9Btl8lUBRnrhxoXGa9sBqDkVTZtxN84wPHHZtk xyge13MuZHzHUmN0JC8r4GEA40EvvdEl4FCo26BldNl9G0+7xPsGxuk0bfdGTSg= X-Gm-Gg: ASbGnctbubw34TnaNAox1iidqrkWESpxlfEra1rxtbzCaZD9Bee0swaeYQqP6qHwQCL mPzIQPOymUzceyFTRgpNangoH7MqyR2Pm2qxii3j9RF6YOHHBX4QkdK6RKRS0aykri5Y54NVcgW IdGZJwMZrOMoNuoFU2FifDGKT5WxYfgYxvyaGmq4Kp9DI8JmiLyuR8ACoCfjHspM0X4BkZH7nzx HB7HczPRTysVr5GpgzSCITvDv98wrDe6O1CwRCOJh3gunQ01XqaZI9KbRXTGJbMXLGZ4xMRqiW/ B54IS94qig4flwDL X-Google-Smtp-Source: AGHT+IHms8v9GKGnEmCweq3xgqaqldkkGqzbrkH/7H91LWgVovOqWRY582tOvP8uJRSK9KMi1luoyA== X-Received: by 2002:a17:907:1c29:b0:aae:83c6:c67e with SMTP id a640c23a62f3a-ab789c2d784mr444486866b.55.1738949821880; Fri, 07 Feb 2025 09:37:01 -0800 (PST) Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab791c89296sm88636366b.106.2025.02.07.09.37.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 09:37:01 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86seop4r13.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> <86seop4r13.fsf@HIDDEN> Date: Fri, 07 Feb 2025 18:37:00 +0100 Message-ID: <87pljthd1f.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > But everything is _not_ visible. For example, if the image is at the > left edge of the window and the window is hscrolled, part of the image > will be invisible, and the columns of characters after it will be > incorrect. Maybe I have this all wrong, but shouldn't we be scanning from the very beginning of the line, and not just the _visible_ beginning? When we have a row with the contents "some long text with a lot of characters that we need to scroll to see properly" and we have it hscrolled until the visible row starts at "characters", current-column at the start of "characters" is still 29 and not 0. Similarly, I would think that given "#<image :width 10em>foo bar" with the buffer hscrolled until it only shows "foo bar", we would want current-column at the start of "foo" to be 10 and not 0, even though the display width of the image is 0 (since it's not visible), because the "actual" width of the image (that is, what its width _would_ be if we could see it all) is 10.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 7 Feb 2025 17:13:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 07 12:13:31 2025 Received: from localhost ([127.0.0.1]:36248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgRv0-0002JK-Ib for submit <at> debbugs.gnu.org; Fri, 07 Feb 2025 12:13:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43998) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tgRuy-0002J4-Dv for 76107 <at> debbugs.gnu.org; Fri, 07 Feb 2025 12:13:29 -0500 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 <eliz@HIDDEN>) id 1tgRus-0004Qn-Td; Fri, 07 Feb 2025 12:13:22 -0500 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=sFCt+a7UFGJnQo16lZwKHTu+DrNdT0FHo94OXgvJjGM=; b=ee5EeRas0pxf ALA1XUm/f4igtXIH6OCBT77rPP/a9tBgagYr5qAwHt5bS0/nLPP8bTvB05JhVYWyuiRFcCxrh26TP Qbsr4cwwK/9aMlGzbza3RzGfHamGorEbAHIlGXiACiRPhz4EWPVZjBRHYGPzK0KDfPD9axHAKlsYR 4K27SmjUnqzylujiWOOa6lmRB10j14lEpOh2yWVSH6w0yhYznqcbqX7vqCsGnOnttMSydVl7QB5iK PssCjJ8OfKtxbDRfCL+ee34qeO8zwodfOnvczFgBXFSTSK/VaEZ56uoaK2HFXIorIvih/ZYsjUeZ6 EemWoI+KJ/C2Ld4oepMlYw==; Date: Fri, 07 Feb 2025 19:13:12 +0200 Message-Id: <86seop4r13.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87v7tlhg8e.fsf@HIDDEN> (message from Thuna on Fri, 07 Feb 2025 17:28:01 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> <87v7tlhg8e.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Cc: 76107 <at> debbugs.gnu.org > Date: Fri, 07 Feb 2025 17:28:01 +0100 > > > Thanks, but I don't see how this could work with just this code. The > > display property that uses images could be much more complex than just > > giving the image file name or data. First, there's the 'slice' > > display spec, which shows a slice of an image. More importantly, the > > IMAGE-SPEC part of the display property could include properties that > > affect the size of the image on display, and Fimage_size doesn't > > necessarily take them into consideration, AFAIR. Which image > > properties that can appear in an image spec did you try with this > > patch? And finally, images are clipped on display when they exceed > > the length of a screen line, which Fimage_size doesn't take into > > consideration, because it doesn't know at which horizontal coordinate > > the image will be shown. > > > > So I'm afraid fixing check_display_width to support images will need > > to simulate the display, i.e. use the move_it_* functions defined in > > xdisp.c; just taking the image's size is not enough. Or maybe you > > could use Fbuffer_text_pixel_size (which needs a window to do its > > calculations, which is another complication of supporting images in > > this case). > > Mm, that's pretty bad. I was mostly hoping that Fimage_size would do > all the heavylifting for me. > > So, let me see if I have the components effecting the display size of an > image right: > > 1. The image spec properties need to be calculated properly. It seems > to me - from looking at the code and checking the image-size of a > newly created image with various properties specified - that > Fimage_size does all the calculations given the specs properly. So, > unless something in xdisp.c effects the display width of an image > (note that I don't mean _visible_; we're (I am) assuming we can see > everything here), it _should_ be correct to just rely on Fimage_size > for this bit. > > 2. Slice display spec needs to be handled. I'll add support for this in > a bit. > > 3. Off-screen clipping is unlikely to be useful, and in fact it is > better if we calculate the width without considering it, since when > moving across columns we (at least I) behave as though everything was > visible. But everything is _not_ visible. For example, if the image is at the left edge of the window and the window is hscrolled, part of the image will be invisible, and the columns of characters after it will be incorrect. > Is that correct? Is there anything I'm missing here? If not, I can go > ahead and try tackle the slice specs. No, you've misunderstood me. The _only_ reliable way of knowing what will be the width of an image on display is to simulate display. We could do what you have in mind, but then we'd need to document that the result might not be accurate in the presence of images, and I'm not sure this would be useful enough. If image-size is enough, then Lisp programs that want to calculate columns in the presence of images could simply add the value it returns. The result will be the same, and as (in)accurate as what your code produces.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 7 Feb 2025 16:28:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 07 11:28:12 2025 Received: from localhost ([127.0.0.1]:36163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgRDA-0000BF-27 for submit <at> debbugs.gnu.org; Fri, 07 Feb 2025 11:28:12 -0500 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:57517) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>) id 1tgRD8-0000B1-7z for 76107 <at> debbugs.gnu.org; Fri, 07 Feb 2025 11:28:11 -0500 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5de594e2555so30691a12.2 for <76107 <at> debbugs.gnu.org>; Fri, 07 Feb 2025 08:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738945684; x=1739550484; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=p9KR5Dk8+kTYf+WBLRMhaeAcl77Xf62UT7Q1NPp3Bqw=; b=BLn6/Ez3+XG+rIgrqHOg+ORCfIbifRhNEF7p1FYK6sZ9XlZIlL2vWchy+WYIFDHUyO m2oCTn5KJIyBnYTI3S6qI40/kUa7XXE41g8WwMTG90FsvNGsP2y4W+khITMvrbrbhSAM 23ckkj4d4uA1p9CYrS1stCWboV6tx4J23ObmsHBH3Ua275ds6A6p6A8omZn3GK/cZgZd 2gN0sQh9zoxSRrT6vqk7k0AODiPUw8bwxQA3uSIta0ZGJ1m++WXS9jV7KF/XEkkfYB7U nwa0gnUlqy1U+CAv8y60iTRSEBJ8B+ouoA2AUBox//zPwIvdhY8VLF7vrn3K7m42en/v m/0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738945684; x=1739550484; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=p9KR5Dk8+kTYf+WBLRMhaeAcl77Xf62UT7Q1NPp3Bqw=; b=eNXjcexIQZW+pxNE68Oqk65pmv+RKpvtHWB1MWqc/6KkKeJc/Kg+4vrAs6NfklvA9h qP+hOSYdcguSAWBH6yF8nSl6y5GK9LEgteoF6fjbjbB8JW9vglhkCEKu5WL1tE9I8KLO zB3LQcCx+kLjCQAeDi5YSSpgXxb8hSLCWfdjChGrTv6nAf/YrS4M6lxFG8wvxUI+g3/i x3sfB43jiIZ37nyv8/r+psxJYaD81YuWv/m5qdzrlrr+/6LEahcuvgZG8YnIJauKU9SG lMM8wcr52w0DGjQVJLvPYRQ/2PUnd8Cd8+l2xNcCqGMXdOQ3CFjMbyMWzYV1VPy7yvN+ lpoQ== X-Gm-Message-State: AOJu0Yz+/jmEwTQ6xPqi0ztZUTMHPF+hhvK97JXbtRzCvAb1tHB/K0nF 5b3fCKZXdu2mG8v8t49d2AZ2VkCpormgv8LZ+iRHjnNXiBl1u6/k5dT6cmJK8no= X-Gm-Gg: ASbGnctfDdfNxemjX7QYwpgI/TdchssS7aCiwiH2SgKHyrC/nVEjZLC6ML1okQjUCjI YWcUbcfGvu85OFj0q4UAQ6z5MbdUBUFay7zs+9tVJctd010w+43xOx7pj+c7+EcN+FgdwZGogI7 T0ZGKxq95B73P4CzYKvKBYtYeRipDJzpTlFkwD5GAyl1bElr03zwtGYEnVZbhiybeFfC4cXH5Vk mtkUBVQeQtM7wxFVllbevkKuogKHi/xXB6jiCU9du0Qkab3XlnL2hh20p2z0/STg8MbVInBH4il 7x3C9Vrd3auxOK7V X-Google-Smtp-Source: AGHT+IENXFRSfj/74GZfaO0VMnFFdqOnlMh+oFIpOtqtYb5hPdzvUwY1nJNzVu+s1q+u7hS4g6RAJw== X-Received: by 2002:a05:6402:3883:b0:5dc:752f:fa9f with SMTP id 4fb4d7f45d1cf-5de45097e0bmr4189589a12.28.1738945683419; Fri, 07 Feb 2025 08:28:03 -0800 (PST) Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5dcf1b80fb0sm2781188a12.39.2025.02.07.08.28.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 08:28:02 -0800 (PST) From: Thuna <thuna.cing@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76107: Consider image specs when scanning for a column In-Reply-To: <86ikpm5g56.fsf@HIDDEN> References: <87a5ayirdp.fsf@HIDDEN> <86ikpm5g56.fsf@HIDDEN> Date: Fri, 07 Feb 2025 17:28:01 +0100 Message-ID: <87v7tlhg8e.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Thanks, but I don't see how this could work with just this code. The > display property that uses images could be much more complex than just > giving the image file name or data. First, there's the 'slice' > display spec, which shows a slice of an image. More importantly, the > IMAGE-SPEC part of the display property could include properties that > affect the size of the image on display, and Fimage_size doesn't > necessarily take them into consideration, AFAIR. Which image > properties that can appear in an image spec did you try with this > patch? And finally, images are clipped on display when they exceed > the length of a screen line, which Fimage_size doesn't take into > consideration, because it doesn't know at which horizontal coordinate > the image will be shown. > > So I'm afraid fixing check_display_width to support images will need > to simulate the display, i.e. use the move_it_* functions defined in > xdisp.c; just taking the image's size is not enough. Or maybe you > could use Fbuffer_text_pixel_size (which needs a window to do its > calculations, which is another complication of supporting images in > this case). Mm, that's pretty bad. I was mostly hoping that Fimage_size would do all the heavylifting for me. So, let me see if I have the components effecting the display size of an image right: 1. The image spec properties need to be calculated properly. It seems to me - from looking at the code and checking the image-size of a newly created image with various properties specified - that Fimage_size does all the calculations given the specs properly. So, unless something in xdisp.c effects the display width of an image (note that I don't mean _visible_; we're (I am) assuming we can see everything here), it _should_ be correct to just rely on Fimage_size for this bit. 2. Slice display spec needs to be handled. I'll add support for this in a bit. 3. Off-screen clipping is unlikely to be useful, and in fact it is better if we calculate the width without considering it, since when moving across columns we (at least I) behave as though everything was visible. Is that correct? Is there anything I'm missing here? If not, I can go ahead and try tackle the slice specs.
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.Received: (at 76107) by debbugs.gnu.org; 7 Feb 2025 08:10:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 07 03:10:58 2025 Received: from localhost ([127.0.0.1]:60861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tgJRy-0004R9-6S for submit <at> debbugs.gnu.org; Fri, 07 Feb 2025 03:10:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43130) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tgJRv-0004Qs-Fq for 76107 <at> debbugs.gnu.org; Fri, 07 Feb 2025 03:10:56 -0500 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 <eliz@HIDDEN>) id 1tgJRq-0001zR-0b; Fri, 07 Feb 2025 03:10:50 -0500 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=151e3TgT8DEn6upJDGrHFsBtsar/PIcf6+tHBDSVhMk=; b=U329lmyuHMxc UT/t11kuLWsd/4sU8RiykG2cD//bKNrsI/w4Cffkyl7t+g3mn/n+Dx56taH9OAm5O9+K0Ouk+5e7V RbzI8u0Zm7EtPeoAUZJAkmFJBEYH06mn2aRpc5M4d2FFSlshqTgbLrBDFv0cmnr8eAMtJRUpzkvJD D9M8T08j2AGpyO9TtW3BvnoSTDLlOMLdDlSa4o0JQanF8UI25O8XBEgQnvZXnukFXg+/x/VmImWMy eRCvDXb4pgS7MCDnDjEJ2xGAzJGg8dlS+4/uzIJ8szw7UueapZZpiTaW+KHdJLAkiccHs3l6pLpVd IC+9ZASDavQFPwmA+fJWzQ==; Date: Fri, 07 Feb 2025 10:10:45 +0200 Message-Id: <86ikpm5g56.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Thuna <thuna.cing@HIDDEN> In-Reply-To: <87a5ayirdp.fsf@HIDDEN> (message from Thuna on Fri, 07 Feb 2025 00:29:38 +0100) Subject: Re: bug#76107: Consider image specs when scanning for a column References: <87a5ayirdp.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76107 Cc: 76107 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Thuna <thuna.cing@HIDDEN> > Date: Fri, 07 Feb 2025 00:29:38 +0100 > > This patch handles display specs within `scan_for_column', which mainly > works to handle it in `current-column' and `move-to-column', which then > effects the filling functions and commands, and visual-fill-column, and > so on. > > The patch seems to be working, as far as I can tell, but it would be > nice if someone could take a look. Specifically, I copied the code to > convert the Lisp_Object holding the width into an integer from the code > above handling the space display properties, so that needs > double-checking. > > I decided to use `Fcar_safe' instead of `XCAR' when taking the `car' of > `Fimage_size' just to be safe but it doesn't look to be necessary? If > that's fine, then feel free to make the change. Thanks, but I don't see how this could work with just this code. The display property that uses images could be much more complex than just giving the image file name or data. First, there's the 'slice' display spec, which shows a slice of an image. More importantly, the IMAGE-SPEC part of the display property could include properties that affect the size of the image on display, and Fimage_size doesn't necessarily take them into consideration, AFAIR. Which image properties that can appear in an image spec did you try with this patch? And finally, images are clipped on display when they exceed the length of a screen line, which Fimage_size doesn't take into consideration, because it doesn't know at which horizontal coordinate the image will be shown. So I'm afraid fixing check_display_width to support images will need to simulate the display, i.e. use the move_it_* functions defined in xdisp.c; just taking the image's size is not enough. Or maybe you could use Fbuffer_text_pixel_size (which needs a window to do its calculations, which is another complication of supporting images in this case).
bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Feb 2025 23:30:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 06 18:30:00 2025
Received: from localhost ([127.0.0.1]:59847 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tgBJn-0004b4-V2
for submit <at> debbugs.gnu.org; Thu, 06 Feb 2025 18:30:00 -0500
Received: from lists.gnu.org ([2001:470:142::17]:36682)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <thuna.cing@HIDDEN>)
id 1tgBJl-0004ao-UY
for submit <at> debbugs.gnu.org; Thu, 06 Feb 2025 18:29:58 -0500
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 <thuna.cing@HIDDEN>)
id 1tgBJf-0005vE-9x
for bug-gnu-emacs@HIDDEN; Thu, 06 Feb 2025 18:29:51 -0500
Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <thuna.cing@HIDDEN>)
id 1tgBJd-0003pi-MB
for bug-gnu-emacs@HIDDEN; Thu, 06 Feb 2025 18:29:51 -0500
Received: by mail-ej1-x635.google.com with SMTP id
a640c23a62f3a-aaf3c3c104fso275641466b.1
for <bug-gnu-emacs@HIDDEN>; Thu, 06 Feb 2025 15:29:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1738884587; x=1739489387; darn=gnu.org;
h=mime-version:message-id:date:subject:to:from:from:to:cc:subject
:date:message-id:reply-to;
bh=+lGLnmgXA3ThWgi4XGZIv7imQ4NN9a2trYpVM687mWE=;
b=T7uJTWbPI6dYLl6sYw7ubgIyY03NNAki5C8gGoKtgbHp50evSnKiIA7JtNvYUR+mwp
PjjGVYxWvGQVlcfFoVYizYkECi7DKnroFpj9wV0CuCQL/ggE40PfFb9saTY8t9Ir0iGh
HWqMyuUO6S3cb0LpNl5ORX9ZtzOurgIaIlrV6YF8G+6C+nrJ1Li9A1qIJeQnyOJp1qhK
0tFC7vdwnUh1D+c4acpVXP09p++viVEnotUGhGGFosPDNQtqgpyqB+NXsKlGLKkLxTqa
Xw52lObnvN+ecVuRirHcpYiN1zprhFVZwwPAvhgYfd0uOBv9cZK1A44TZQoL8WleJFvr
Rabw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1738884587; x=1739489387;
h=mime-version:message-id:date:subject:to:from:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=+lGLnmgXA3ThWgi4XGZIv7imQ4NN9a2trYpVM687mWE=;
b=n79G27JSwXAxuidNEUry2dbTyDJjTeTd+4oSg01pkB6Nqzo3fjCghnwLikC3sBP6rA
BpygD0+EyoDa8LW9Pwv0IykymtN39F3coPaqVMoRpkbHPzLXoRokRv+vWeEQYL9ikLGY
97P6+PTCGTJClDZbH51CmcVHxNfH+dBTjqeZZXy5K31IvJefM9Mu9V3k9h8oUvgyfNuS
F839pkuSI5MFbJVf+0uO3TewavosVXvUPKcpxpYJbA+3GYPYFi0/v571uMU1qNjT3zWw
1hksKpP+yElpb227KJIDO940yqwxIpJjEb4LYBJtu8slL1jiqLYLH3uVv8wcALyVr0QB
5gxA==
X-Gm-Message-State: AOJu0YynszB/DNll/BuEtNuNL0uvacebTIiSYQcAeZGldVbn6gI6oyZ/
eLuAKyc09+s7Vyxl1G4i4Tazc/mERLx/V9gefYuhGVdaB2VxJo27aHmvzXZiIGrwGg==
X-Gm-Gg: ASbGnctR01eeGZGm0losWUchFyjhKlSaYEECrsmzTqtYmw1n+sP18BiA/JTurYVTADX
xrSxaEAWlYyKnp5Q/9jfKCkRSLEh3hWLgq3jfrIQiZpJvh6ETVklfpFrVbP09t3FUcqblHsVApg
WAzf3k5FR7dmFZFa9oMvoYFjTM5oU2pYIGo0aGXp7EyIkSVRZL14Gl/zIoERtM9sAMFP4Z6waSg
u1Z5hXnrs92uWMveB2+d4RuY7sFQXq2qpRTDij9+vyTvuHDVMYeHWZqG+wbo9Mhpy91/lcGCo2W
AdrnHmakCOjcL7NV
X-Google-Smtp-Source: AGHT+IGfa6DmZ4ZYXme6CjxpR4wEO3UnebSubUTQ4ebul7cCYtBwpBBGKQb6f1ElIHYufD0iLIfvww==
X-Received: by 2002:a17:907:1c22:b0:ab7:647:d52d with SMTP id
a640c23a62f3a-ab789c6e8c9mr75259466b.51.1738884586718;
Thu, 06 Feb 2025 15:29:46 -0800 (PST)
Received: from thuna-lis3 ([178.249.211.103]) by smtp.gmail.com with ESMTPSA id
4fb4d7f45d1cf-5dd9510a321sm1361252a12.63.2025.02.06.15.29.45
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 06 Feb 2025 15:29:45 -0800 (PST)
From: Thuna <thuna.cing@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Consider image specs when scanning for a column
Date: Fri, 07 Feb 2025 00:29:38 +0100
Message-ID: <87a5ayirdp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::635;
envelope-from=thuna.cing@HIDDEN; helo=mail-ej1-x635.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,
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-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--=-=-=
Content-Type: text/plain
This patch handles display specs within `scan_for_column', which mainly
works to handle it in `current-column' and `move-to-column', which then
effects the filling functions and commands, and visual-fill-column, and
so on.
The patch seems to be working, as far as I can tell, but it would be
nice if someone could take a look. Specifically, I copied the code to
convert the Lisp_Object holding the width into an integer from the code
above handling the space display properties, so that needs
double-checking.
I decided to use `Fcar_safe' instead of `XCAR' when taking the `car' of
`Fimage_size' just to be safe but it doesn't look to be necessary? If
that's fine, then feel free to make the change.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Consider-image-specs-when-scanning-for-a-column.patch
From 39e412bd6eb9fa37bb47005309ed4d36c853cabe Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@HIDDEN>
Date: Thu, 6 Feb 2025 19:51:28 +0100
Subject: [PATCH] Consider image specs when scanning for a column
* src/indent.c (check_display_width): If looking at an image display
property, return the image's width.
---
src/indent.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/indent.c b/src/indent.c
index 3094a9d3089..d503274ea0b 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -507,6 +507,16 @@ check_display_width (ptrdiff_t pos, ptrdiff_t col, ptrdiff_t *endpos)
&& (XFLOAT_DATA (prop) <= align_to_max))
width = (int)(XFLOAT_DATA (prop) + 0.5) - col;
}
+ /* Handle `(image ...)' display specs */
+ else if (CONSP (val) && EQ (Qimage, XCAR (val)))
+ {
+ Lisp_Object raw_width = Fcar_safe (Fimage_size (val, Qnil, Qnil));
+ if (RANGED_FIXNUMP (0, raw_width, INT_MAX))
+ width = XFIXNUM (raw_width);
+ else if (FLOATP (raw_width) && 0 <= XFLOAT_DATA (raw_width)
+ && XFLOAT_DATA (raw_width) <= INT_MAX)
+ width = (int) (XFLOAT_DATA (raw_width) + 0.5);
+ }
/* Handle 'display' strings. */
else if (STRINGP (val))
width = XFIXNUM (Fstring_width (val, Qnil, Qnil));
--
2.44.2
--=-=-=--
Thuna <thuna.cing@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#76107; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.