Re: Invisibility bug: `invisible' vs `display'

[David Kastrup <dak@gnu.org>]

Daniel Brockman <daniel@brockman.se> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> Mixing invisible and display properties -- with the desire to actually
>>> get the effects of the display property looks very obscure to me, and
>>> cannot image that any code is actually relying on such functionality.
>>>
>>> I think the change is safe, so I installed it.
>>
>> Sigh.  If you use preview-latex on material where _some_ of it is made
>> invisible using TeX-fold-mode, the desired outcome will be to get the
>> display, and get it once only.
>
> The bug did not let you override the `invisible' property
> using the `display' property whenever you wanted;

How do you know what I want?

> it _only_ let you do that at the start of invisible text --- clearly
> counter-intuitive, counter-useful, illogical, and erroneous.

A display embedded in an invisible area should obviously not be
visible.  At the immediate edge, it is not clear what should take
preference.  If we have a display overlay with identical start and end
points both of which advance-on-insert, then the overlay _clearly_
marks the position _between_ the text before and behind it.  If the
text _behind_ it is invisible, this should obviously not affect the
overlay.  Even more so if the displayed overlay is
non-advance-on-insert.

Very clearly your proposed behavior is counter-intuitive,
counter-useful, illogical, and erroneous.

But since the patch does not involve any check related to "start of
invisible", it would, anyway, seem to do much more than the purported
fix.

So we not only get new, erroroneous behavior, but also we get an
undetermined and untested amount of such.

> The reason I'm laboring this point is that you do not seem to
> appreciate the obscurity of the now-eliminated special case.

And you do not seem to appreciate the non-obscurity of a number of not
so special cases that are now affected.

>> I can't vouch for the patch being either a step in the right or
>> wrong direction.
>
> Ignoring for a moment the fact that the old behavior was very
> strange (it was almost exactly like the new behavior, except for an
> obscure special case), are there actually any arguments for having
> `display' override `invisible'?
>
> If you want some text to show, why not just set `invisible'
> to nil on that text?

Display properties are not necessarily a part of text.

>> But I'd clearly like to see fewer "I think it should work and can't
>> imagine anybody actually using it, anyway" patches at this point in
>> the game.
>
> One can never be sure that no code is relying on obscure bugs, but I
> _can_ imagine that quite some code is actually relying on the manual
> being right in that ``any non-`nil' `invisible' property makes a
> character invisible [...] if you don't alter the default value of
> `buffer-invisibility-spec'.''[1]

You yourself said that the bug was obscure and showed only in obscure
cases.  I did not see anybody claim the same for the purported fix,
and there have been no tests.

-- 
David Kastrup