GNU bug report logs - #135
eval-defun binds print-level during eval

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 135 in the body.
You can then email your comments to 135 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: emacs-devel <at> gnu.org
Subject: Re: generate autoloads versus eval-expression-print-level (patch)
Date: Mon, 14 Apr 2008 10:46:29 +1000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> Actually, looking at the code of eval-expression, it seems to only bind
> those variables around the print part, not the eval part.

Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun
not.  Eg. C-M-x on (progn print-level) ==> 4.

Message #12 received at 135-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 135-done <at> debbugs.gnu.org
Subject: Re: eval-defun binds print-level during eval  
Date: Thu, 29 May 2008 19:07:58 -0400

This has been fixed.

Message #17 received at 135 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 135 <at> debbugs.gnu.org
Subject: Re: bug#135 closed by Glenn Morris <rgm <at> gnu.org> (Re: eval-defun  binds print-level during eval  )
Date: Mon, 02 Jun 2008 09:31:07 +1000

don <at> donarmstrong.com (Emacs bug Tracking System) writes:
>
> This has been fixed.

Has it?  It's still coming out as 4 for me (C-M-x recipe in the bug).

(But I'm a little unsure how clean my build is at the moment.)

Message #22 received at 135 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org
Subject: Re: bug#135 closed by Glenn Morris <rgm <at> gnu.org> (Re: eval-defun  binds print-level during eval  )
Date: Sun, 1 Jun 2008 22:03:06 -0400

Kevin Ryde wrote (on Mon, 2 Jun 2008 at 09:31 +1000):

> Has it?  It's still coming out as 4 for me (C-M-x recipe in the bug).
> 
> (But I'm a little unsure how clean my build is at the moment.)

My mistake, thanks for pointing it out. I will reopen this bug.
(Some of the discussion seems to be missing from the bug tracker,
probably a teething problem.)

Message #29 received at 135 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 135 <at> debbugs.gnu.org
Subject: Re: bug#135 closed by Glenn Morris <rgm <at> gnu.org> (Re: eval-defun  binds print-level during eval  )
Date: Tue, 03 Jun 2008 09:04:51 +1000

Glenn Morris <rgm <at> gnu.org> writes:
>
> (Some of the discussion seems to be missing from the bug tracker,
> probably a teething problem.)

Yeah, no, it was a double-banger starting on emacs-devel; a patch
accepted for one problem, a second (the C-M-x) revealing itself and not
easily fixable ...

Message #34 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org
Subject: Re: generate autoloads versus eval-expression-print-level (patch)
Date: Wed, 06 Jul 2011 19:29:02 +0200

Kevin Ryde <user42 <at> zip.com.au> writes:

>> Actually, looking at the code of eval-expression, it seems to only bind
>> those variables around the print part, not the eval part.
>
> Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun
> not.  Eg. C-M-x on (progn print-level) ==> 4.

What's the status on this bug?  Is this still a problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #37 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi <at> gnus.org>,
	"'Kevin Ryde'" <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org
Subject: RE: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Wed, 6 Jul 2011 12:31:13 -0700

> > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun
> > not.  Eg. C-M-x on (progn print-level) ==> 4.
> 
> What's the status on this bug?  Is this still a problem?

Haven't read the bug thread, but putting (progn print-level) in *scratch* and
doing C-M-x on it shows 4 in the echo area.  IOW, that description still
applies, in the latest Windows build:

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-06-27 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'

Message #42 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Thu, 07 Jul 2011 18:22:36 +0200

"Drew Adams" <drew.adams <at> oracle.com> writes:

>> > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun
>> > not.  Eg. C-M-x on (progn print-level) ==> 4.
>> 
>> What's the status on this bug?  Is this still a problem?
>
> Haven't read the bug thread, but putting (progn print-level) in *scratch* and
> doing C-M-x on it shows 4 in the echo area.  IOW, that description still
> applies, in the latest Windows build:

`C-M-x' uses `eval-expression-print-level' and friends (which default to
4), so I think this isn't a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #47 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Thu, 07 Jul 2011 13:20:55 -0400

Lars Magne Ingebrigtsen wrote:

>> Haven't read the bug thread, but putting (progn print-level) in
>> *scratch* and doing C-M-x on it shows 4 in the echo area. IOW, that
>> description still applies, in the latest Windows build:
>
> `C-M-x' uses `eval-expression-print-level' and friends (which default to
> 4), so I think this isn't a bug.

I don't understand why answering a message which begins "Haven't read
the bug" means the bug can be closed.

As the bug says, some of the thread is missing, but it is easily found.

http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01001.html

    It occurred to me to wonder what business eval-defun has binding
    those print variables during the eval, as opposed to just the
    printing of the result, but doing anything about that looks a bit
    difficult.

Message #50 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Thu, 07 Jul 2011 19:23:21 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> I don't understand why answering a message which begins "Haven't read
> the bug" means the bug can be closed.
>
> As the bug says, some of the thread is missing, but it is easily found.
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01001.html
>
>     It occurred to me to wonder what business eval-defun has binding
>     those print variables during the eval, as opposed to just the
>     printing of the result, but doing anything about that looks a bit
>     difficult.

Ah, right.  I've now reopened the report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #55 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Thu, 07 Jul 2011 15:58:11 -0400

>>> > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun
>>> > not.  Eg. C-M-x on (progn print-level) ==> 4.
>>> What's the status on this bug?  Is this still a problem?
>> Haven't read the bug thread, but putting (progn print-level) in
>> *scratch* and doing C-M-x on it shows 4 in the echo area.  IOW, that
>> description still applies, in the latest Windows build:

> `C-M-x' uses `eval-expression-print-level' and friends (which default to
> 4), so I think this isn't a bug.

The OP considers it a bug because he wants the
(print-level eval-expression-print-level) binding to only apply during
printing but not during evaluation.  I can understand
this interpretation.


        Stefan

Message #58 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Sun, 10 Jul 2011 14:48:02 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> The OP considers it a bug because he wants the
> (print-level eval-expression-print-level) binding to only apply during
> printing but not during evaluation.  I can understand
> this interpretation.

Yes, it sounds reasonable.  But, as you said, somewhat tricky to fix,
since it basically calls the C-level `eval-region', which both evals and
prints the form, if I read the code correctly.

No, wait.  fixing this could be done without too much work, I think.
We could extend PRINTFLAG to `eval-region' (which is currently a
boolean) to be a closure to do the actual printing, for instance.

Basically

(eval-region 2 56 (lambda (form)
                    (let ((print-level eval-expression-print-level))
                          ... etc)
                       (prin1 form)))

That should be backwards-compatible, slightly generally useful, and
should allow us to fix this.

Does this sound OK?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #63 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Sun, 10 Jul 2011 15:14:54 +0200

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> We could extend PRINTFLAG to `eval-region' (which is currently a
> boolean) to be a closure to do the actual printing, for instance.

That argument is actually a stream (which can be a function), though
that doesn't help since that receives the individual characters instead
of the form to print.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #66 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 'Kevin Ryde' <user42 <at> zip.com.au>, 135 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Sun, 10 Jul 2011 15:18:28 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> That argument is actually a stream (which can be a function), though
> that doesn't help since that receives the individual characters instead
> of the form to print.

Ah, right.  So that wouldn't work.  But we could add a new optional
parameter to `eval-region' to do the suggested thing.

But is it worth it?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #69 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 135 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
	'Kevin Ryde' <user42 <at> zip.com.au>
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Mon, 11 Jul 2011 23:35:53 -0400

>> That argument is actually a stream (which can be a function), though
>> that doesn't help since that receives the individual characters instead
>> of the form to print.
> Ah, right.  So that wouldn't work.  But we could add a new optional
> parameter to `eval-region' to do the suggested thing.
> But is it worth it?

eval-region is slightly problematic with lexical-binding, so if we could
avoid using it that would be good.


        Stefan

Message #72 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Fri, 15 Jul 2011 10:18:26 +1000

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>
> `eval-region', which both evals and prints the form,

I thought the read/eval/print was a bit too tightly bound up there, and
that teasing the steps apart might be cleaner than extra ways to
influence it (parameters or dynamic bindings).  Dunno if that'd be easy
or hard though.



-- 
The sigfile food series: Beetroot in Hamburger
Not one of Australia's finest contributions to world gastronomy,
but actually not too bad.

Message #75 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Fri, 15 Jul 2011 19:03:26 +0200

Kevin Ryde <user42 <at> zip.com.au> writes:

> I thought the read/eval/print was a bit too tightly bound up there, and
> that teasing the steps apart might be cleaner than extra ways to
> influence it (parameters or dynamic bindings).  Dunno if that'd be easy
> or hard though.

That's a much better idea.

Looking at the code, it seems that (basically) all you'd need to do is
provide yet yet yet another parameter to readevalloop, and then return
the (last) val, and then refactor eval-region a bit, and then...  uhm...

Ok, it's not totally trivial, but...  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #78 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: 135 <at> debbugs.gnu.org
Subject: Re: bug#135: generate autoloads versus eval-expression-print-level
	(patch)
Date: Sun, 17 Jul 2011 07:56:13 +1000

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>
> readevalloop

I wondered if eval-defun might be something like separate steps
sexp-at-point, macroexpand/mangle, eval, display-result-of-eval-somehow.
Unless eval-region ends up subtly better like error context or debug or
something ...

Message #81 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#135: eval-defun binds print-level during eval
Date: Sun, 24 Apr 2022 17:10:26 +0200

I had an idea, after obviously pondering this issue for ten years.

To recap, for people with bad memories -- put this in a buffer and
`C-M-x' it:

(progn print-level)

It will print 4, because we rebind print-level before evaling it, but
ideally it should have its real value while doing the eval, but be
eval-expression-print-level during printing.

As the printing is actually deep inside the bowels of readevalloop,
untangling that's a challenge...  but...  the following simple change
handles the test case, and doesn't seem to lead to any obvious
regressions.

Any comments here?

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 33f6902491..c442d0fa76 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1614,8 +1614,6 @@ elisp--eval-defun
   ;; printing, not while evaluating.
   (defvar elisp--eval-defun-result)
   (let ((debug-on-error eval-expression-debug-on-error)
-	(print-length eval-expression-print-length)
-	(print-level eval-expression-print-level)
         elisp--eval-defun-result)
     (save-excursion
       ;; Arrange for eval-region to "read" the (possibly) altered form.
@@ -1631,9 +1629,13 @@ elisp--eval-defun
           (setq form (funcall load-read-function (current-buffer)))
           (setq end (point)))
         ;; Alter the form if necessary.
-        (let ((form (eval-sexp-add-defvars
-                     (elisp--eval-defun-1
-                      (macroexpand form)))))
+        (let ((form `(let ((print-level ,print-level)
+                           (print-length ,print-length))
+                       ,(eval-sexp-add-defvars
+                         (elisp--eval-defun-1
+                          (macroexpand form)))))
+	      (print-length eval-expression-print-length)
+	      (print-level eval-expression-print-level))
           (eval-region beg end standard-output
                        (lambda (_ignore)
                          ;; Skipping to the end of the specified region


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #86 received at 135 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 135 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#135: eval-defun binds print-level during eval
Date: Wed, 27 Apr 2022 20:04:19 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> As the printing is actually deep inside the bowels of readevalloop,
> untangling that's a challenge...  but...  the following simple change
> handles the test case, and doesn't seem to lead to any obvious
> regressions.
>
> Any comments here?

No comments, and the code seems to have no untoward side effects, so
I've now pushed the change to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.