From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16434: bug#16694: bugs #16694/#16378: Patches Date: Wed, 23 Apr 2014 18:51:37 +0300 Message-ID: <83zjjc82nq.fsf@gnu.org> References: <52F601AE.5040309@binary-island.eu> <87k3bj40nu.fsf@cougar.home.aneadesign.com> <83wqfiz36v.fsf@gnu.org> <5331D45B.7090704@binary-island.eu> <5335920F.4030008@binary-island.eu> <533C26F3.4040600@binary-island.eu> <83lhvk8b6x.fsf@gnu.org> <83a9bz92h2.fsf@gnu.org> <534517A5.1070306@binary-island.eu> <53492567.4090303@binary-island.eu> <83zjjqsjn7.fsf@gnu.org> <5349546A.4040500@binary-island.eu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1398268343 10602 80.91.229.3 (23 Apr 2014 15:52:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2014 15:52:23 +0000 (UTC) Cc: gundaetiapo@gmail.com, 16434@debbugs.gnu.org To: Matthias Dahl Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 23 17:52:15 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WczT5-00017V-0B for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Apr 2014 17:52:15 +0200 Original-Received: from localhost ([::1]:33455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WczT4-00037t-H6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Apr 2014 11:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WczSx-00037o-KV for bug-gnu-emacs@gnu.org; Wed, 23 Apr 2014 11:52:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WczSt-0000nq-1a for bug-gnu-emacs@gnu.org; Wed, 23 Apr 2014 11:52:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WczSs-0000nl-Tv for bug-gnu-emacs@gnu.org; Wed, 23 Apr 2014 11:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WczSs-0000n1-IP for bug-gnu-emacs@gnu.org; Wed, 23 Apr 2014 11:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Apr 2014 15:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16434 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16434-submit@debbugs.gnu.org id=B16434.13982683063003 (code B ref 16434); Wed, 23 Apr 2014 15:52:02 +0000 Original-Received: (at 16434) by debbugs.gnu.org; 23 Apr 2014 15:51:46 +0000 Original-Received: from localhost ([127.0.0.1]:56307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WczSc-0000mM-7M for submit@debbugs.gnu.org; Wed, 23 Apr 2014 11:51:46 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:37921) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WczSZ-0000mB-IX for 16434@debbugs.gnu.org; Wed, 23 Apr 2014 11:51:44 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N4H00D00QBVMF00@a-mtaout21.012.net.il> for 16434@debbugs.gnu.org; Wed, 23 Apr 2014 18:51:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N4H00D3AQQ5JN50@a-mtaout21.012.net.il>; Wed, 23 Apr 2014 18:51:41 +0300 (IDT) In-reply-to: <5349546A.4040500@binary-island.eu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88257 Archived-At: > Date: Sat, 12 Apr 2014 16:57:46 +0200 > From: Matthias Dahl > Cc: 16434-done@debbugs.gnu.org, gundaetiapo@gmail.com, monnier@IRO.UMontreal.CA, > 16378-done@debbugs.gnu.org, cs.mlists+bug-gnu-emacs@mailbox.org, > 16694-done@debbugs.gnu.org > > Hello Eli... > > > Done. > > Thanks. I'm sorry, but now I see that the fix of this bug caused an adverse side effect: face attributes that are defined in the X resources are now overridden by the face defaults. At least that's what happens on MS-Windows, where we simulate the X resources in w32reg.c. Specifically, in Emacs 24.3, the tool bar has its foreground and background colors set to SystemButtonText and SystemButtonFace, accordingly, as specified in SYSTEM_DEFAULT_RESOURCES defined by w32reg.c. By contrast, in the current pretest, this face has the default foreground and background colors defined by faces.el: (defface tool-bar '((default :box (:line-width 1 :style released-button) :foreground "black") <<<<<<<<<<<<<<<<<<<<<<<<<< (((type x w32 ns) (class color)) :background "grey75") <<<<<<<<<<<<<<<<<<<<<<<<<< This is clearly seen if one tries to customize this face in an Emacs that was started without -Q. I looked at the code, and it seems that the problem is in face-spec-recalc, and the doc string explicitly says that it is the intended behavior: (defun face-spec-recalc (face frame) "Reset the face attributes of FACE on FRAME according to its specs. After the reset, the specs are applied from the following sources in this order: X resources (if applicable) | (theme and user customization) or, if nonexistent or does not match the current frame, (defface default spec) | defface override spec" The code indeed follows the doc string: it first resets the face, then applies the X resources, and then applies either the theme or the default face spec: (face-spec-reset-face face frame) (make-face-x-resource-internal face frame) ;; If FACE is customized or themed, set the custom spec from ;; `theme-face' records. (let ((theme-faces (get face 'theme-face)) (no-match-found 0) spec theme-face-applied) (if theme-faces (dolist (elt (reverse theme-faces)) (setq spec (face-spec-choose (cadr elt) frame no-match-found)) (unless (eq spec no-match-found) (face-spec-set-2 face frame spec) (setq theme-face-applied t)))) ;; If there was a spec applicable to FRAME, that overrides the ;; defface spec entirely (rather than inheriting from it). If ;; there was no spec applicable to FRAME, apply the defface spec. (unless theme-face-applied (setq spec (face-spec-choose (face-default-spec face) frame)) (face-spec-set-2 face frame spec)) (setq spec (face-spec-choose (get face 'face-override-spec) frame)) (face-spec-set-2 face frame spec))) What happens on Windows is that make-face-x-resource-internal indeed picks up the colors specified bu w32reg.c, but then face-spec-set-2 resets the colors to what the defface spec says. Can you or someone else see if setting the colors of the tool-bar face in the X resources on Unix is similarly overridden? I don't understand this logic: resources are a kind of customization, so they should override the default face spec, not the other way around. Am I missing something? This change was done because --reverse-video didn't work, but what does --reverse-video have to do with X resources and their priority in determining the face attributes? Thanks.