save-excursion doesn't always work

save-excursion doesn't always work

[Ittay Freiman]

hi,

i found this behavior while using auctex. to recreate, create a new
buffer for a tex document, with auctex as the mode (LaTeX-mode). type
in the first line 'this is a test'.

go down one line. '(point)' should return 16. now evaluate
'(save-excursion (LaTeX-fill-region-as-paragraph 1 16 t))'. nothing
actually changes in the buffer, but the cursor jumps to point 15. you
can repeat this with the same results.

can someone please tell me what is going on? also, if i write a
function that uses LaTeX-fill-region-as-paragraph, how can i return
the cursor to its original place (i'm currently using markers,
however, putting the cursor inside the filled region  creates weird
behaviors)

thanx,
ittay

Re: save-excursion doesn't always work

[David Kastrup]

ittay@qlusters.com (Ittay Freiman) writes:

> i found this behavior while using auctex. to recreate, create a new
> buffer for a tex document, with auctex as the mode
> (LaTeX-mode). type in the first line 'this is a test'.
> 
> go down one line. '(point)' should return 16. now evaluate
> '(save-excursion (LaTeX-fill-region-as-paragraph 1 16 t))'. nothing
> actually changes in the buffer,

Wrong.  A lot changes in the buffer.  Place some text property on the
space in question: it will be gone afterwards.  AUCTeX in the process
of filling deletes sequences of spaces completely, then reinserts a
single one.  Whether you were before or in or after such a deleted
space before the operation. you'll end up on the same side of the
reinserted space afterwards.

> but the cursor jumps to point 15. you can repeat this with the same
> results.
> 
> can someone please tell me what is going on? also, if i write a
> function that uses LaTeX-fill-region-as-paragraph, how can i return
> the cursor to its original place (i'm currently using markers,
> however, putting the cursor inside the filled region creates weird
> behaviors)

You can't, for the above reason.  AUCTeX's filling modes would have to
be rewritten so that instead of deleting all spaces and reinserting
one space, AUCTeX would delete all spaces except one.

I think Emacs' default filling by now does something like that.  If
you volunteer in trying to port the relevant portions, I will check
them into the AUCTeX code base: the current behavior is a nuisance
for other reasons as well.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: save-excursion doesn't always work

[Stefan Monnier <foo@acm.com>]

>>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:
> You can't, for the above reason.  AUCTeX's filling modes would have to
> be rewritten so that instead of deleting all spaces and reinserting
> one space, AUCTeX would delete all spaces except one.
> I think Emacs' default filling by now does something like that.

It might do a few things slightly differently, but it will modify the
buffer anyway, even if the end result is exactly the same as the
starting point (e.g. it will first turn all \n into spaces and then
turn them back into \n).


        Stefan

Re: save-excursion doesn't always work

[David Kastrup]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> >>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:
> > You can't, for the above reason.  AUCTeX's filling modes would have to
> > be rewritten so that instead of deleting all spaces and reinserting
> > one space, AUCTeX would delete all spaces except one.
> > I think Emacs' default filling by now does something like that.
> 
> It might do a few things slightly differently, but it will modify the
> buffer anyway, even if the end result is exactly the same as the
> starting point (e.g. it will first turn all \n into spaces and then
> turn them back into \n).

We are not talking about modification of the buffer, but about marks
being moved around in seemingly random manner.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: save-excursion doesn't always work

[Stefan Monnier <foo@acm.com>]

>> It might do a few things slightly differently, but it will modify the
>> buffer anyway, even if the end result is exactly the same as the
>> starting point (e.g. it will first turn all \n into spaces and then
>> turn them back into \n).
> We are not talking about modification of the buffer, but about marks
> being moved around in seemingly random manner.

Unless they're explicitly moved, marks only move in response to
buffer modifications.  Maybe the default filling function works
better than AUCTeX in this regard (I don't know) but even if it
does, it doesn't work 100% as the user wants it to.


        Stefan

Re: save-excursion doesn't always work

[David Kastrup]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> >> It might do a few things slightly differently, but it will modify the
> >> buffer anyway, even if the end result is exactly the same as the
> >> starting point (e.g. it will first turn all \n into spaces and then
> >> turn them back into \n).
> > We are not talking about modification of the buffer, but about marks
> > being moved around in seemingly random manner.
> 
> Unless they're explicitly moved, marks only move in response to
> buffer modifications.

Yes.  But if you do modifications that end up doing nothing, the
marks may move or not.  The former is more of a nuisance than the
latter.

> Maybe the default filling function works better than AUCTeX in this
> regard (I don't know) but even if it does, it doesn't work 100% as
> the user wants it to.

Come off it.  Nobody uses M-q as a substitute for forward-paragraph on
filled text.  It is a text-changing command.  I don't think people
will complain much if it changes text.  They will complain if regions
and marks end up on the wrong side of (maybe adjusted) white space,
though.  _Regardless_ of whether there were indeed formatting changes
or not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: save-excursion doesn't always work

[Stefan Monnier <foo@acm.com>]

>>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:
> Come off it.  Nobody uses M-q as a substitute for forward-paragraph on
> filled text.  It is a text-changing command.  I don't think people
> will complain much if it changes text.  They will complain if regions
> and marks end up on the wrong side of (maybe adjusted) white space,
> though.  _Regardless_ of whether there were indeed formatting changes
> or not.

I have no clue what makes you think I disagree with you.
I though I made it pretty clear that my comment was only an answer
to your implicit question about whether Emacs' default filling code
had solved that problem.


        Stefan

Re: save-excursion doesn't always work

[David Kastrup]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> >>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:
> > Come off it.  Nobody uses M-q as a substitute for forward-paragraph on
> > filled text.  It is a text-changing command.  I don't think people
> > will complain much if it changes text.  They will complain if regions
> > and marks end up on the wrong side of (maybe adjusted) white space,
> > though.  _Regardless_ of whether there were indeed formatting changes
> > or not.
> 
> I have no clue what makes you think I disagree with you.
> I though I made it pretty clear that my comment was only an answer
> to your implicit question about whether Emacs' default filling code
> had solved that problem.

Interesting.  Since _I_ said that Emacs' filling mode worked
differently (and more cautious) with regard to this aspect than
AUCTeX's, and since you contributed no information whatsoever about
Emacs' fill-mode behavior with regard to original poster's question
about AUCTeX's fill-mode and my explanation, I find it an interesting
twist that you now claim _I_ asked an implicit question which _you_
claim to have answered.

Well, suit yourself.  In that case, thank you for your answer
(whatever it may have been) to my implicit question (whatever that may
have been).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum