bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value
Date: Mon, 19 Apr 2010 11:58:07 -0700

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]