bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

Visit this file, without loading it:
http://www.emacswiki.org/emacs/wide-n.el
 
Change this line:
(setq wide-n-restrictions
      (remove (cons mrk1 mrk2) wide-n-restrictions))
 
To this:
(setq wide-n-restrictions
      (delete (cons mrk1 mrk2) wide-n-restrictions))
 
Then load the file (with `delete'). Then:
 
In some buffer X, do `C-x n n', then `C-x n x'.
Check the value of variable `wide-n-restrictions'.
 
In another buffer Y, just check the value of the variable. You will see
that the default value, which should be `(all)', has been changed to be what the
new value is for buffer X.
 
Try the same thing again (starting from scratch), but using `remove' (the
original code) instead of `delete'. There is no problem now: only the
buffer-local value is ever set.

This doesn't seem right to me.
 
In GNU Emacs 23.1.95.1 (i386-mingw-nt5.1.2600)
 of 2010-04-03 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/imagesupport/include'

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Stefan Monnier]

> This doesn't seem right to me.
 
Why not?  That's the whole reason for the existence of two functions:
`delete' and `remove'.


        Stefan

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > This doesn't seem right to me.
>  
> Why not?  That's the whole reason for the existence of two functions:
> `delete' and `remove'.

I'm aware that `delete' modifies the list structure and `remove' uses a copy.
What I don't understand is the interaction with a default value instead of a
buffer-local value. Why would `delete' cause the behavior described?

The same code BTW uses `nconc' apparently without causing such
modify-the-default-value behavior:

(setq wide-n-restrictions
      (nconc (nthcdr arg wide-n-restrictions) latest))

What is the relation between `delete's modification of the list structure of a
cons that is a buffer-local value of a variable and its (apparent) modification
of the default value of the variable?

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Stefan Monnier]

>> > This doesn't seem right to me.
>> Why not?  That's the whole reason for the existence of two functions:
>> `delete' and `remove'.
> I'm aware that `delete' modifies the list structure and `remove' uses
> a copy.  What I don't understand is the interaction with a default
> value instead of a buffer-local value.  Why would `delete' cause the
> behavior described?

Why not?


        Stefan


PS: Closing this.  You can continue the discussion on gnu.emacs.help
(or even comp.lang.lisp, tho I never read that one and they're probably
not that familiar with buffer-local variables).

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

 

> -----Original Message-----
> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca] 
> Sent: Sunday, April 18, 2010 11:25 PM
> To: Drew Adams
> Subject: Re: bug#5971: 23.1.95; `delete' modifies default 
> value instead of buffer-local value
> 
> >> > This doesn't seem right to me.
> >>
> >> Why not?  That's the whole reason for the existence of two 
> >> functions: `delete' and `remove'.
> >
> > I'm aware that `delete' modifies the list structure and 
> > `remove' uses a copy.  What I don't understand is the
> > interaction with a default value instead of a buffer-local
> > value.  Why would `delete' cause the behavior described?
> 
> Why not?

Why? (You're not helping, just being evasive.) Why should modification of a
buffer-local value also modify the default value?

If this is not a product bug, it is at least a doc bug.

I can find nothing in the doc that mentions such behavior or would help one to
expect it or understand it. There is no explanation of any dependency between a
default value and buffer-local values, in the sense manifested. The only
explanation about buffer-local vars states that if a buffer-local value is not
yet set then the default value is used instead.

That does not explain why modification of a buffer-local value would affect also
the default value. The way the doc presents it, the two are conceptually
separate, including in terms of modification. There is nothing that I can see
that would lead one to expect that modification of a particular buffer-local
value would affect also the default value. This needs to be documented. It is
apparently an important way in which a buffer-local value is, well, not
buffer-local.

In the doc there are caveats about things like `let'-binding, but nothing is
said about this (arguably more serious or at least just as surprising)
bizarreness (er, design property).

Buffer-local variables are specific to Emacs Lisp (and other Lisps that have a
notion of editor buffers). Other, general Lisps do not have any notion of
buffer-local variables, so users of such Lisps who come to Emacs Lisp will not
have an understanding of this either. The Emacs Lisp doc needs to cover this
specific difference completely.

> PS: Closing this.  

Please reopen it - at least as a doc bug.

> You can continue the discussion on gnu.emacs.help
> (or even comp.lang.lisp, tho I never read that one and 
> they're probably not that familiar with buffer-local variables).

Precisely. Which is why this particular knot about buffer-local variables needs
to be documented in the Elisp manual. It is not, AFAICT.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Glenn Morris]

Please don't post to 3 different mailing lists.
You should never post to tracker@debbugs.
You should post to help-debbugs@gnu only to discuss the bug tracking
system.

Also, messages that are pure control messages should go to
control@debbugs only, not to the individual bug address as well.

If you have problems with this, help-debbugs is the place to discuss
such things.

Drew Adams wrote:

> To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>, <5971@debbugs.gnu.org>
> Cc: tracker@debbugs.gnu.org, 'GNU bug Tracking System' <help-debbugs@gnu.org>

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> Why? (You're not helping, just being evasive.) Why should modification of a
> buffer-local value also modify the default value?

delete works by side effect.  If you don't want this use remove.

> If this is not a product bug, it is at least a doc bug.

Delete by side effect any occurrences of ELT as a member of SEQ.
          ^^^^^^^^^^^

Pretty clear description.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > Why? (You're not helping, just being evasive.) Why should 
> > modification of a buffer-local value also modify the default value?
> 
> delete works by side effect.  If you don't want this use remove.
> 
> > If this is not a product bug, it is at least a doc bug.
> 
> Delete by side effect any occurrences of ELT as a member of SEQ.
>           ^^^^^^^^^^^
> Pretty clear description.

I'm well aware that `delete' deletes by side effect.
Please read the thread and that will be quite clear.

What's not clear is that a side effect on a buffer-local value should affect the
default value.

Nothing in the doc states that they share list structure. Apparently they do.
This relation between the two needs to be documented. From reading the doc there
is nothing that would lead you to expect that setting the buffer-local value
would ever change the default value.

The doc presents the two values (buffer-local and default) as being separate.
The only relation described between the two is that if the buffer-local value is
not set then the default value is used for the variable.

In this case, the buffer-local value is not set in buffer Y, so it uses the
default value. What's not clear is why setting the buffer-local value in buffer
X changed the default value (so it was used in buffer Y, where the b-l value was
not set).

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> Nothing in the doc states that they share list structure.

There is no buffer-local value before you set it.

The doc is pretty clear that a buffer-local value only starts to exist
the first time it is set:

Make VARIABLE become buffer-local whenever it is set.
At any time, the value for the current buffer is in effect,
unless the variable has never been set in this buffer,
in which case the default value is in effect.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > Nothing in the doc states that they share list structure.
> 
> There is no buffer-local value before you set it.

Yes, I know that. And I noted that explicitly.
 
> The doc is pretty clear that a buffer-local value only starts to exist
> the first time it is set:
> 
> Make VARIABLE become buffer-local whenever it is set.
> At any time, the value for the current buffer is in effect,
> unless the variable has never been set in this buffer,
> in which case the default value is in effect.
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes, and I explictly said that too. Please read what I wrote.

I am not questioning the fact that the default value is used if no buffer-local
value is set. And that behavior is adequately documented.

What is _not_ documented AFAICT is that using `delete' to set the buffer-local
value in buffer X also modifies the default value. There is no reason to expect
that, from reading the doc.

Once the default value has been modified, it is clear that buffer Y will (and
should) pick it up if you have not yet set a buffer-local value in Y. What is
not clear is why the _default_ value gets modified, just by setting the
_buffer-local_ value (in X).

And as I noted, using `nconc' (which is destructive like `delete') does not have
this effect. The same code uses `nconc' to set the buffer-local value in X, and
that does not also modify the default value.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > Nothing in the doc states that they share list structure.
>> 
>> There is no buffer-local value before you set it.
>
> Yes, I know that. And I noted that explicitly.

So you know that the default value is *the value you are modifying*.

>> The doc is pretty clear that a buffer-local value only starts to exist
>> the first time it is set:
>> 
>> Make VARIABLE become buffer-local whenever it is set.
>> At any time, the value for the current buffer is in effect,
>> unless the variable has never been set in this buffer,
>> in which case the default value is in effect.
>>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Yes, and I explictly said that too. Please read what I wrote.

Please read what I wrote.

> What is _not_ documented AFAICT is that using `delete' to set the buffer-local
> value in buffer X also modifies the default value. There is no reason to expect
> that, from reading the doc.

You are *not* modifying the buffer-local value, because *it does not
exist* yet.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> >> > Nothing in the doc states that they share list structure.
> >> 
> >> There is no buffer-local value before you set it.
> >
> > Yes, I know that. And I noted that explicitly.
> 
> So you know that the default value is *the value you are modifying*.

No, I do not know that. Where does it say that `setq' modifies the default
value?

If there is no buffer-local value, then the default value is used, yes. That
doesn't say anything about modifying or setting anything.

The modification of the default value was done in buffer X. It is buffer Y that
does not yet have a buffer local value. When modifying buffer X's value of the
var, I used `setq' with `delete'. I did not use `setq-default'.

I do not see any doc that would indicate that `setq' with `delete' should modify
the default value. On the contrary, everything seems to say that setting the var
using setq should set the buffer-local value (only).

> >> The doc is pretty clear that a buffer-local value only 
> >> starts to exist the first time it is set:
> >> 
> >> Make VARIABLE become buffer-local whenever it is set.
> >> At any time, the value for the current buffer is in effect,
> >> unless the variable has never been set in this buffer,
> >> in which case the default value is in effect.
> >>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Yes, and I explictly said that too. Please read what I wrote.
> 
> Please read what I wrote.

You just repeated what I acknowledged from the beginning: it is normal that if
no buffer-local value is set in buffer Y then the default value for the variable
is used (returned) in buffer Y.

That has nothing to do with the question at hand, which is how/why
modifying/setting the buffer-local value in buffer X also ends up
modifying/setting the default value. 

When, in buffer X, I use `setq' with `delete' I am destructively modifying the
_buffer-local_ value in X, not the default value.

Or at least that's what the doc says I am doing. The variable is declared with
`make-variable-buffer-local', which means that whenever it is set it is the
_buffer-local_ value that is set (unless I use, say, `setq-default').

> > What is _not_ documented AFAICT is that using `delete' to 
> > set the buffer-local value in buffer X also modifies the
> > default value. There is no reason to expect that, from reading the doc.
> 
> You are *not* modifying the buffer-local value, because *it does not
> exist* yet.

No, it does not yet exist when I set it (in buffer X). But it is a buffer-local
variable, declared using `make-variable-buffer-local'. And that means that
_whenever it is set_, it is the buffer-local value, _not_ the default value,
that is set.

,----
| make-variable-buffer-local is an interactive built-in function in `C
| source code'.
| 
| (make-variable-buffer-local VARIABLE)
| 
| Make VARIABLE become buffer-local whenever it is set.
| At any time, the value for the current buffer is in effect,
| unless the variable has never been set in this buffer,
| in which case the default value is in effect.
| Note that binding the variable with `let', or setting it while
| a `let'-style binding made in this buffer is in effect,
| does not make the variable buffer-local.  Return VARIABLE.
| 
| In most cases it is better to use `make-local-variable',
| which makes a variable local in just one buffer.
| 
| The function `default-value' gets the default value and `set-default' sets it.
`----

What part of "whenever it is set" is one of us not understanding?

Using `setq' to set the variable should set its _buffer-local_ value.

Yes, until you set the buffer-local value, it is the default value that is
returned for the variable. But "_whenever it is set_", it is the buffer-local
value that is set, _not_ the default value.

At least that's what the doc says.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> No, I do not know that. Where does it say that `setq' modifies the default
> value?

Stop being silly.  Which part of `by side effect' did you not
understand?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > No, I do not know that. Where does it say that `setq' 
> > modifies the default value?
> 
> Stop being silly.  Which part of `by side effect' did you not
> understand?

Stop with the name-calling.

The question is, side-effect/modification of what object? Apriori, the
buffer-local value and the default value are separate Lisp objects.

If there is _no_ buffer-local value, then the default value is returned for the
var. But that does not mean that the buffer-local and default values are the
same. It means only that the variable has _no_ b-l value, so the default value
is used. And if the variable is set in the buffer, then it is _only_ the
buffer-local value that is set. That is the only thing the doc indicates. 

According to the doc, anytime the variable is set, it is the buffer-local value
(only) that is set. There is nothing in the doc that suggests that the
buffer-local value and the default value share the same Lisp object. On the
contrary, the impression given is that they are separate objects.

The only relation between them that is described is that one of them (default
value) is used as the var value if the other (b-l value) is not yet set. That
does not imply that they share memory in any way.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> If there is _no_ buffer-local value, then the default value is returned for the
> var.

Exactly.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > If there is _no_ buffer-local value, then the default value 
> > is returned for the var.
> 
> Exactly.

OK, I get it.

The problem was that the defvar defined a default value that was a particular
cons cell. Then, I set the buffer-local value to (a modification of) that list
structure, since the initial value returned by the variable was the default one.
IOW, in the setq, it was the right-hand side, where the variable's value was
used, that was the problem.

Before closing the bug, please consider adding something to the doc that might
make this gotcha clearer. Perhaps something like this:

Although `make-variable-buffer-local' makes its argument variable become buffer
local whenever it is set, any references to the variable before it is set return
its default value. That includes any occurrences of the variable in an
expression used to calculate the new, buffer-local value.

Thanks.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Kevin Rodgers]

Drew Adams wrote:
>>> If there is _no_ buffer-local value, then the default value 
>>> is returned for the var.
>> Exactly.
> 
> OK, I get it.
> 
> The problem was that the defvar defined a default value that was a particular
> cons cell. Then, I set the buffer-local value to (a modification of) that list
> structure, since the initial value returned by the variable was the default one.
> IOW, in the setq, it was the right-hand side, where the variable's value was
> used, that was the problem.
> 
> Before closing the bug, please consider adding something to the doc that might
> make this gotcha clearer. Perhaps something like this:
> 
> Although `make-variable-buffer-local' makes its argument variable become buffer
> local whenever it is set, any references to the variable before it is set return
> its default value. That includes any occurrences of the variable in an
> expression used to calculate the new, buffer-local value.

That is implied by the fact that make-variable-buffer-local is a function (vs.
macro vs. special form): its argument forms are evaluated before being passed
to the function by eval.

-- 
Kevin Rodgers
Denver, Colorado, USA

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Drew Adams]

> > Before closing the bug, please consider adding something to 
> > the doc that might make this gotcha clearer. Perhaps something
> > like this:
> > 
> > Although `make-variable-buffer-local' makes its argument 
> > variable become buffer local whenever it is set, any
> > references to the variable before it is set return
> > its default value. That includes any occurrences of the 
> > variable in an expression used to calculate the new,
> > buffer-local value.
> 
> That is implied by the fact that make-variable-buffer-local 
> is a function (vs. macro vs. special form): its argument
> forms are evaluated before being passed to the function by eval.

Yeah, I know. And I shoulda known better. I didn't pay attention to the fact
that I had a defvar that set the default value to a cons cell - originally it
was nil (as it is again now). Still, it might help if we said something more
(admittedly different from what I suggested), to help users avoid such problems
destructively modifying the default value.

bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value

[Glenn Morris]

I don't see a need to keep open this particular report, which was marked
"wontfix" some time ago.

bug#5971: - reopen

[Drew Adams]

reopen 5971

thanks