emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should invisible imply intangible?


From: Richard Stallman
Subject: Re: Should invisible imply intangible?
Date: Tue, 19 Mar 2002 22:11:44 -0700 (MST)

    > It would be useful to have functions to get the text properties (or
    > just one of them) that would be inherited by an insertion at a given
    > buffer position.  It looks like that would be useful as a subroutine
    > for many purposes.

    Now this failure to get my meaning across certainly is my fault for
    using the wrong words.  What I wanted to make the behavior depend on
    was not the stickiness of properties, but actually the marker
    insertion type of the overlay boundaries.

It would make sense for those same subroutines to consider the marker
insertion type of overlay boundaries, because those control a kind of
inheritance--practically speaking--of overlay properties in insertion.

      If the cursor is kept out of invisible areas, it
    makes sense to try to define the insertion such that wherever a legal
    cursor position is, insertion characters will not insert into the
    invisible area.

That seems logical.

    This cannot always be achieved: when the overlay-beginning marker is
    of the stay-before-insertion variety, and the overlay-end marker is
    of the move-after-insertion variety, there will be no cursor position
    between the preceding visible and the following visible character
    where inserted characters would not become invisible.

We could say this is unreasonable usage.

      If the front
    marker is of the moving and the end marker of the staying variety, I
    would tend to make the position behind the invisible overlay legal (so
    that the overlay does not move),

Either one could be legitimate here, at first sight, but I think there
was some case where it was better to make the legitimate position be
before the invisible text, rather than after.

Anyway, it could take a lot of work to implement this, perhaps more
than we can muster.  Stefan, could you please fix the simpler case
that started this discussion?  Later on if people write something more
powerful we can install that.  Let's not let grandiose plans cripple
a simple job.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]