bug#16752: 24.3.50; pp-to-string deactivates mark

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

Evaluating this expression returns:

(list deactivate-mark
      (pp-to-string '1)
      deactivate-mark)

returns (nil "1" t).  Deactivating the mark is a surprising and
unnecessary side effect.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Fri, 14 Feb 2014 10:46:08 +0100
> 
> Evaluating this expression returns:
> 
> (list deactivate-mark
>       (pp-to-string '1)
>       deactivate-mark)
> 
> returns (nil "1" t).  Deactivating the mark is a surprising and
> unnecessary side effect.

_Any_ change to _any_ buffer will set deactivate-mark, which is a
global variable.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

On Fri, Feb 14 2014, Eli Zaretskii wrote:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Fri, 14 Feb 2014 10:46:08 +0100
>> 
>> Evaluating this expression returns:
>> 
>> (list deactivate-mark
>>       (pp-to-string '1)
>>       deactivate-mark)
>> 
>> returns (nil "1" t).  Deactivating the mark is a surprising and
>> unnecessary side effect.
>
> _Any_ change to _any_ buffer will set deactivate-mark, which is a
> global variable.

What has that do to with pp-to-string?  I didn't ask for _any_ change to
_any_ buffer.

Helmut

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 16752@debbugs.gnu.org
> Date: Fri, 14 Feb 2014 12:02:33 +0100
> 
> >> (list deactivate-mark
> >>       (pp-to-string '1)
> >>       deactivate-mark)
> >> 
> >> returns (nil "1" t).  Deactivating the mark is a surprising and
> >> unnecessary side effect.
> >
> > _Any_ change to _any_ buffer will set deactivate-mark, which is a
> > global variable.
> 
> What has that do to with pp-to-string?  I didn't ask for _any_ change to
> _any_ buffer.

See pp-buffer, which is called by pp-string.  You asked for pp-string,
which does its job using a temporary buffer.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> Date: Fri, 14 Feb 2014 13:16:49 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16752@debbugs.gnu.org
> 
> See pp-buffer, which is called by pp-string.  You asked for pp-string,

Sorry, I meant pp-to-string, of course.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

On Fri, Feb 14 2014, Eli Zaretskii wrote:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: 16752@debbugs.gnu.org
>> Date: Fri, 14 Feb 2014 12:02:33 +0100
>> 
>> >> (list deactivate-mark
>> >>       (pp-to-string '1)
>> >>       deactivate-mark)
>> >> 
>> >> returns (nil "1" t).  Deactivating the mark is a surprising and
>> >> unnecessary side effect.
>> >
>> > _Any_ change to _any_ buffer will set deactivate-mark, which is a
>> > global variable.
>> 
>> What has that do to with pp-to-string?  I didn't ask for _any_ change to
>> _any_ buffer.
>
> See pp-buffer, which is called by pp-string.  You asked for pp-string,
> which does its job using a temporary buffer.

So you're saying that it's not a bug that pp-to-string modifies
deactivate-mark?

Helmut

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 16752@debbugs.gnu.org
> Date: Fri, 14 Feb 2014 12:23:02 +0100
> 
> On Fri, Feb 14 2014, Eli Zaretskii wrote:
> 
> >> From: Helmut Eller <eller.helmut@gmail.com>
> >> Cc: 16752@debbugs.gnu.org
> >> Date: Fri, 14 Feb 2014 12:02:33 +0100
> >> 
> >> >> (list deactivate-mark
> >> >>       (pp-to-string '1)
> >> >>       deactivate-mark)
> >> >> 
> >> >> returns (nil "1" t).  Deactivating the mark is a surprising and
> >> >> unnecessary side effect.
> >> >
> >> > _Any_ change to _any_ buffer will set deactivate-mark, which is a
> >> > global variable.
> >> 
> >> What has that do to with pp-to-string?  I didn't ask for _any_ change to
> >> _any_ buffer.
> >
> > See pp-buffer, which is called by pp-string.  You asked for pp-string,
> > which does its job using a temporary buffer.
> 
> So you're saying that it's not a bug that pp-to-string modifies
> deactivate-mark?

No, of course not.  I just described how this happens and why.  The
fix should be almost trivial, I think.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Stefan Monnier]

forcemerge 16728 16752
thanks

> Evaluating this expression returns:
> (list deactivate-mark
>       (pp-to-string '1)
>       deactivate-mark)

deactivate-mark is a global variable and lots of functions happen to
work on internal buffers, which ends up "unwittingly" setting
deactivate-mark to t.

There are 2 directions to try and fix it:
1- let-bind deactivate-mark in functions like pp-to-string so as to
   eliminate those spurious deactivations.  But there can be many of
   them, and it doesn't solve the problem where the buffer-modification
   is done in a non-temporary buffer.
2- make deactivate-mark buffer-local.  This is "The Right Way" but
   might introduce new problems.
   E.g. we really should deactivate the mark in all the buffers that
   have their deactivate-mark set.


        Stefan

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 14 Feb 2014 12:42:25 -0500
> Cc: 16752@debbugs.gnu.org
> 
> 1- let-bind deactivate-mark in functions like pp-to-string so as to
>    eliminate those spurious deactivations.  But there can be many of
>    them, and it doesn't solve the problem where the buffer-modification
>    is done in a non-temporary buffer.
> 2- make deactivate-mark buffer-local.  This is "The Right Way" but
>    might introduce new problems.
>    E.g. we really should deactivate the mark in all the buffers that
>    have their deactivate-mark set.

3- Save and restore deactivate-mark inside with-temp-buffer, which
   will probably solve 99.99% of these unexpected side effects.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

On Fri, Feb 14 2014, Eli Zaretskii wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 14 Feb 2014 12:42:25 -0500
>> Cc: 16752@debbugs.gnu.org
>> 
>> 1- let-bind deactivate-mark in functions like pp-to-string so as to
>>    eliminate those spurious deactivations.  But there can be many of
>>    them, and it doesn't solve the problem where the buffer-modification
>>    is done in a non-temporary buffer.
>> 2- make deactivate-mark buffer-local.  This is "The Right Way" but
>>    might introduce new problems.
>>    E.g. we really should deactivate the mark in all the buffers that
>>    have their deactivate-mark set.
>
> 3- Save and restore deactivate-mark inside with-temp-buffer, which
>    will probably solve 99.99% of these unexpected side effects.

4- Introduce something like buffer-disable-undo that disables this
automatic deactivate-mark updating.  BTW, with-temp-buffer should
disable undo by default.

Helmut

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Fri, 14 Feb 2014 19:27:30 +0100
> 
> On Fri, Feb 14 2014, Eli Zaretskii wrote:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date: Fri, 14 Feb 2014 12:42:25 -0500
> >> Cc: 16752@debbugs.gnu.org
> >> 
> >> 1- let-bind deactivate-mark in functions like pp-to-string so as to
> >>    eliminate those spurious deactivations.  But there can be many of
> >>    them, and it doesn't solve the problem where the buffer-modification
> >>    is done in a non-temporary buffer.
> >> 2- make deactivate-mark buffer-local.  This is "The Right Way" but
> >>    might introduce new problems.
> >>    E.g. we really should deactivate the mark in all the buffers that
> >>    have their deactivate-mark set.
> >
> > 3- Save and restore deactivate-mark inside with-temp-buffer, which
> >    will probably solve 99.99% of these unexpected side effects.
> 
> 4- Introduce something like buffer-disable-undo that disables this
> automatic deactivate-mark updating.

I thought about such a possibility as well, but it sounds less
attractive, because it places the burden on users and Lisp programs.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Stefan Monnier]

> 3- Save and restore deactivate-mark inside with-temp-buffer, which
>    will probably solve 99.99% of these unexpected side effects.

While with-temp-buffer is not technically a function, I'd count it as
covered by point number 1 ;-)


        Stefan

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eller.helmut@gmail.com,  16752@debbugs.gnu.org
> Date: Fri, 14 Feb 2014 16:00:34 -0500
> 
> > 3- Save and restore deactivate-mark inside with-temp-buffer, which
> >    will probably solve 99.99% of these unexpected side effects.
> 
> While with-temp-buffer is not technically a function, I'd count it as
> covered by point number 1 ;-)

My suggestion would free implementors of pp-to-string etc. from doing
that in every place where they use temporary buffers, which is a very
frequent paradigm in Emacs.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Stefan Monnier]

> My suggestion would free implementors of pp-to-string etc. from doing
> that in every place where they use temporary buffers, which is a very
> frequent paradigm in Emacs.

But it'll break code like

   (let ((buf (current-buffer)))
     (with-temp-buffer
       ...
       (with-current-buffer buf
         (insert "toto"))
       ...))


-- Stefan

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eller.helmut@gmail.com,  16752@debbugs.gnu.org
> Date: Sun, 16 Feb 2014 22:11:33 -0500
> 
> > My suggestion would free implementors of pp-to-string etc. from doing
> > that in every place where they use temporary buffers, which is a very
> > frequent paradigm in Emacs.
> 
> But it'll break code like
> 
>    (let ((buf (current-buffer)))
>      (with-temp-buffer
>        ...
>        (with-current-buffer buf
>          (insert "toto"))
>        ...))

And that is a problem because..?

bug#16752: 24.3.50; pp-to-string deactivates mark

[Stefan Monnier]

>> > My suggestion would free implementors of pp-to-string etc. from doing
>> > that in every place where they use temporary buffers, which is a very
>> > frequent paradigm in Emacs.
>> But it'll break code like
>> 
>> (let ((buf (current-buffer)))
>> (with-temp-buffer
>> ...
>> (with-current-buffer buf
>> (insert "toto"))
>> ...))
> And that is a problem because..?

Because it breaks some code.
After thinking some more about it, I wonder, tho: why don't we just make
deactivate-mark buffer-local?


        Stef

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eller.helmut@gmail.com,  16752@debbugs.gnu.org
> Date: Mon, 17 Feb 2014 15:27:49 -0500
> 
> After thinking some more about it, I wonder, tho: why don't we just make
> deactivate-mark buffer-local?

During a feature freeze?  Who knows what this will break?

bug#16752: 24.3.50; pp-to-string deactivates mark

[Stefan Monnier]

> During a feature freeze?

Haha!  Good one!


        Stefan

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

On Mon, Feb 17 2014, Stefan Monnier wrote:

> After thinking some more about it, I wonder, tho: why don't we just make
> deactivate-mark buffer-local?

After adding (make-variable-buffer-local 'deactivate-mark) to my .emacs
I didn't see any problems.

I noticed that mark is no longer deactivated by C-x C-e or M-C-x in the
*scratch* buffer.  Presumably because prin1 now only modifies the
deactivate-mark variable in the *Messages* buffer.

I also discovered that add-text-properties doesn't deactivate mark. That
was surprising to me because usually changing text properties counts as
modifying the buffer and supposedly "all the primitives that change the
buffer set `deactivate-mark'".

Helmut

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  16752@debbugs.gnu.org
> Date: Tue, 18 Feb 2014 09:31:14 +0100
> 
> I also discovered that add-text-properties doesn't deactivate mark.

It does for me, so please show a recipe.

bug#16752: 24.3.50; pp-to-string deactivates mark

[Helmut Eller]

On Tue, Feb 18 2014, Eli Zaretskii wrote:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  16752@debbugs.gnu.org
>> Date: Tue, 18 Feb 2014 09:31:14 +0100
>> 
>> I also discovered that add-text-properties doesn't deactivate mark.
>
> It does for me, so please show a recipe.

Hmm.. can't reproduce it now.  Apparently had called
add-text-properties two times with the same arguments.

Helmut

bug#16752: 24.3.50; pp-to-string deactivates mark

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: monnier@iro.umontreal.ca,  16752@debbugs.gnu.org
> Date: Tue, 18 Feb 2014 16:33:21 +0100
> 
> On Tue, Feb 18 2014, Eli Zaretskii wrote:
> 
> >> From: Helmut Eller <eller.helmut@gmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  16752@debbugs.gnu.org
> >> Date: Tue, 18 Feb 2014 09:31:14 +0100
> >> 
> >> I also discovered that add-text-properties doesn't deactivate mark.
> >
> > It does for me, so please show a recipe.
> 
> Hmm.. can't reproduce it now.  Apparently had called
> add-text-properties two times with the same arguments.

Then I think that's expected, since the second time is not considered
a change of the buffer (Emacs simply optimizes such a no-op away,
including the deactivation of mark).

bug#16752: 24.3.50; pp-to-string deactivates mark

[Alex]

close 16728 25.1
quit

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

> forcemerge 16728 16752
> thanks
>
>> Evaluating this expression returns:
>> (list deactivate-mark
>>       (pp-to-string '1)
>>       deactivate-mark)
>
> deactivate-mark is a global variable and lots of functions happen to
> work on internal buffers, which ends up "unwittingly" setting
> deactivate-mark to t.
>
> There are 2 directions to try and fix it:
> 1- let-bind deactivate-mark in functions like pp-to-string so as to
>    eliminate those spurious deactivations.  But there can be many of
>    them, and it doesn't solve the problem where the buffer-modification
>    is done in a non-temporary buffer.
> 2- make deactivate-mark buffer-local.  This is "The Right Way" but
>    might introduce new problems.
>    E.g. we really should deactivate the mark in all the buffers that
>    have their deactivate-mark set.
>
>
>         Stefan

Looks like option 2 was chosen, and the test cases in both bugs now work
as expected, so I believe this is done. Please re-open if I'm wrong.