From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Inspecting functions returning complicated values Date: Wed, 1 Oct 2014 20:06:42 -0700 (PDT) Message-ID: <5f66e73a-7651-4e55-af67-b23f7de758c5@default> References: <87lhp0hd9m.fsf@wmi.amu.edu.pl> <871tqrmhp7.fsf@debian.uxu> 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 1412219242 20695 80.91.229.3 (2 Oct 2014 03:07:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 03:07:22 +0000 (UTC) To: Emanuel Berg , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Oct 02 05:07:15 2014 Return-path: Envelope-to: geh-help-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 1XZWjb-0003sY-4u for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Oct 2014 05:07:15 +0200 Original-Received: from localhost ([::1]:59792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZWja-000550-NN for geh-help-gnu-emacs@m.gmane.org; Wed, 01 Oct 2014 23:07:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZWjH-000544-R4 for help-gnu-emacs@gnu.org; Wed, 01 Oct 2014 23:07:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZWj9-0003lh-2q for help-gnu-emacs@gnu.org; Wed, 01 Oct 2014 23:06:55 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZWj8-0003lJ-TB for help-gnu-emacs@gnu.org; Wed, 01 Oct 2014 23:06:47 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9236jCg008499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Oct 2014 03:06:46 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s9236hPh005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 03:06:44 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9236hBs024305; Thu, 2 Oct 2014 03:06:43 GMT In-Reply-To: <871tqrmhp7.fsf@debian.uxu> 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: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100222 Archived-At: > > M-x pp-eval-expression >=20 > What improvement is that? > (message "hello") > (eval-expression (message "hello")) > (pp-eval-expression (message "hello")) >=20 > Here, the first two seem to do the same, namely put it > in the echo area for inspection and then you can use > `C-h e'. pp-eval-expression also puts it in *Messages* > but doesn't echo it what I can see. Maybe it's because you don't know what you're doing? Maybe you didn't read the doc for `pp-eval-expression'? Hard to guess. Just what are you trying to accomplish? `pp-eval-expression' is a function. As such, it evaluates its argument. What does the doc string tell us it does with its argument? Evaluate EXPRESSION and pretty-print its value. Also add the value to the front of the list in the variable `values'. So let's see what you did. Somehow, you evaluated the sexp `(pp-eval-expression (message "hello"))'. Perhaps you used `C-x C-e', or maybe `M-:', to do that? However you did it, that evaluates the sexp `(message "hello")' and passes the resulting value to function `pp-eval-expression'. That resulting value is the string "hello". So what does `pp-eval-expression' then do with its argument, "hello"? It evaluates it! And then it pretty-prints the result of that evaluation. "hello" evaluates to "hello". OK, whatever. Since the pretty-printed representation of string "hello" is "hello", `pp-eval-expression' prints "hello" in the echo area. End of story...almost. And then, depending on how you evaluated `(pp-eval-expression (message "hello"))', you might see the value of _that_ sexp echoed (in the echo area). What is that value? `nil'. `pp-eval-expression' is used for its side effect, not its value. Why do `C-x C-e' and `M-:' print the value of the sexp they evaluate? Ask them. But it is generally handy that they do. So in the echo area, and in `*Messages*', two things are printed: a pretty-print of the string "hello", followed by `nil'. In addition, you have access to the result of evaluating the argument sexp (the string "hello"), which is "hello", as the car of global variable `values': `C-h v values' or `M-: (car values)'. Now what was it that you _wanted_ to do? Typically, one uses `pp-eval-expression' to (1) evaluate an expression and then (2) pretty-print the result of evaluation. Because it wants to evaluate an expression argument, you need to pass it an expression, and `pp-eval-expression' of course evaluates its argument first, before the function body executes. (It is not a macro or a special form.) So a typical use of `pp-eval-expression' would be something like `(pp-eval-expression 'ctl-x-map)' or `(pp-eval-expression '(nth 2 (nth 2 font-lock-keywords)))', and the result of pretty-printing would look something like this: (keymap #^[nil nil keymap =09#^^[3 0 pop-global-mark nil list-buffers save-buffers-kill-terminal list= -directory eval-last-sexp find-file nil nil indent-rigidly nil kmacro-keyma= p downcase-region =09 (keymap =09 (108 . set-language-environment) =09 (99 . universal-coding-system-argument) ... or this: (2 (let ((type (get =09(intern-soft =09 (match-string 1)) =09'lisp-define-type))) (cond ((eq type 'var) font-lock-variable-name-face) ((eq type 'type) font-lock-type-face) (t font-lock-function-name-face))) nil t) The first of these is the same kind of representation you see if you use `C-h v ctl-x-map'. Why? Because... `describe-variable' uses function `pp', just like `pp-eval-expression' does. But again, depending on how you evaluate the `pp-eval-expression' sexp, you might be fooled. If you evaluate it interactively then you might be fooled by the _command_ that you use to evaluate it. Using `M-:' or `C-x C-e' (without a prefix arg) prints the value of the evaluated `pp-eval-expression' sexp, right after `pp-eval-expression' prints the value of its argument expression. The hand is quicker than the eye. But lo and behold, `pp-eval-expression' is a command! And that means you can execute it using `M-x' or bind it to a key. What happens then? M-x pp-eval-expression RET Eval: (nth 2 (nth 2 font-lock-keywords)) RET And the pretty-printed value is shown in buffer `*Pp Eval Output*'. And a message tells you "See buffer *Pp Eval Output*." (That message should not end in a period, but let's not nitpick.) But wait, how come we didn't need to quote the expression? Because interactively `pp-eval-expression' uses `read--expression', and that, well,...reads an expression. In this case there is no need to evaluate something to provide `pp-eval-expression' with its expression argument. > But I agree with the other posters, IELM, with (ielm) > is the best way to do this. Good to know. To do what?