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 12:51:59 -0800 (PST) Message-ID: <6718ace6-b672-40fc-a5bc-ea29eb155239@default> References: <20141129191023.34112.qmail@mail.muc.de> <3e0d66d6-99b6-4e0d-a1eb-b7f2e3731ea7@default> <20141130195811.GB12974@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 1417380810 17816 80.91.229.3 (30 Nov 2014 20:53:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2014 20:53:30 +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 Sun Nov 30 21:53: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 1XvBUh-0004A7-1u for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Nov 2014 21:53:23 +0100 Original-Received: from localhost ([::1]:51744 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvBUg-0001rt-K8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Nov 2014 15:53:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvBUV-0001rj-3V for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 15:53:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvBUM-0002VB-9v for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 15:53:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvBUM-0002V0-6Q for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 15:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XvBUL-00066x-Mk for bug-gnu-emacs@gnu.org; Sun, 30 Nov 2014 15:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Nov 2014 20:53:01 +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.141738073123430 (code B ref 19217); Sun, 30 Nov 2014 20:53:01 +0000 Original-Received: (at 19217) by debbugs.gnu.org; 30 Nov 2014 20:52:11 +0000 Original-Received: from localhost ([127.0.0.1]:50179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvBTX-00065p-8H for submit@debbugs.gnu.org; Sun, 30 Nov 2014 15:52:11 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43829) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvBTU-00065g-Nb for 19217@debbugs.gnu.org; Sun, 30 Nov 2014 15:52:09 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAUKq6Y7029386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Nov 2014 20:52:07 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAUKq50Y028671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Nov 2014 20:52:06 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAUKq55O017457; Sun, 30 Nov 2014 20:52:05 GMT In-Reply-To: <20141130195811.GB12974@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: acsinet21.oracle.com [141.146.126.237] 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:96766 Archived-At: > > > You can also move point to just after the closing ) and do C-x > > > C-e (`eval-last-sexp'). >=20 > > I too thought that was the case, but it does not seem to be. I > > just tried it, starting with emacs -Q in several Emacs versions > > (22, 24.4, 25 dev build). >=20 > I've never had a problem with C-x C-e that I can remember, and that > includes several times with point after a random ) inside a defun. > What happens when you do C-x C-e with point just after the `defface' > form? As I said, nothing happens. emacs -Q Put this in *scratch*, and evaluate it: (when t (defface foo '((((background dark)) (:foreground "#58DFFA4FFFFF")) (t (:foreground "Firebrick"))) "A face." :group 'help) ) `M-x customize-face' shows that it is defined as it should be. Edit the definition, replacing "Firebrick" with "Blue". Put point just after the defface sexp and hit `C-x C-e'. `M-x customize-face' shows that no change was made. Feel free to blow away the Customize buffer completely, so you are sure that you're not just seeing what was there before. ;-) Edit the color to "Green". Put point on the symbol `defface' and hit `C-M-x' - likewise, still no change to the face. > > > > How about letting users redefine a `defface' with `C-M-x' even > > > > in this case? >=20 > > > How is Emacs to determine which depth of parenthesis is to be > > > considered the opening one? For example, if a defface is > > > contained within a defmacro, which one is to be executed on C-M-x? >=20 > > I really don't care about corner cases, if in fact there are any. >=20 > What exactly are you suggesting? See above. (1) `C-x C-e' should work as you say it works. (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). > That `defface' be made a special case, If that's necessary, yes. It should be made to work, whether that means special-casing it or not. Currently, `C-M-x' inside a defun that is not at top level does not have the problem that defface has. Repeat the above recipe, but with (defun toto () "Toto." (forward-char)) in place of the defface sexp. Edit it after evalling, to use `backward-char', and use `C-M-x' again. Check the definition before and after editing, using (symbol-function 'toto). No problem. Not so, for defface. > and that if any of the sequence of enclosing (s opens a `defface' > form, this should be the one chosen for execution? Or should any > defining function count? What is special about `defface'? No idea what you are going on about; sorry. > > You could even require that point be on the symbol `defface' in > > the sexp, for all I care. Then it should be trivial to grab the > > `defface' sexp (e.g., use `(list-at-point)'). >=20 > > The point is to have some way to reevaluate the defface sexp. If > > `C-x C-e' worked, that would be enough, but AFAICT it does not > > work. >=20 > What happens when you try it? See above. 100% reproducible from emacs -Q. What happens when you try it? ;-) > > > > Is there a good reason for doing this only at top-level? >=20 > > > I think it is to make it unambiguous, which form is to be > > > evaluated. >=20 > > Dunno how `C-x C-e' could be ambiguous wrt the sexp that precedes > > point. If the sexp preceding point is ambiguous then I think > > we're probably in a world of trouble. ;-) >=20 > Neither C-M-x not C-x C-e are ambiguous. The first evaluates the > top level form containing point, the second the sexp immediately > preceding point. They should. But they do not, in the case of defface. See above. Try it. > > Coming back to `C-M-x': Then don't seek perfection. Require that > > point be closer to the list enclosing `defface' than to another > > list when you try `C-M-x', in order for it to unambiguously pick > > up the right sexp. >=20 > 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. It's trivial to determine whether point is at the same list level as the `defface' symbol. > > What am I missing? >=20 > A detailed clear specification of what you want. I don't think I'm (or you are) missing that. Have you tried it?