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

[Garreau, Alexandre]

Le 18/10/2018 à 18h32, Yuri Khan a écrit :
> On Thu, Oct 18, 2018 at 4:51 PM Garreau, Alexandre
> <galex-713@galex-713.eu> 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
prone.

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?