bug#13699: 24.2.93; multiple defcustoms for one variable

bug#13699: 24.2.93; multiple defcustoms for one variable

[Roland Winkler]

start emacs -Q
load the following two files (first bar.el, then baz.el)

cat > bar.el <<EOF
(defcustom foo 'bar
  "This is bar.el.")
EOF

cat > baz.el <<EOF
(defcustom foo 'baz
  "This is baz.el.")
EOF

Expected result:
Either loading baz.el overrides completely loading bar.el,
so that C-h v foo reflects baz.el only.
Or emacs "remembers" bar.el so that C-h foo indicates the fact that
foo was first defined in bar.el and foo kept its value defined there.

Actual result:
C-h v foo says

  foo is a variable defined in `baz.el'.
  Its value is bar
  Original value was baz
  
  Documentation:
  This is baz.el.

The actual value of foo is the original value from bar.el,
but "Original value was baz" denies the fact that this value
stems from bar.el.

I noticed this problem with the variable mail-signature which
sendmail.el initializes with a value of t. But my old version of vm
also initialized it with a value of nil. With sendmail.el being
loaded before vm, I got the value of t, but it took me a little
while to figure out how this value came about.

I suggest that multiple calls of defcustom appearing for the same
variable in different files should be handled consistently so that
it becomes possible to trace back how the value of the variable
came about.


In GNU Emacs 24.2.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2013-02-08 on lukas
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
System Description:	Ubuntu 8.04.4 LTS

bug#13699: 24.2.93; multiple defcustoms for one variable

[Glenn Morris]

"Roland Winkler" wrote:

> The actual value of foo is the original value from bar.el,
> but "Original value was baz" denies the fact that this value
> stems from bar.el.

Similar thing with defvar.

> I noticed this problem with the variable mail-signature which
> sendmail.el initializes with a value of t. But my old version of vm
> also initialized it with a value of nil.

That's just a bug in that version of VM.

> I suggest that multiple calls of defcustom appearing for the same
> variable in different files should be handled consistently so that
> it becomes possible to trace back how the value of the variable
> came about.

Multiple defcustoms (or defvars) for the same variable are bugs, so it
is unlikely to be a high priority to improve their treatment.

bug#13699: 24.2.93; multiple defcustoms for one variable

[Roland Winkler]

On Tue Feb 12 2013 Glenn Morris wrote:
> Multiple defcustoms (or defvars) for the same variable are bugs,

Sure! -- But debugging such a situation is currently more difficult
than it could be. That's really the point I wanted to make.

> so it is unlikely to be a high priority to improve their
> treatment.

bug#13699: 24.2.93; multiple defcustoms for one variable

[Glenn Morris]

"Roland Winkler" wrote:

> On Tue Feb 12 2013 Glenn Morris wrote:
>> Multiple defcustoms (or defvars) for the same variable are bugs,
>
> Sure! -- But debugging such a situation is currently more difficult
> than it could be. That's really the point I wanted to make.

It is many, many times more likely that a package will mistakenly change
the value of a variable with setq than with defcustom.