generate autoloads versus eval-expression-print-level (patch)

generate autoloads versus eval-expression-print-level (patch)

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

I was trying some update-file-autoloads and generate-file-autoloads via
progn forms in a test file, running them with C-M-x.  Eg.

    (progn
      (switch-to-buffer "x")
      (require 'autoload)
      (generate-file-autoloads "foo.el"))

I was very confused that my defgroups (in foo.el) like

    ;;;###autoload
    (defgroup my-group nil "This is my group."
      :prefix "my-group-"
      :group 'applications)

would end up in the output with ellipsis like

    (let ((loads (get ... ...))) (if (member (quote "foo") loads) nil (put (quote my-group) (quote custom-loads) (cons ... loads))))

I guess eval-expression-print-level interferes with what autoloads.el is
trying to produce.  I wonder autoloads.el could bind print-level like it
does print-length, for certainty of output.

2008-04-11  Kevin Ryde  <user42@zip.com.au>

	* emacs-lisp/autoload.el (autoload-generate-file-autoloads): Bind
	print-level to ensure defgroup output forms aren't truncated if
	print-level is set to eval-expression-print-level when going via
	eval-defun and friends, or has been otherwise fiddled with.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: autoload.el.print-level.diff --]
[-- Type: text/x-diff, Size: 454 bytes --]

*** autoload.el	07 Apr 2008 08:04:36 +1000	1.136
--- autoload.el	11 Apr 2008 09:12:19 +1000	
***************
*** 335,340 ****
--- 335,341 ----
      (let ((autoloads-done '())
            (load-name (autoload-file-load-name file))
            (print-length nil)
+           (print-level nil)
            (print-readably t)           ; This does something in Lucid Emacs.
            (float-output-format nil)
            (visited (get-file-buffer file))

Re: generate autoloads versus eval-expression-print-level (patch)

[Stefan Monnier]

> ***************
> *** 335,340 ****
> --- 335,341 ----
>       (let ((autoloads-done '())
>             (load-name (autoload-file-load-name file))
>             (print-length nil)
> +           (print-level nil)
>             (print-readably t)           ; This does something in Lucid Emacs.
>             (float-output-format nil)
>             (visited (get-file-buffer file))


Thanks, installed,


        Stefan

Re: generate autoloads versus eval-expression-print-level (patch)

[Kevin Ryde]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> installed,

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.

Re: generate autoloads versus eval-expression-print-level (patch)

[Stefan Monnier]

> 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.

Actually, looking at the code of eval-expression, it seems to only bind
those variables around the print part, not the eval part.


        Stefan

Re: generate autoloads versus eval-expression-print-level (patch)

[Kevin Ryde]

Stefan Monnier <monnier@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.

Re: generate autoloads versus eval-expression-print-level (patch)

[Stefan Monnier]

>> 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.

Oh, indeed, and it's not obvious how best to fix it.  Hmm...


        Stefan

bug#135: marked as done (eval-defun binds print-level during eval)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]


Your message dated Thu, 29 May 2008 19:07:58 -0400
with message-id <18495.14158.982200.566312@fencepost.gnu.org>
and subject line Re: eval-defun binds print-level during eval  
has caused the Emacs bug report #135,
regarding eval-defun binds print-level during eval
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
135: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=135
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5324 bytes --]

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

Stefan Monnier <monnier@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.




[-- Attachment #3: Type: message/rfc822, Size: 1229 bytes --]

From: Glenn Morris <rgm@gnu.org>
To: 135-done@emacsbugs.donarmstrong.com
Subject: Re: eval-defun binds print-level during eval
Date: Thu, 29 May 2008 19:07:58 -0400
Message-ID: <18495.14158.982200.566312@fencepost.gnu.org>


This has been fixed.

bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval )

[Kevin Ryde]

don@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.)

bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval )

[Glenn Morris]

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.)

bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval )

[Kevin Ryde]

Glenn Morris <rgm@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 ...

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

Kevin Ryde <user42@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Drew Adams]

> > 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'

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Glenn Morris]

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.

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Stefan Monnier]

>>> > 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

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Stefan Monnier]

>> 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

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Kevin Ryde]

Lars Magne Ingebrigtsen <larsi@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.

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Lars Magne Ingebrigtsen]

Kevin Ryde <user42@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/

bug#135: generate autoloads versus eval-expression-print-level (patch)

[Kevin Ryde]

Lars Magne Ingebrigtsen <larsi@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 ...

bug#135: eval-defun binds print-level during eval

[Lars Ingebrigtsen]

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

bug#135: eval-defun binds print-level during eval

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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