Re: Should invisible imply intangible?

["Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>]

>     isearch-open-invisible will call a user-supplied hook in order to make
>     invisible texts appear when searching.  Those images I use in my
>     buffer effectively make the original text invisible (for example, I
>     replace $\frac{\pi}{3}$ by an image for the formula), so I want
>     isearch to "open" them while going through the buffer.  isearch will,
>     however, only call isearch-open-invisible if the text/overlay is
>     marked as invisible, so that is what I do.
> 
> It would make more sense to modify isearch-open-invisible so it can
> deal with these images in another way.  The invisible property should
> override the display property and make the text it covers not appear,
> not as itself, not modified by a display property.

I'm not completely sure about that.  After all, why would someone
put a `display' property on an `invisible' overlay if the `invisible'
property means that the `display' property will be ignored anyway ?

In the case of `display' properties, I agree that your point of view
might be acceptable, but in the case of `before-string' and `after-string'
it is clearly not so, because it is very common to use an overlay
with both the `before-string' and the `invisible' property in order
to replace a piece of text with another.  In such a case we again end
up with `invisible' text which does have a screen representation so that
having point before or after the invisible text is user-visible
(just as is the case with ellipsis), which implies that we again shouldn't
prevent the user from placing point immediately after the invisible text.

I hope you're beginning to see what I meant when I said that it's
not easy to determine when a piece of `invisible' text really has
no effect on screen.  Checking the invisibility-spec is not enough:
you also have to check the presence of a `before-string' or an
`after-string' or a `display' (although this last one might disappear
if you decide that its behavior should be changed) and maybe there
are other cases.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel