GNU bug report logs -
#73600
31.0.50; Visual wrap prefix mode and image display
Previous Next
Full log
Message #50 received at 73600 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Oct 2024 10:38:09 -0700
> Cc: 73600 <at> debbugs.gnu.org, gautier <at> gautierponsinet.xyz
> From: Jim Porter <jporterbugs <at> gmail.com>
>
> On 10/12/2024 10:36 PM, Eli Zaretskii wrote:
> > Yes, this is what I had in mind, thanks. But does
> > next-single-char-property-change really fit the bill? What if you
> > have several overlapping 'display' properties, and in particular one
> > property "enclosed" in another? Did you test such a scenario?
>
> I had tested those manually and they worked (according to my
> understanding of display properties, anyway). I've added some test cases
> to that effect in the latest patch.
>
> Just to make sure we're on the same page: my (admittedly limited)
> understanding of xdisp.c is that, for replacing-display-properties,
> Emacs determines the range of buffer text to replace by using 'eq' on
> the 'display' property. So if you have an 'image' spec from positions 1
> to 10, but add a 'height' spec from positions 3 to 4, Emacs will now
> render the image three times: one each for the ranges [1, 3), [3, 4),
> and [4, 10).
That is probably correct, at least in some cases, but why should we
rely on that for this purpose? Isn't it more reliable and
future-proof to skip the entire span of the outermost "replacing"
display property, and never look at properties inside that text? Does
it really matter for visual-wrap-prefix-mode to look inside?
IOW, I prefer simplicity of the logic to sophisticated design based on
what we actually see Emacs do in tricky cases, because time and again
I learned the hard way that my mental models of what actually happens
can be erroneous in the fine details.
This bug report was last modified 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.