From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13278: 24.3.50; Attributes aren't inherited in a copied face across frames Date: Sun, 30 Dec 2012 19:14:14 -0800 Message-ID: <17D206CE44214D93B9FCF8C1623F8C83@us.oracle.com> References: <87623kjkpo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1356923719 11683 80.91.229.3 (31 Dec 2012 03:15:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 03:15:19 +0000 (UTC) Cc: 13278@debbugs.gnu.org To: "'Katsumi Yamaoka'" , "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 31 04:15:34 2012 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 1TpVqb-0001Rr-CL for geb-bug-gnu-emacs@m.gmane.org; Mon, 31 Dec 2012 04:15:29 +0100 Original-Received: from localhost ([::1]:33228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpVqM-0002cz-6w for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Dec 2012 22:15:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpVqI-0002cr-6d for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 22:15:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TpVqG-0001yk-Pl for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 22:15:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpVqF-0001yB-Vp for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 22:15:08 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TpVr7-0006dK-Rk for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 22:16:12 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Dec 2012 03:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13278 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13278-submit@debbugs.gnu.org id=B13278.135692373925471 (code B ref 13278); Mon, 31 Dec 2012 03:16:01 +0000 Original-Received: (at 13278) by debbugs.gnu.org; 31 Dec 2012 03:15:39 +0000 Original-Received: from localhost ([127.0.0.1]:37484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TpVql-0006cl-1S for submit@debbugs.gnu.org; Sun, 30 Dec 2012 22:15:39 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18155) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TpVqh-0006cX-8z for 13278@debbugs.gnu.org; Sun, 30 Dec 2012 22:15:37 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBV3EQ7q014432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Dec 2012 03:14:27 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBV3EPjG022626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Dec 2012 03:14:25 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBV3EPe3003873; Sun, 30 Dec 2012 21:14:25 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Dec 2012 19:14:24 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3m7CpNJH1mY3wTTkqHBEUt4vTfbgADp87w X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:69219 Archived-At: >> May I ask why you are trying to use `copy-face' instead of `defface'? May I ask why `copy-face' is now considered "mostly intended for internal usage"? Why does it no longer result in a customizable face (according to the doc)? And is that really true? In what way and by what scenarios? > I've been using it conveniently since the face feature was introduced > in Emacs. For example, it's handy when I want a face of which only > the color differs from the built-in one: > > (copy-face 'bold 'orange-bold) > (set-face-foreground 'orange-bold "Orange") > > Of course doing it by defface is not so troublesome, so I can live > without copy-face. > > > As the docstring of `copy-face' indicates, it is mostly intended for > > internal usage, > > Oh, I didn't notice the docstring having changed recently. I must > close this thread. Thanks anyway. > > > and you are likely to screw up the face's customization > > data if you call it directly. If you give more details about the > > use-case, that would be good. Too bad. `copy-face' was intended for users to use, before someone decided otherwise and to deem it "mostly intended for internal usage". Internal use was not what `copy-face' was "mostly intended for" originally. The doc string is the same in Emacs 23, 22, 21, and 20, and no doubt prior too. It invites users to use `copy-face'. And the only change I see for Emacs 24 is that you added this: This function does not copy face customization data, so NEW-FACE will not be made customizable. Most Lisp code should not call this function; use `defface' with :inherit instead. That was NOT true before Emacs 24 - faces created by `copy-face' WERE customizable. What did users gain by this change? Or was it just a net loss? And why tell users to use :inherit here? That is something completely different. A copy does not at all inherit from its source - that's the whole idea of a copy, and the idea behind `copy-face'. Searching for some explanation of this mystery change, I naturally looked in NEWS. I don't find anything there about any change to `copy-face' behavior or usage guidelines. Searching for `face' turns up nothing about this. Why isn't this change documented? FWIW, I have a fair amount of code that uses `copy-face'. Much of it is in commands that first copy a face to serve as a backup before the command lets a user change different attributes of the face incrementally. A user needs to be able to undo all of the resulting changes, which is why such commands back up the face to be modified, using `copy-face'. I presume & hope that such code is not now broken. `copy-face' is still used in the Emacs Lisp sources, so I'm guessing that a use such as this will still work. I also do simple things like this, for my own use: (copy-face 'secondary-selection 'query-replace) In fact, I don't understand why the doc string says that the result is not customizable - it sure seems to be in the cases I've tried. If you are going to say things like that then please be specific: Just what about customization is lost, and under what circumstances? What does not work wrt customization anymore? And why should "most Lisp code" not call `copy-face'? What kind of Lisp code can reasonably call it? Please be specific about the problems or limitations. Even "internal" Lisp programmers deserve to know what this is about. This is Emacs, the "extensible, customizable, self-documenting real-time display editor". It is not enough to say "don't use this - off limits". Please tell users why, in detail: what happens if they do use it? Under what circumstances does `copy-face' break face customizability? In what way is it broken? This bug report points to one area where `copy-face' apparently no longer works correctly. But that way doesn't seem to be about the new face not being customizable. It would be good for the doc to be clear about just what works and what doesn't, especially since the breakage is apparently new. And of course the change belongs in NEWS as well. Do you want me to file a separate bug for this doc problem, or to reopen this one until it is fixed?