save-excursion and the mark

save-excursion and the mark

[Stefan Monnier]

`save-excursion' is defined to save&restore the mark (as well as its
being active or not).

But I'm having a hard time finding a piece of code where we actually
make use of this.  Can someone point me to such code (either in Emacs or
in some external package)?  I.e. point me to code which would misbehave
if save-excursion were to stop saving&restoring the mark (and/or its
activation status).


        Stefan

Re: save-excursion and the mark

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> `save-excursion' is defined to save&restore the mark (as well as its
> being active or not).
>
> But I'm having a hard time finding a piece of code where we actually
> make use of this.  Can someone point me to such code (either in Emacs or
> in some external package)?  I.e. point me to code which would misbehave
> if save-excursion were to stop saving&restoring the mark (and/or its
> activation status).

I have a package that might be using the feature. None of the tests
were failing when I wrapped `save-excursion' like this:

    (defmacro lispy-save-excursion (&rest body)
      "More intuitive (`save-excursion' BODY)."
      (declare (indent 0))
      `(let ((activep (region-active-p))
             (mark (mark))
             (out (save-excursion
                    ,@body)))
         (when activep
           (set-mark mark))
         (when (bolp)
           (back-to-indentation))
         out))

I can test `save-excursion' again if you modify it.

Oleh

Re: save-excursion and the mark

[Stefan Monnier]

> I have a package that might be using the feature.

Where and how?

> None of the tests were failing when I wrapped `save-excursion' like
> this:

>     (defmacro lispy-save-excursion (&rest body)
>       "More intuitive (`save-excursion' BODY)."
>       (declare (indent 0))
>       `(let ((activep (region-active-p))
>              (mark (mark))
>              (out (save-excursion
>                     ,@body)))
>          (when activep
>            (set-mark mark))
>          (when (bolp)
>            (back-to-indentation))
>          out))

Hmm... this seems to redundantly save&restore the mark.  What is this
supposed to illustrate/test?


        Stefan

Re: save-excursion and the mark

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I have a package that might be using the feature.
>
> Where and how?

It's at https://github.com/abo-abo/lispy. There's a bunch of functions
that manipulate the active region sexp-wise. Some of them might use the
fact that the mark is restored. I can't be sure until I get a
`save-excursion' version that doesn't touch the mark.

>
>> None of the tests were failing when I wrapped `save-excursion' like
>> this:
>
>>     (defmacro lispy-save-excursion (&rest body)
>>       "More intuitive (`save-excursion' BODY)."
>>       (declare (indent 0))
>>       `(let ((activep (region-active-p))
>>              (mark (mark))
>>              (out (save-excursion
>>                     ,@body)))
>>          (when activep
>>            (set-mark mark))
>>          (when (bolp)
>>            (back-to-indentation))
>>          out))
>

> Hmm... this seems to redundantly save&restore the mark.  What is this
> supposed to illustrate/test?

Supposing that you would disable the mark storing/restoring in
`save-excursion', I rewrote my code to save/restore the mark on top of
that. It didn't hurt the tests.

It was hard for me to write my own `save-excursion' in Elisp to
completely test it, since it's not obvious how it works when chunks of
text are deleted.

Oleh

Re: save-excursion and the mark

[Artur Malabarba]

2015-02-23 23:14 GMT+00:00 Oleh Krehel <ohwoeowho@gmail.com>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I have a package that might be using the feature.
>>
>> Where and how?
>
> It's at https://github.com/abo-abo/lispy. There's a bunch of functions
> that manipulate the active region sexp-wise. Some of them might use the
> fact that the mark is restored. I can't be sure until I get a
> `save-excursion' version that doesn't touch the mark.

I think the following should do it.

(cl-letf* (((point-marker))
          ((current-buffer)))
    ;; Your code here.
    )

> Supposing that you would disable the mark storing/restoring in
> `save-excursion', I rewrote my code to save/restore the mark on top of
> that. It didn't hurt the tests.
It couldn't have hut the tests, given that it's redundant :-) (for now
at least).


> It was hard for me to write my own `save-excursion' in Elisp to
> completely test it, since it's not obvious how it works when chunks of
> text are deleted.

I think it just follows the point marker. Test the snippet above and
see if it works for you.

Re: save-excursion and the mark

[Oleh Krehel]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-02-23 23:14 GMT+00:00 Oleh Krehel <ohwoeowho@gmail.com>:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> I have a package that might be using the feature.
>>>
>>> Where and how?
>>
>> It's at https://github.com/abo-abo/lispy. There's a bunch of functions
>> that manipulate the active region sexp-wise. Some of them might use the
>> fact that the mark is restored. I can't be sure until I get a
>> `save-excursion' version that doesn't touch the mark.
>
> I think the following should do it.
>
> (cl-letf* (((point-marker))
>           ((current-buffer)))
>     ;; Your code here.
>     )
>
>> Supposing that you would disable the mark storing/restoring in
>> `save-excursion', I rewrote my code to save/restore the mark on top of
>> that. It didn't hurt the tests.
> It couldn't have hut the tests, given that it's redundant :-) (for now
> at least).

It might well could. If I was storing the point in this naive way, the
tests would have failed, since the point is adjusted by `save-excursion'
to the amount of text deleted. If I suppose that the mark was adjusted
as well, and the tests were using this aspect, then they would fail with
my naive approach on top of regular `save-excursion'.

>> It was hard for me to write my own `save-excursion' in Elisp to
>> completely test it, since it's not obvious how it works when chunks of
>> text are deleted.
>
> I think it just follows the point marker. Test the snippet above and
> see if it works for you.

It works! Thanks.

Oleh

Re: save-excursion and the mark

[Alexis]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> `save-excursion' is defined to save&restore the mark (as well as 
> its being active or not).
> 
> But I'm having a hard time finding a piece of code where we 
> actually make use of this.  Can someone point me to such code 
> (either in Emacs or in some external package)?  I.e. point me to 
> code which would misbehave if save-excursion were to stop 
> saving&restoring the mark (and/or its activation status).

My `org-vcard` package on MELPA makes use of `save-excursion` in a 
few places, but mostly out of politeness towards the user 
(i.e. restoring point after my code has done its thing). At any 
rate, since the usage is so limited, i'd be happy to manually save 
point and the mark, if it's felt that it would be generally 
beneficial for `save-excursion` to not do so itself.


Alexis.

Re: save-excursion and the mark

[Stefan Monnier]

> My `org-vcard` package on MELPA makes use of `save-excursion` in a few
> places, but mostly out of politeness towards the user (i.e. restoring point
> after my code has done its thing).

Yes.  99.9% of the uses expect it to save&restore point.  That's not the
cases I'm interested in.

> At any rate, since the usage is so limited, i'd be happy to manually
> save point and the mark, if it's felt that it would be generally
> beneficial for `save-excursion` to not do so itself.

I'm tempted to throw away the "save&restore mark" feature, since it
seems to be never used, and I've actually bumped into a few cases where
it's more annoying than useful (tho I wouldn't call them truly harmful).


        Stefan

Re: save-excursion and the mark

[Yuri Khan]

On Tue, Feb 24, 2015 at 9:52 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> I'm tempted to throw away the "save&restore mark" feature, since it
> seems to be never used, and I've actually bumped into a few cases where
> it's more annoying than useful (tho I wouldn't call them truly harmful).

Perhaps it can be solved in a backward-compatible way, by introducing
two new functions, say, save-point-excursion and save-mark-excursion,
then implementing save-excursion in terms of their composition and
cross-referencing both from its docstring?

Re: save-excursion and the mark

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Feb 22, 2015, at 11:44 PM, Stefan Monnier wrote:

>`save-excursion' is defined to save&restore the mark (as well as its
>being active or not).
>
>But I'm having a hard time finding a piece of code where we actually
>make use of this.

Won't this potentially break some poor user's code out there?  There's tons of
code that you'll never see because it's private.  save-excursion is documented
to save and restore mark, so people could be surprised by this API break, and
confused by their code suddenly breaking after an upgrade.  It seems risky.

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> to save and restore mark, so people could be surprised by this API break, and
> confused by their code suddenly breaking after an upgrade.  It seems risky.

It does seem risky.  At the same time, I can't find a single piece of
code that relies on this functionality so far.
So either the risk is minuscule, or I haven't looked in the right way.
Hence this thread, to try and see who and how might rely on this.


        Stefan

Re: save-excursion and the mark

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On Feb 24, 2015, at 02:27 PM, Stefan Monnier wrote:

>It does seem risky.  At the same time, I can't find a single piece of code
>that relies on this functionality so far.  So either the risk is minuscule,
>or I haven't looked in the right way.  Hence this thread, to try and see who
>and how might rely on this.

Sure, and that's appreciated, but of course most Emacs users probably don't
read this mailing list.  :)

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: save-excursion and the mark

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Posted on subreddit. Still a small fraction of all users, though.

https://www.reddit.com/r/emacs/comments/2x13db/does_anyone_ever_use_saveexcursion_to_preserve/
On Feb 24, 2015 5:11 PM, "Barry Warsaw" <barry@python.org> wrote:

> On Feb 24, 2015, at 02:27 PM, Stefan Monnier wrote:
>
> >It does seem risky.  At the same time, I can't find a single piece of code
> >that relies on this functionality so far.  So either the risk is
> minuscule,
> >or I haven't looked in the right way.  Hence this thread, to try and see
> who
> >and how might rely on this.
>
> Sure, and that's appreciated, but of course most Emacs users probably don't
> read this mailing list.  :)
>
> Cheers,
> -Barry
>

[-- Attachment #2: Type: text/html, Size: 1122 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> Posted on subreddit.  Still a small fraction of all users, though.

Users aren't really relevant here because they wouldn't know if the code
they run relies on this behavior.  Only package authors would know.


        Stefan

Re: save-excursion and the mark

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

> Users aren't really relevant here because they wouldn't know if the code
> they run relies on this behavior.  Only package authors would know.

Good point. Then that subreddit might be a good start. A lot of authors are
there.

[-- Attachment #2: Type: text/html, Size: 284 bytes --]

Re: save-excursion and the mark

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Feb 24, 2015, at 10:01 PM, Stefan Monnier wrote:

>Users aren't really relevant here because they wouldn't know if the code
>they run relies on this behavior.  Only package authors would know.

Just a quick response and then I'll stop.

I disagree.  Lots of users write little bits of lisp, or get lisp from their
colleagues and friends.  Much of it may never get published outside their
small network or corporate walls.  The point is that this is a long-published
and API and you will never know everyone who is relying on the documented
behavior.

When it's sometimes necessary to break an API, it's best to do it in a
backward compatible way, or progressively deprecate it.  In any case, I think
it's important to justify the break with a compelling rationale.  "Unused
AFAICT" often isn't such exactly because you can't reach your entire user
base, and you can't know how they are using it.

Cheers,
-Barry

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> When it's sometimes necessary to break an API, it's best to do it in a
> backward compatible way, or progressively deprecate it.

Of course.  I'm just trying to get a good view of the situation right
now, without which no decision can be taken.


        Stefan

RE: save-excursion and the mark

[Drew Adams]

> I disagree.  Lots of users write little bits of lisp, or get lisp from their
> colleagues and friends.  Much of it may never get published outside their
> small network or corporate walls.  The point is that this is a long-
> published and API and you will never know everyone who is relying on the
> documented behavior.
> 
> When it's sometimes necessary to break an API, it's best to do it in a
> backward compatible way, or progressively deprecate it.  In any case, I
> think it's important to justify the break with a compelling rationale.
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "Unused AFAICT" often isn't such exactly because you can't reach your
> entire user base, and you can't know how they are using it.

+1 - Change requires a compelling argument in favor, not just
     "Anyone here happen to see a compelling reason not to...?")

(At least that's the way it used to work.)

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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 make a new construct with a different name, such as
'save-point', to save only point.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[Stefan Monnier]

> Why not make a new construct with a different name, such as
> 'save-point', to save only point.

If save-excursion is in practice never used to save&restore the mark,
then changing save-excursion would be a lot simpler and would save us
from introducing a 99% redundant `save-point'.


        Stefan

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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. ]]]

  > If save-excursion is in practice never used to save&restore the mark,
  > then changing save-excursion would be a lot simpler and would save us
  > from introducing a 99% redundant `save-point'.

That's true, if it is _never_ used that way.  But it is hard to verify
_never_, and we can expect some things to break.  I think the principle
of avoiding incompatible changes is enough reason to pay the small price
of adding one more very simple construct.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[Stefan Monnier]

> That's true, if it is _never_ used that way.  But it is hard to verify
> _never_, and we can expect some things to break.

Definitely.  This said, the same holds for changing the function
slot of symbols so that they can't be unbound anymore (and use Qnil
instead of Qunbound).  Yet when I did that in 24.4 noone noticed.

> I think the principle of avoiding incompatible changes is enough
> reason to pay the small price of adding one more very
> simple construct.

Then again, the benefit of adding a new construct is rather minimal,


        Stefan

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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. ]]]

  > > That's true, if it is _never_ used that way.  But it is hard to verify
  > > _never_, and we can expect some things to break.

  > Definitely.  This said, the same holds for changing the function
  > slot of symbols so that they can't be unbound anymore (and use Qnil
  > instead of Qunbound).  Yet when I did that in 24.4 noone noticed.

save-excursion is used an awful lot.
symbol-function is used very rarely.
An incompatible change in save-excursion is much more likely
to break things than an incompatible change in symbol-function.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[martin rudalics]

 > save-excursion is used an awful lot.
 > symbol-function is used very rarely.
 > An incompatible change in save-excursion is much more likely
 > to break things than an incompatible change in symbol-function.

But this also means that detecting a breakage is more likely to happen
for a change in `save-excursion' than for a change in `symbol-function'.

I would make the change and wait until someone complains.  IMHO this is
the cheapest way to find out whether anyone really wants this to restore
the mark.

martin

Re: save-excursion and the mark

[Stefan Monnier]

> I would make the change and wait until someone complains.  IMHO this is
> the cheapest way to find out whether anyone really wants this to restore
> the mark.

Indeed, given that I still haven't found any example where it would
matter, the next step is likely to try it out.


        Stefan

Re: save-excursion and the mark

[Stefan Monnier]

> symbol-function is used very rarely.

FWIW, The change affected fboundp as well, which is also used a lot.


        Stefan

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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. ]]]

  > FWIW, The change affected fboundp as well, which is also used a lot.

How does a change in the internal representation of
unboundness affect code that uses fboundp?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[Stefan Monnier]

> How does a change in the internal representation of
> unboundness affect code that uses fboundp?

After

   (fset 'foo nil)

the old code would do

   (fboundp 'foo) => t

whereas the new code does

   (fboundp 'foo) => nil


-- Stefan

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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. ]]]

  > After

  >    (fset 'foo nil)

That was a bizarre thing to do, outside the normal use of function
cells.

  > the old code would do

  >    (fboundp 'foo) => t

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[Andreas Röhler]

On 23.02.2015 05:44, Stefan Monnier wrote:
>
> `save-excursion' is defined to save&restore the mark (as well as its
> being active or not).
>
> But I'm having a hard time finding a piece of code where we actually
> make use of this.  Can someone point me to such code (either in Emacs or
> in some external package)?  I.e. point me to code which would misbehave
> if save-excursion were to stop saving&restoring the mark (and/or its
> activation status).
>
>
>          Stefan
>
>

Hi Stefan,

See for example indent-code-ridigly.

IMO one of the most valuable functions in Emacs. Useful in all cases, where the extend of region is changed.
Fill-commands will use this - that way updating the users mark-(stack?).

Andreas

Re: save-excursion and the mark

[Stefan Monnier]

> See for example indent-code-ridigly.

Can you give more details about how this requires save&restore of the
mark (or its "active" status)?


        Stefan

Re: save-excursion and the mark

[Andreas Röhler]

On 25.02.2015 03:59, Stefan Monnier wrote:
>> See for example indent-code-ridigly.
>
> Can you give more details about how this requires save&restore of the
> mark (or its "active" status)?
>
>
>          Stefan
>

Think a shifting code by TAB in python-mode.

Mark might exist somewhere in line. Shifting will use its own region - but original region should be restored - if any.
Shifting by itself should not create a region nor clutter the mark-ring.

BTW you didn't tell whats the reason of the change:
Maybe it's worth reconsidering

commit b1d6ddd44614c84746f5ee494e1f29cd9be8a2d8

Notable changes to goto-line, i.e. calling push-mark.

Just an idea,

Andreas

Re: save-excursion and the mark

[Ivan Shmakov]

>>>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>>> On 25.02.2015 03:59, Stefan Monnier wrote:

 >>> See for example indent-code-ridigly.

 >> Can you give more details about how this requires save&restore of
 >> the mark (or its "active" status)?

 > Think a shifting code by TAB in python-mode.

	FWIW, python.el doesn’t seem to use the mark.

 > Mark might exist somewhere in line. Shifting will use its own region
 > – but original region should be restored – if any.  Shifting by
 > itself should not create a region nor clutter the mark-ring.

	There seem to be a misunderstanding; the notion of /Emacs Lisp/
	region is different to that of /Emacs/ region, the former being
	(more or less) a way of saying “from here to there”, and
	does /not/ (generally) involve either mark or point.

	For instance, indent-code-ridigly can be used from Lisp like:

   (indent-code-ridigly 13 37)

	Or perhaps:

   (when-let ((here  (re-search-backward "START" nil t))
              (there (re-search-forward  "END"   nil t)))
     (indent-code-ridigly here there))

	With the common idiom being:

   (let ((save (point)))
     ; Move point forward, by some amount.
     (indent-code-ridigly save (point)))

	As should be obvious, the mark is /not/ involved in either case.
	And, arguably, it /should not/ be.

[…]

 > commit b1d6ddd44614c84746f5ee494e1f29cd9be8a2d8

 > Notable changes to goto-line, i. e. calling push-mark.

	That makes a point, indeed: there’s a class of Emacs commands
	intended first and foremost for interactive use.  Naturally,
	goto-line is one of them; to quote its docstring:

This function is for interactive use only;
in Lisp code use `forward-line' instead.

	The proposed change to save-excursion would expose the bugs in
	the code which uses such commands inside of save-excursion,
	which now masks the unfortunate side-effects of such (mis)use.

-- 
FSF associate member #7257  np. Rule the World — Kamelot  3013 B6A0 230E 334A

Re: save-excursion and the mark

[Andreas Röhler]

On 25.02.2015 13:35, Ivan Shmakov wrote:
>>>>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>>>> On 25.02.2015 03:59, Stefan Monnier wrote:
>
>   >>> See for example indent-code-ridigly.
>
>   >> Can you give more details about how this requires save&restore of
>   >> the mark (or its "active" status)?
>
>   > Think a shifting code by TAB in python-mode.
>
> 	FWIW, python.el doesn’t seem to use the mark.
>
>   > Mark might exist somewhere in line. Shifting will use its own region
>   > – but original region should be restored – if any.  Shifting by
>   > itself should not create a region nor clutter the mark-ring.
>
> 	There seem to be a misunderstanding; the notion of /Emacs Lisp/
> 	region is different to that of /Emacs/ region, the former being
> 	(more or less) a way of saying “from here to there”, and
> 	does /not/ (generally) involve either mark or point.
>
> 	For instance, indent-code-ridigly can be used from Lisp like:
>
>     (indent-code-ridigly 13 37)
>
> 	Or perhaps:
>
>     (when-let ((here  (re-search-backward "START" nil t))
>                (there (re-search-forward  "END"   nil t)))
>       (indent-code-ridigly here there))
>
> 	With the common idiom being:
>
>     (let ((save (point)))
>       ; Move point forward, by some amount.
>       (indent-code-ridigly save (point)))
>
> 	As should be obvious, the mark is /not/ involved in either case.
> 	And, arguably, it /should not/ be.
>
> […]
>
>   > commit b1d6ddd44614c84746f5ee494e1f29cd9be8a2d8
>
>   > Notable changes to goto-line, i. e. calling push-mark.
>
> 	That makes a point, indeed: there’s a class of Emacs commands
> 	intended first and foremost for interactive use.  Naturally,
> 	goto-line is one of them; to quote its docstring:
>
> This function is for interactive use only;
> in Lisp code use `forward-line' instead.
>
> 	The proposed change to save-excursion would expose the bugs in
> 	the code which uses such commands inside of save-excursion,
> 	which now masks the unfortunate side-effects of such (mis)use.
>

Okay, thanks.

Andreas

Re: save-excursion and the mark

[Stefan Monnier]

> Think a shifting code by TAB in python-mode.

That doesn't help.  Give me a recipe.


        Stefan

Re: save-excursion and the mark

[Andreas Röhler]

On 25.02.2015 15:00, Stefan Monnier wrote:
>> Think a shifting code by TAB in python-mode.
>
> That doesn't help.  Give me a recipe.
>

Code inside indent-rigidly deals with mark issues, however seems to be local and should not affect state outside.

Join Ivan's opinion for now: in case code is broken after change it's expected to reveal a bug resp. a design flaw.

So far no objections any more,

thanks,

Andreas

Re: save-excursion and the mark

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 > `save-excursion' is defined to save&restore the mark (as well as its
 > being active or not).

 > But I'm having a hard time finding a piece of code where we actually
 > make use of this.  Can someone point me to such code (either in Emacs
 > or in some external package)?  I. e. point me to code which would
 > misbehave if save-excursion were to stop saving&restoring the mark
 > (and/or its activation status).

	FWIW, I’m having a hard time thinking of /why/ someone may make
	use of such a behavior.  The mark is pretty much a UI feature,
	and the code isn’t supposed to ever touch it /unless/ the very
	intent of said code is to change its position.  At which point
	saving and restoring its state becomes contrary to that intent.

	Unless there be a substantial code base which relies on the
	current behavior, I’d rather just change it, while taking
	reasonable effort to identify the affected packages and inform
	their respective maintainers of the fixes necessary.

-- 
FSF associate member #7257  Mother Gaia — Stratovarius  … 3013 B6A0 230E 334A

Re: save-excursion and the mark

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Wed, 25 Feb 2015 09:18:00 +0000
> 
> 	FWIW, I’m having a hard time thinking of /why/ someone may make
> 	use of such a behavior.  The mark is pretty much a UI feature,
> 	and the code isn’t supposed to ever touch it /unless/ the very
> 	intent of said code is to change its position.  At which point
> 	saving and restoring its state becomes contrary to that intent.

The code inside save-excursion could inadvertently or unknowingly
invoke functions that push the mark.

Re: save-excursion and the mark

[Magnar Sveen]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

The change breaks expand-region, for one.

On Mon, Feb 23, 2015 at 5:44 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>
> `save-excursion' is defined to save&restore the mark (as well as its
> being active or not).
>
> But I'm having a hard time finding a piece of code where we actually
> make use of this.  Can someone point me to such code (either in Emacs or
> in some external package)?  I.e. point me to code which would misbehave
> if save-excursion were to stop saving&restoring the mark (and/or its
> activation status).
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> The change breaks expand-region, for one.

Ha!  We got one!
Can you show us the code that depends on this?


        Stefan

Re: save-excursion and the mark

[Stefan Monnier]

> The change breaks expand-region, for one.

Looks like the problem is basically in er--expand-region-1 where you do:

    (while try-list
      (save-excursion
        (ignore-errors
	  (setq mark-active nil)
          (funcall (car try-list))
          (when (and (region-active-p)
    [...]

The test (region-active-p) is meant to check whether the (car try-list)
function activated the region, but you don't actually ensure that the
region is deactivated before the call.  So if that function "fails" and
the region happened to be enabled when we entered er--expand-region-1 you
end up taking that "input region" as one of the choices.

In practice this was harmless, but I don't think it was ever correct.
The patch below seems to fix the behavior.


        Stefan


diff --git a/expand-region-core.el b/expand-region-core.el
index ccab290..942318c 100644
--- a/expand-region-core.el
+++ b/expand-region-core.el
@@ -92,6 +92,7 @@ moving point or mark as little as possible."
     (while try-list
       (save-excursion
         (ignore-errors
+	  (setq mark-active nil)
           (funcall (car try-list))
           (when (and (region-active-p)
                      (er--this-expansion-is-better start end best-start best-end))

Re: save-excursion and the mark

[Magnar Sveen]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Thanks for taking a look. Unfortunately it breaks several expansions, that
use the current mark as input to its expansion. If you are indeed going
forward with this change (why is that?), then maybe we could get a
save-mark function?

On Wed, Apr 8, 2015 at 3:57 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > The change breaks expand-region, for one.
>
> Looks like the problem is basically in er--expand-region-1 where you do:
>
>     (while try-list
>       (save-excursion
>         (ignore-errors
>           (setq mark-active nil)
>           (funcall (car try-list))
>           (when (and (region-active-p)
>     [...]
>
> The test (region-active-p) is meant to check whether the (car try-list)
> function activated the region, but you don't actually ensure that the
> region is deactivated before the call.  So if that function "fails" and
> the region happened to be enabled when we entered er--expand-region-1 you
> end up taking that "input region" as one of the choices.
>
> In practice this was harmless, but I don't think it was ever correct.
> The patch below seems to fix the behavior.
>
>
>         Stefan
>
>
> diff --git a/expand-region-core.el b/expand-region-core.el
> index ccab290..942318c 100644
> --- a/expand-region-core.el
> +++ b/expand-region-core.el
> @@ -92,6 +92,7 @@ moving point or mark as little as possible."
>      (while try-list
>        (save-excursion
>          (ignore-errors
> +         (setq mark-active nil)
>            (funcall (car try-list))
>            (when (and (region-active-p)
>                       (er--this-expansion-is-better start end best-start
> best-end))
>

[-- Attachment #2: Type: text/html, Size: 2086 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> If you are indeed going forward with this change (why is that?),

There are various problems with the previous save-excursion semantics,
all linked to the mark-saving part of it, and this part is useless in
98% of the cases, useful in 1%, and harmful in 1%, so it's better to get
rid of it in my view.

Among the various problems, I actually fixed some recently (before
throwing out the code), but the remaining ones are ugly:
saving/restoring the mark includes saving/restoring the mark-active
state as well, and in the general case you'd also want to run the
(de)activate-mark-hook, which could break even more uses of
save-excursion which never expected it to run such hook code.

> then maybe we could get a save-mark function?

Since you're the only user so far, better write explicitly the exact
saving/restoring you need (especially since it's not obvious to me what
it is you really need, I guess you could start with something along the
lines of (cl-letf (((mark)) (mark-active mark-active)) ...)).


        Stefan

Re: save-excursion and the mark

[Magnar Sveen]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

There are millions of lines of elisp that you've never seen. Emacs is after
all the eminently hackable editor. And you're making breaking changes to a
core API out of a sense of cleanliness? You've now been made aware of one
case where the change is harmful, and your conclusion is "this is the one
case where it is harmful". No, it's the first case where it's been detected
- and that's because expand-region is widely used by thousands of people -
and thankfully it even has tests. People's code is going to break.

You are maintaining an API with many thousands of users. Don't break it. If
you must, deprecate it. Introduce save-point, and add "You probably want to
use save-point" to the docstring of save-excursion.


On Tue, Apr 14, 2015 at 10:17 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > If you are indeed going forward with this change (why is that?),
>
> There are various problems with the previous save-excursion semantics,
> all linked to the mark-saving part of it, and this part is useless in
> 98% of the cases, useful in 1%, and harmful in 1%, so it's better to get
> rid of it in my view.
>
> Among the various problems, I actually fixed some recently (before
> throwing out the code), but the remaining ones are ugly:
> saving/restoring the mark includes saving/restoring the mark-active
> state as well, and in the general case you'd also want to run the
> (de)activate-mark-hook, which could break even more uses of
> save-excursion which never expected it to run such hook code.
>
> > then maybe we could get a save-mark function?
>
> Since you're the only user so far, better write explicitly the exact
> saving/restoring you need (especially since it's not obvious to me what
> it is you really need, I guess you could start with something along the
> lines of (cl-letf (((mark)) (mark-active mark-active)) ...)).
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 2464 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

> You are maintaining an API with many thousands of users. Don't break it.

Maintaing broken APIs is all a matter of tradeoffs.  We happen to
disagree on those tradeoffs here.  So far your case is the only one.
If/when the many other cases come storming, I might reconsider those
tradeoffs, of course.

> If you must, deprecate it. Introduce save-point, and add "You probably
> want to use save-point" to the docstring of save-excursion.

That wouldn't solve the problems with save-excursion.


        Stefan

Re: save-excursion and the mark

[Magnar Sveen]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

> That wouldn't solve the problems with save-excursion.

You're calling save-excursion a "broken API", but it's in use everywhere -
it is a staple of emacs lisp - and has been working for years. So yeah,
offering an alternative for the 1% of cases where it isn't working as
intended would solve the problem. With no breakage.

I don't get the impression that you're taking seriously the millions of
lines of code that you don't have access to. That was written years ago.
That was copied from the emacs wiki. That people are relying on, but no
longer know how to change. It's not like you'll get a proper error message
when it breaks.

> If/when the many other cases come storming, I might reconsider those tradeoffs,
of course.

Are you seriously expecting users of Emacs to storm into emacs-devel in
anticipation of their code breaking prior to a release? Or are you talking
about rolling back a breaking change after the fact, creating issues for
new code relying on new behavior?

It was just the other day that I pointed out a package in Emacs that's from
1999 to a friend. It's not been changed since. I used it as an example of
how stable Emacs is, and how it allows for a piece of software to be done.
Really done. This new attitude towards breaking changes saddens me in that
light.

- Magnar

On Wed, Apr 15, 2015 at 2:53 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > You are maintaining an API with many thousands of users. Don't break it.
>
> Maintaing broken APIs is all a matter of tradeoffs.  We happen to
> disagree on those tradeoffs here.  So far your case is the only one.
> If/when the many other cases come storming, I might reconsider those
> tradeoffs, of course.
>
> > If you must, deprecate it. Introduce save-point, and add "You probably
> > want to use save-point" to the docstring of save-excursion.
>
> That wouldn't solve the problems with save-excursion.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 2673 bytes --]

Re: save-excursion and the mark

[Stefan Monnier]

>> That wouldn't solve the problems with save-excursion.
> You're calling save-excursion a "broken API", but it's in use everywhere -

Yes, the save-point part of it is used everywhere and works well.
The save-mark part of it was used pretty much nowhere and does not work well.

> it is a staple of emacs lisp - and has been working for years.

Still works.  Just ever so slightly differently.

> So yeah, offering an alternative for the 1% of cases where it isn't
> working as intended would solve the problem. With no breakage.

As mentioned, there was breakage.

> It's not like you'll get a proper error message when it breaks.

I know, just like the previously existing breakage that got fixed by
this change.

> Are you seriously expecting users of Emacs to storm into emacs-devel in
> anticipation of their code breaking prior to a release?

There's already been very hot debates about this change, but actual
examples of broken code have been really hard to come by, so despite the
heat I've gotten, am getting, and will keep getting, I'll stick to my
guns for now.

> Or are you talking about rolling back a breaking change after the fact,

That's clearly an option.  Doing so after 25.1 is released would be
highly unlikely, but until 25.1 the change is tentative.

> creating issues for new code relying on new behavior?

Based on what I've seen of existing uses of save-excursion, I'm not
worried about this.

> It was just the other day that I pointed out a package in Emacs that's
> from 1999 to a friend.  It's not been changed since.  I used it as an
> example of how stable Emacs is, and how it allows for a piece of
> software to be done.  Really done.  This new attitude towards breaking
> changes saddens me in that light.

Every Emacs release introduced incompatible changes.  Maybe more so
under my maintainership, I don't know.

But the only thing that could change my opinion, I think, is more
evidence that this change breaks a lot of code (and of course, such
evidence is stronger when found in high-quality code, since I'm more
willing to break bad code than good code).


        Stefan

Re: save-excursion and the mark

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On 04/15/2015 07:59 AM, Stefan Monnier wrote:
>>> That wouldn't solve the problems with save-excursion.
>> You're calling save-excursion a "broken API", but it's in use everywhere -
> 
> Yes, the save-point part of it is used everywhere and works well.
> The save-mark part of it was used pretty much nowhere and does not work well.
> 
>> it is a staple of emacs lisp - and has been working for years.
> 
> Still works.  Just ever so slightly differently.
> 
>> So yeah, offering an alternative for the 1% of cases where it isn't
>> working as intended would solve the problem. With no breakage.
> 
> As mentioned, there was breakage.
> 
>> It's not like you'll get a proper error message when it breaks.
> 
> I know, just like the previously existing breakage that got fixed by
> this change.
> 
>> Are you seriously expecting users of Emacs to storm into emacs-devel in
>> anticipation of their code breaking prior to a release?
> 
> There's already been very hot debates about this change, but actual
> examples of broken code have been really hard to come by, so despite the
> heat I've gotten, am getting, and will keep getting, I'll stick to my
> guns for now.
> 
>> Or are you talking about rolling back a breaking change after the fact,
> 
> That's clearly an option.  Doing so after 25.1 is released would be
> highly unlikely, but until 25.1 the change is tentative.
> 
>> creating issues for new code relying on new behavior?
> 
> Based on what I've seen of existing uses of save-excursion, I'm not
> worried about this.
> 
>> It was just the other day that I pointed out a package in Emacs that's
>> from 1999 to a friend.  It's not been changed since.  I used it as an
>> example of how stable Emacs is, and how it allows for a piece of
>> software to be done.  Really done.  This new attitude towards breaking
>> changes saddens me in that light.
> 
> Every Emacs release introduced incompatible changes.  Maybe more so
> under my maintainership, I don't know.
> 
> But the only thing that could change my opinion, I think, is more
> evidence that this change breaks a lot of code (and of course, such
> evidence is stronger when found in high-quality code, since I'm more
> willing to break bad code than good code).

FWIW, I agree that breaking strict compatibility in this particular
instance is the right thing to do.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: save-excursion and the mark

[Richard Stallman]

[[[ 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. ]]]

  > You are maintaining an API with many thousands of users. Don't break it. If
  > you must, deprecate it. Introduce save-point, and add "You probably want to
  > use save-point" to the docstring of save-excursion.

I think that is wise.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: save-excursion and the mark

[Phillip Lord]

Magnar

While I can appreciate your point (oops, pun). But, while introducing a
new macro and effectively deprecating save-excursion would be safe, it
would be unlikely to have any real effects at all, simply because as you
say Emacs is very stable. That is, the vast majority of save-excursion
calls will never get changed, even if save-excursion is deprecated.

Changing "save-excursion" and introducing "save-mark-excursion" would be
another possibility (although the latter would have  the difficulties
that Stefan has described with, for example, activate-mark-hook.

Phil

Magnar Sveen <magnars@gmail.com> writes:

> There are millions of lines of elisp that you've never seen. Emacs is after
> all the eminently hackable editor. And you're making breaking changes to a
> core API out of a sense of cleanliness? You've now been made aware of one
> case where the change is harmful, and your conclusion is "this is the one
> case where it is harmful". No, it's the first case where it's been detected
> - and that's because expand-region is widely used by thousands of people -
> and thankfully it even has tests. People's code is going to break.
>
> You are maintaining an API with many thousands of users. Don't break it. If
> you must, deprecate it. Introduce save-point, and add "You probably want to
> use save-point" to the docstring of save-excursion.

Re: save-excursion and the mark

[Oleh Krehel]

Hi Stefan,

I finally got around to fixing the lispy tests for emacs-snapshot.

Here's a reference to the first passing build:
https://travis-ci.org/abo-abo/lispy/builds/59129245

And here's the commit that fixed the stuff:
https://github.com/abo-abo/lispy/commit/bf5c12276a414a9cc6a131c86b5c9a33af3dca53

It was also tricky to write code in a way that the tests pass both on 25
and 24.5.

One thing that I really didn't like is that I had to replace

    (region-active-p)

with 

    (and mark-active (not deactivate-mark))

because (region-active-p) started behaving differently in temp buffers
and non-temp buffers. Before, the behavior was the same.

Just my small note to add to the list of "casualties".

Oleh

Re: save-excursion and the mark

[Stefan Monnier]

> One thing that I really didn't like is that I had to replace
>     (region-active-p)
> with 
>     (and mark-active (not deactivate-mark))

I think this should be

     (and (region-active-p) (not deactivate-mark))

The (not deactivate-mark) test has always been needed if you intend your
tests to check what the user would see after running that code
interactively (in which case the command loop would deactivate the mark
at the end of the command if deactivate-mark is set).

The fact that you did not need (not deactivate-mark) in the past was
just a lucky accident for the code you happened to test.


        Stefan

Re: save-excursion and the mark

[Andreas Röhler]

Hi Stefan,

Am 14.04.2015 um 22:16 schrieb Stefan Monnier:
>> If you are indeed going forward with this change (why is that?),
> There are various problems with the previous save-excursion semantics,
> all linked to the mark-saving part of it, and this part is useless in
> 98% of the cases, useful in 1%, and harmful in 1%, so it's better to get
> rid of it in my view.
>
> Among the various problems, I actually fixed some recently (before
> throwing out the code), but the remaining ones are ugly:
> saving/restoring the mark includes saving/restoring the mark-active
> state as well, and in the general case you'd also want to run the
> (de)activate-mark-hook, which could break even more uses of
> save-excursion which never expected it to run such hook code.

Understand the wish to simplify things in this context.

AFAIU there is some redundancy - what about deprecating explicit setting 
of mark-active?

Its documentation says:
Non-nil means the mark and region are currently active in this buffer.

Maybe conceive region-active-p just as non-nil extend between point and 
mark - returning nil in case a mark is  not set?

Andreas




>
>> then maybe we could get a save-mark function?
> Since you're the only user so far, better write explicitly the exact
> saving/restoring you need (especially since it's not obvious to me what
> it is you really need, I guess you could start with something along the
> lines of (cl-letf (((mark)) (mark-active mark-active)) ...)).
>
>
>          Stefan
>
>

Re: save-excursion and the mark

[Frank Fischer]

Am 23.02.2015 um 05:44 schrieb Stefan Monnier:
> 
> `save-excursion' is defined to save&restore the mark (as well as its
> being active or not).
> 
> But I'm having a hard time finding a piece of code where we actually
> make use of this.  Can someone point me to such code (either in Emacs or
> in some external package)?  I.e. point me to code which would misbehave
> if save-excursion were to stop saving&restoring the mark (and/or its
> activation status).

It's probably a little late but that change just caused a bug in the
evil-mode package. Because Evil does deal a lot with the user interface
it sometimes plays around with point and mark.

Currently it's only one place, I can fix that easily. But I have no idea
if we rely on the old behaviour in other places.

However, I can live with the new behaviour, it just took me some time to
find out what causes that bug ;)

Best regards,
Frank

Re: save-excursion and the mark

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>                             I.e. point me to code which would misbehave
> if save-excursion were to stop saving&restoring the mark (and/or its
> activation status).

I found two more places where the behaviour is/was used :

1. In AUCTeX, e.g.

(defun LaTeX-fill-environment (justify)
  "Fill and indent current environment as LaTeX text."
  (interactive "*P")
  (save-excursion
    (LaTeX-mark-environment) ;; <= this activates the mark
    (re-search-forward "{\\([^}]+\\)}")
    (LaTeX-fill-region (region-beginning) (region-end) justify
		       (concat " environment " (TeX-match-buffer 1))))

The mark ends up being active when it was not. This happens with emacs
master, and doesn't happen with emacs 24.

2. In replace.el, in query-replace-read-from

There is a comment:
	    ;; The save-excursion here is in case the user marks and copies
	    ;; a region in order to specify the minibuffer input.
	    ;; That should not clobber the region for the query-replace itself.

and indeed, with emacs master, if you mark some text (to act only on
that region), hit M-%, then C-x o, mark some other text, hit C-x o
again, and fill the prompt to do a replacement, the replacement is done
on the newly marked region. Here also, this doesn't happen in emacs 24.

I hope this helps.

Nicolas.

save-excursion and the mark

[Lars Magne Ingebrigtsen]

Code that previously relied on `save-excursion' restoring the mark no
longer works, and that's fine.  But could we have a new form like
`save-mark' (or something) that we could just slap around forms that
previously relied on this form behaving the old way?

I was just bitten by this by the async hashcash code moving the mark
around and me kill/yanking the wrong bits of the text.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: save-excursion and the mark

[Stefan Monnier]

> Code that previously relied on `save-excursion' restoring the mark no
> longer works, and that's fine.  But could we have a new form like
> `save-mark' (or something) that we could just slap around forms that
> previously relied on this form behaving the old way?

(cl-letf (((mark))) ...) might do the trick.
Or maybe you'll need (cl-letf (((mark)) (mark-active)) ...).
note that if the "..." activates or deactivates the mark, you're
probably somewhat in trouble in the sense that (de)activate-mark-hook
will be run, despite the cl-letf, and you can't really undo the effect
of running a hook.


        Stefan

Re: save-excursion and the mark

[Wolfgang Jenkner]

On Sat, Apr 18 2015, Stefan Monnier wrote:

>> Code that previously relied on `save-excursion' restoring the mark no
>> longer works, and that's fine.  But could we have a new form like
>> `save-mark' (or something) that we could just slap around forms that
>> previously relied on this form behaving the old way?
>
> (cl-letf (((mark))) ...) might do the trick.
> Or maybe you'll need (cl-letf (((mark)) (mark-active)) ...).
> note that if the "..." activates or deactivates the mark, you're
> probably somewhat in trouble in the sense that (de)activate-mark-hook
> will be run, despite the cl-letf, and you can't really undo the effect
> of running a hook.

It would be useful to know which existing uses of (de)activate-mark-hook
are worrisome.

In lisp/ there are very few instances where functions are added to those
hooks (only for rectangle marking and "enhanced edt keypad mode
emulation", whatever that is).  In elpa, there seems to be none at all.
So, those uses seem too marginal to draw conclusions.

In theory, of course, there are ways to set or bind symbols which are
not amenable to grepping, so I might have missed something.

The instance of emacs I'm running says

    activate-mark-hook is a variable defined in `simple.el'.
    Its value is (evil-visual-activate-hook t)
    Local in buffer *unsent wide reply to Stefan Monnier*; global value is nil

I'd guess that most users of evil turn on evil-mode, which is
a globalized minor mode, so any problem with some inadvertent use of
save-excursion would have surfaced quickly.

Wolfgang

Re: save-excursion and the mark

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> (cl-letf (((mark))) ...) might do the trick.

Thanks; that kinda cryptic incantation seems to do the trick

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: save-excursion and the mark

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> (cl-letf (((mark))) ...) might do the trick.
>
> Thanks; that kinda cryptic incantation seems to do the trick

Actually, it just made things break in a different way.

The following code used to work, and is run from a process filter
(asynchronously):

(defun hashcash-insert-payment-async-2 (buffer process pay)
  (when (buffer-live-p buffer)
    (with-current-buffer buffer
      (save-excursion
	(save-restriction
	  (setq hashcash-process-alist (delq
					(assq process hashcash-process-alist)
					hashcash-process-alist))
	  (message-goto-eoh)
	  (when pay
	    (insert-before-markers "X-Hashcash: " pay)))))))

If I put the mark somewhere in the buffer, and the text is then
inserted, then the mark suddenly has the same value as point.

If I wrap this code in the `cl-letf', the mark value doesn't change at
all, which means that it now points to somewhere else in the buffer.
(Since the X-Hashcash header is inserted before the mark.)  That is, the
numerical value of the mark doesn't change, so it visually moves
backwards in the buffer, since text has been inserted before the mark.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: save-excursion and the mark

[Artur Malabarba]

>>> (cl-letf (((mark))) ...) might do the trick.
>>
>> Thanks; that kinda cryptic incantation seems to do the trick
>
> Actually, it just made things break in a different way.
> (Since the X-Hashcash header is inserted before the mark.)  That is, the
> numerical value of the mark doesn't change, so it visually moves
> backwards in the buffer, since text has been inserted before the mark.

Try using (cl-letf (((mark-marker))) ...) instead. It should preseve
the mark's marker position, instead of numeric position.