Re: [sumner@graphics.lcs.mit.edu] Faces wrong when opening new frame (PR#1465)
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
No, not at all. I presented an example in which the procedure as
written is _designed_ to destroy useful data. In this case it happens
not to be the user's customization; it happens that the user would
like to experiment with somebody else's configuration without
restarting Emacs. It's still useful data, and I still see no excuse
for destroying it. If it were garbage, it would get collected. But
it's not.
Yes, that code is designed to destroy data. But destroyed
data is not user's data. It's custom's own setting. (If
defface is called before first frame is initialized, Custom
picks up wrong faces.)
>>>> It is called only before .emacs (or
.xemacs/init.el) is
>>>> loaded and never called again.
So? pdump_load is called before _anything_ is loaded and it still
managed to destroy user data (namely, command line option settings).
That was a design bug, too.
But command line option is supplied before pdump_load and
was processed before it, right? If user data is supplied
before startup-initialize-custom-faces and is destroyed by
it, it is a bug. If there's a bug, I'm willing to fix it.
Yoshiki> If you were referring to face-spec-reset function I
Yoshiki> wholeheartedly agree. But I don't understand why you
Yoshiki> ignore context and add random remarks.
Because I'm not capable of fixing this particular bug; only suggesting
a work-around that you say is irrelevant. What I am primarily
concerned about is the future bugs that Custom is 99.44% sure to
introduce due to its habit of destroying data without requesting
confirmation from the user.
True custom-set-face-update-spec and the like destroy user
data. But mere new frame opening doesn't call those
functions. I'm insisting that user data is not destroyed in
this case, it's just frame-background-mode bug. If you
still think user data is destroyed in this case, you can
debug-on-entry reset-face and make a new frame.
--
Yoshiki Hayashi