[Top][All Lists]

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

Re: point moved despite save-excursion, after deleting/reinserting regio

From: Garreau, Alexandre
Subject: Re: point moved despite save-excursion, after deleting/reinserting region
Date: Thu, 18 Oct 2018 13:45:36 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu)

Le 18/10/2018 à 18h32, Yuri Khan a écrit :
> On Thu, Oct 18, 2018 at 4:51 PM Garreau, Alexandre
> <> wrote:
>> > When you delete text, markers pointing into that text cannot follow,
>> > they get relocated to the beginning/end of the deletion/insertion.
>> > What else can Emacs do, given that it doesn't know your future
>> > intentions?
>> I thought something such as `save-excursion' would do that, or that it
>> would be saved with the string, or something alike.
> Imagine if that was true: that save-excursion could somehow magically
> restore point across deletion of a fragment of text and subsequent
> re-insertion of the same fragment.
> Now comes the next guy (me!) and says, what if I re-insert not the
> same fragment but a slight modification of it? Maybe I wrapped it in a
> pair of XML tags. Or removed a pair of XML tags. Anyway, plz restore
> the point Doing The Right Thing, kthx.
> How would the hypothetical implementation of save-excursion do that?

Yes, if that modification comes from the same string.

> You’d probably want to make buffer-substring to return not only the
> buffer substring but also a representation of all markers within. You
> can’t put them into the string itself because that will confuse the
> algorithms that do the modification. You could probably put it into
> properties, but then those who use buffer-substring-no-properties
> lose. Further, insert would scan the inserted fragment and restore
> markers.

I’d say a function such as buffer-substring-no-properties clearly
indicates you *want* to loose/clear all associated metadata.

Though I’m not sure it may be properly done with text properties: aren’t
these made for storing metadata about *interval* of text, rather than
points? would something such as “#("text" 2 2 plist)” be appropriate?
here it is just taken away at evaluation, and anyway it looks redundant
as well.

> The practical answer to my position-preserving modifications is, do
> them directly in the buffer. If the modifications do not span the
> point, point will be preserved by save-excursion.
> Now returning to your modify-evaluate-undo scenario. How important is
> it to you that the evaluation happens in the original buffer? Maybe
> you could copy the fragment to a temporary buffer, modify and evaluate
> it there, have the temporary buffer killed for you? This way, the
> original buffer content is unmodified and the point is unmoved.
> Moreover, the undo history is untouched.

The problem is doing that elsewhere might have other side effects as
well: for instance a source block might use definitions of some other
source block or part of the org-file, or refer to some file, etc. and
anyway copying it in a new buffer, then parsing what its output is, then
putting it in the original buffer, is a lot more complex and error

The other alternative, of copying the whole widened buffer in a new
buffer, seems overkill, and may, I guess, still cause issues: if there
is a relative path affecting the evaluation, while the
“current-directory” of a such buffer, with no buffer-file, be guaranteed
the same?

reply via email to

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