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.