[Top][All Lists]

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

Re: Overlay mechanic improvements

From: Richard Stallman
Subject: Re: Overlay mechanic improvements
Date: Mon, 22 Sep 2014 19:11:31 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > Why not?  If the images are thought of as part of the buffer contents,

    They most emphatically aren't.  Search and replace works on the
    underlying text (invalidating the image when a replace happens),
    incremental search works on the underlying text (temporarily removing
    the image), saving saves the underlying text, all editing commands apply
    to the underlying text.

Could you explain to me why this is right?
I never used that feature, so I don't understand the context.

    basically say "let's ignore all the mismatching semantics because the
    performance of overlays is bad".

No, I am not saying that.  I am saying something else:

    > I'd expect it to be desirable that they follow text that is copied.
    > If you kill text that contains some of these images of math
    > and then yank  it back, shouldn't it come back with the images?

    > This is what lead me to think of text properties first for this job.

Since you say that is not the desired behavior, I'd like to understand
why not.

What is a scenario for editing the text that is under the image
overlay, and what is the right behavior?

Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

reply via email to

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