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#19217: 25.0.50; `C-M-x' (`eval-defun') on a `defface' that is not top-level Date: Sun, 30 Nov 2014 16:00:09 -0800 (PST) Message-ID: References: <20141129191023.34112.qmail@mail.muc.de> <3e0d66d6-99b6-4e0d-a1eb-b7f2e3731ea7@default> <20141130195811.GB12974@acm.acm> <6718ace6-b672-40fc-a5bc-ea29eb155239@default> <20141130232003.GC12974@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1417392093 22354 80.91.229.3 (1 Dec 2014 00:01:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 00:01:33 +0000 (UTC) Cc: 19217@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 01 01:01:23 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 1XvEQd-0007Q6-I5 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Dec 2014 01:01:23 +0100 Original-Received: from localhost ([::1]:52216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEQd-0003iP-8T for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Nov 2014 19:01:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEQR-0003iG-MA for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 19:01:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvEQI-0007g9-Uc for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 19:01:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEQI-0007g5-Qo for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 19:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XvEQI-0003mS-8z for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 19:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Dec 2014 00:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19217 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19217-submit@debbugs.gnu.org id=B19217.141739202214409 (code B ref 19217); Mon, 01 Dec 2014 00:01:02 +0000 Original-Received: (at 19217) by debbugs.gnu.org; 1 Dec 2014 00:00:22 +0000 Original-Received: from localhost ([127.0.0.1]:50227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvEPd-0003kK-Iv for submit@debbugs.gnu.org; Sun, 30 Nov 2014 19:00:22 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:23362) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvEPb-0003k2-G8 for 19217@debbugs.gnu.org; Sun, 30 Nov 2014 19:00:20 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB100Gx0020140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Dec 2014 00:00:18 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB100FR0005524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2014 00:00:16 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sB100ERt020880; Mon, 1 Dec 2014 00:00:14 GMT In-Reply-To: <20141130232003.GC12974@acm.acm> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:96770 Archived-At: > Ah. Yes, `defface' is like `defvar', in that if you defface a face > twice, the second try does not overwrite the first. `defvar' too should be fixed, for the same cases & reasons. There is no user-oriented reason that `C-M-x' should not re-evaluate the sexp, redefining the variable or the face. There can be implementation reasons (too hard to do, or whatever), but I see no user reason. And wrt the implementation, I see no reason why TRT cannot be done, at least for common, simple use cases (e.g., point on the symbol being redefined). > So I now see what you're complaining about, and I think would too, > if I were doing anything at all with faces. > ... use C-M-x. And for the latter, you need the opening paren > at top level. 1. That evaluates more than the defface inside that opening paren. E.g., in the test case I gave, the opening top-level paren is for (when... ). 2. Even if that did the right thing, which does not (see #1), it is far too restrictive - far more restrictive than it needs to be. See what I wrote above. > If I were you, I'd hack something together for > my own use based on what's in lisp-mode.el. ... > You could probably fix this with a bit of advice (whether > old-style or new-style ;-). Thanks for the advice, but I prefer to file this bug report and hope that Emacs gets fixed. I've lived with it this way for decades already. It is for Emacs, not for me, that I file the bug report. > > (2) `C-M-x' with point inside a defface sexp should also work. > > If the latter cannot easily be made to work with point anywhere > > inside the sexp, then at least make it work with point on > `defface' > > or near it (e.g. at the same list level). >=20 > > > That `defface' be made a special case, >=20 > > If that's necessary, yes. It should be made to work, whether that > > means special-casing it or not. >=20 > Given how much of a special case faces already are, in terms of > awkwardness and inflexibility, maybe that's not too much to ask for. > But beware of what you're asking for - you might get it. Then > when you do C-M-x, expecting to evaluate a defun, you accidentally > get a face defined instead, which you then can't get rid of. Why can't I "get rid of it"? Anyway, I can live with `C-M-x' redefining the stuff I use it on. I will expect it to do that. If I don't want to do that then I can use `eval-region' or similar, which perform normal load-like evaluation. > > > I'm not sure how you're going to construe "closer", given that a > > > list typically extends over many characters and when point is > > > within it, that must count as distance zero. Or something. >=20 > > It's trivial to determine whether point is at the same list level > > as the `defface' symbol. >=20 > That would indeed be one way of doing it. Thanks for taking a look, in any case. Should someone decide to fix this bug, it might be good to (a) take a user poll and (b) provide a way (e.g. a user option) to return to the previous (i.e., current), lame behavior for those who prefer it.