Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> > Actually, there is a fine distinction here.  The cursor can never be
> > immediately before a before-string.  It is either strictly before the
> > start of the overlay, in which case it is one character away from the
> > before-string, or it is on the first character of the overlay, in
> > which case it is _after_ the before-string.
> 
> I believe that the behavior should again depend on the insertion-type
> of the overlay's boundary.  If point is just at the beginning of an
> overlay with a before-string and inserting a char will move the
> overlay's boundary, then the cursor should be displayed before
> the before-string.
> This was recently brought up when discussing code that adds a "¶" at
> end of paragraphs (using a before-string property): the current code
> always displays the cursor just after this string, which looks very odd
> since typed text will be inserted before the string.

I just wanted to call back in order to report that preview-latex is
out of the debate.  I don't use the invisible text property any more.
And I don't use the isearch-invisible hooks anymore.  And I don't
want to have isearch bother about opening my overlays anymore (even
though they use the display property.  isearch never cared for that
up to now, and it should not do so in future.  If it will, I want to
know as soon as possible in order to know how to keep it from
bothering).

All that I ask is that
a) isearch and its cousins keep setting disable-point-adjustment to t
   when they don't want the cursor to be moved from the point of
   replacement
b) post-command-hook gets run *before* Emacs tries to attempt any point
   adjustment itself.

If it does, I have the choice of either
a) doing point adjustment the way I feel right if
disable-point-adjustment and global-disable-point-adjustment are not
set
b) remove the display property of my overlay if they are, so that
Emacs' point-adjustment will not have to do anything.
c) set disable-point-adjustment in the post-command-hook in order to
signal Emacs it should not bother itself.

I would be quite happy if query-replace would also run
post-command-hook with disable-point-adjustment set for every
replacement, but that's a different story.  Perhaps I'll be able to
find a way to persuade it to do the equivalent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: address@hidden