From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: pp-eval-expression broken Date: Tue, 9 Jan 2007 14:56:40 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1168383514 4324 80.91.229.12 (9 Jan 2007 22:58:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Jan 2007 22:58:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 09 23:58:33 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H4PvK-0002cn-8P for ged-emacs-devel@m.gmane.org; Tue, 09 Jan 2007 23:58:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H4PvJ-0008PA-T0 for ged-emacs-devel@m.gmane.org; Tue, 09 Jan 2007 17:58:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H4Pv1-0008Nu-Qc for emacs-devel@gnu.org; Tue, 09 Jan 2007 17:58:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H4Puy-0008JQ-Mj for emacs-devel@gnu.org; Tue, 09 Jan 2007 17:58:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H4Puy-0008JC-FM for emacs-devel@gnu.org; Tue, 09 Jan 2007 17:58:08 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1H4Puw-0001N0-EV; Tue, 09 Jan 2007 17:58:06 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l09Mw3UK017942; Tue, 9 Jan 2007 16:58:04 -0600 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l09MfXvD026267; Tue, 9 Jan 2007 15:58:03 -0700 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-141.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 2349727191168383405; Tue, 09 Jan 2007 15:56:45 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:65086 Archived-At: > That's what I do in my own redefined `pp-eval-expression'. > But I don't use > (interactive "X") or (interactive "x"). I just use this: > > (interactive > (list (read-from-minibuffer "Eval: " nil read-expression-map t > 'read-expression-history)) > > Is there a problem with using that? > > That seems ok. Does that mean that you will reverse the change to `pp-last-sexp' that evals its arg before calling `pp-eval-expression', and let `pp-eval-expression' always eval its arg? I hope so. Otherwise, I see a problem in having the Lisp behavior of `pp-eval-expression' (no evaluation of its argument) be different from its interactive behavior (arg evaluation). The problem is worse than I thought. I thought that I could get by with just this tweak in my own definition of `pp-eval-expression': (interactive (list (read-from-minibuffer "Eval: " nil read-expression-map t 'read-expression-history))) (unless (and (not (interactive-p)) (> emacs-major-version 21)) (setq expression (eval expression))) However, although that works for Lisp functions, such as `pp-eval-last-sexp', written with the new, Emacs-22 interface in mind, and it works OK interactively, it fails for `repeat-complex-command' in Emacs 22, because that re-evaluates an interactive call as a Lisp sexp. It causes `repeat-complex-command' following `pp-eval-expression' not to evaluate the expression at all. I really think the best approach is to return to the pre-Emacs 22 behavior of `pp-eval-expression' always evaluating its argument and `pp-eval-last-sexp' not evaluating the sexp before it passes it to `pp-eval-expression'.