GNU bug report logs - #76107
Consider image specs when scanning for a column

Previous Next

Package: emacs;

Reported by: Thuna <thuna.cing <at> gmail.com>

Date: Thu, 6 Feb 2025 23:30:02 UTC

Severity: wishlist

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thuna <thuna.cing <at> gmail.com>
Cc: 76107 <at> debbugs.gnu.org
Subject: bug#76107: Consider image specs when scanning for a column
Date: Fri, 07 Feb 2025 19:13:12 +0200
> From: Thuna <thuna.cing <at> gmail.com>
> 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.




This bug report was last modified 48 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.