pp-eval-expression enhancements

pp-eval-expression enhancements

[Drew Adams]

This patch improves `pp-eval-expression' in these ways:

* Provides a progress message.
* Does not make buffer *Pp Eval Output* read-only.
* Inhibits emacs-lisp-mode-hook and change-major-mode-hook
  when entering emacs-lisp-mode.
* Fontifies buffer *Pp Eval Output*.

I often want to use *Pp Eval Output* as more or less a normal Emacs-Lisp
buffer: killing, yanking, evaluating. I see no reason to make it read-only.
It should probably also have undo, but I'll leave that to someone else's
patch.

I also propose that we use `M-:', the binding of `eval-expression', for
`pp-eval-expression' instead. Why would we not want to do that? To try that
out, do this:

(substitute-key-definition 'eval-expression 'pp-eval-expression global-map)

--------------8<---------------------

*** pp-CVS-2007-07-10.el	Tue Jul 10 15:37:26 2007
--- pp-CVS-patched-2007-07-10.el	Tue Jul 10 15:40:38 2007
***************
*** 103,108 ****
--- 103,109 ----
    (interactive
     (list (read-from-minibuffer "Eval: " nil read-expression-map t
                                 'read-expression-history)))
+   (message "Evaluating...")
    (setq values (cons (eval expression) values))
    (let* ((old-show-function temp-buffer-show-function)
  	 ;; Use this function to display the buffer.
***************
*** 126,139 ****
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
! 		       (select-window old-selected)))
! 		 (message "%s" (buffer-substring (point-min) (point)))
! 		 ))))))
!     (with-output-to-temp-buffer "*Pp Eval Output*"
!       (pp (car values))
!       (with-current-buffer standard-output
! 	(emacs-lisp-mode)
! 	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload
  (defun pp-eval-last-sexp (arg)
--- 127,144 ----
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
!                       (select-window old-selected)
!                       (message "Evaluating...done.  See buffer *Pp Eval
Output*.")))
!                 (message "%s" (buffer-substring (point-min)
(point)))))))))
!     (with-output-to-temp-buffer "*Pp Eval Output*" (pp (car values)))
!     (save-excursion
!       (set-buffer "*Pp Eval Output*")
!       (setq buffer-read-only nil)
!       (let ((emacs-lisp-mode-hook nil)
!             (change-major-mode-hook nil))
!         (emacs-lisp-mode))
!       (set (make-local-variable 'font-lock-verbose) nil)
!       (font-lock-fontify-buffer))))

  ;;;###autoload
  (defun pp-eval-last-sexp (arg)

RE: pp-eval-expression enhancements

[Drew Adams]

Any news on this?

> From: Drew Adams Sent: Tuesday, July 10, 2007 3:55 PM
> This patch improves `pp-eval-expression' in these ways:
> 
> * Provides a progress message.
> * Does not make buffer *Pp Eval Output* read-only.
> * Inhibits emacs-lisp-mode-hook and change-major-mode-hook
>   when entering emacs-lisp-mode.
> * Fontifies buffer *Pp Eval Output*.
> 
> I often want to use *Pp Eval Output* as more or less a normal Emacs-Lisp
> buffer: killing, yanking, evaluating. I see no reason to make it 
> read-only. It should probably also have undo, but I'll leave that to
> someone else's patch.
> 
> I also propose that we use `M-:', the binding of `eval-expression', for
> `pp-eval-expression' instead. Why would we not want to do that? 
> To try that out, do this:
> 
> (substitute-key-definition 'eval-expression 'pp-eval-expression 
> global-map)
> 
> --------------8<---------------------
> 
> *** pp-CVS-2007-07-10.el	Tue Jul 10 15:37:26 2007
> --- pp-CVS-patched-2007-07-10.el	Tue Jul 10 15:40:38 2007
> ***************
> *** 103,108 ****
> --- 103,109 ----
>     (interactive
>      (list (read-from-minibuffer "Eval: " nil read-expression-map t
>                                  'read-expression-history)))
> +   (message "Evaluating...")
>     (setq values (cons (eval expression) values))
>     (let* ((old-show-function temp-buffer-show-function)
>   	 ;; Use this function to display the buffer.
> ***************
> *** 126,139 ****
>   			 (progn
>   			   (select-window window)
>   			   (run-hooks 'temp-buffer-show-hook))
> ! 		       (select-window old-selected)))
> ! 		 (message "%s" (buffer-substring (point-min) (point)))
> ! 		 ))))))
> !     (with-output-to-temp-buffer "*Pp Eval Output*"
> !       (pp (car values))
> !       (with-current-buffer standard-output
> ! 	(emacs-lisp-mode)
> ! 	(set (make-local-variable 'font-lock-verbose) nil)))))
> 
>   ;;;###autoload
>   (defun pp-eval-last-sexp (arg)
> --- 127,144 ----
>   			 (progn
>   			   (select-window window)
>   			   (run-hooks 'temp-buffer-show-hook))
> !                       (select-window old-selected)
> !                       (message "Evaluating...done.  See buffer *Pp Eval
> Output*.")))
> !                 (message "%s" (buffer-substring (point-min)
> (point)))))))))
> !     (with-output-to-temp-buffer "*Pp Eval Output*" (pp (car values)))
> !     (save-excursion
> !       (set-buffer "*Pp Eval Output*")
> !       (setq buffer-read-only nil)
> !       (let ((emacs-lisp-mode-hook nil)
> !             (change-major-mode-hook nil))
> !         (emacs-lisp-mode))
> !       (set (make-local-variable 'font-lock-verbose) nil)
> !       (font-lock-fontify-buffer))))
> 
>   ;;;###autoload
>   (defun pp-eval-last-sexp (arg)

Re: pp-eval-expression enhancements

[Richard Stallman]

    > * Provides a progress message.
    > * Does not make buffer *Pp Eval Output* read-only.
    > * Fontifies buffer *Pp Eval Output*.

Those three sound like improvements.
(But why doesn't it fontify itself anyway,
now that font lock is normally enabled?
Is that a bug?)

    > * Inhibits emacs-lisp-mode-hook and change-major-mode-hook
    >   when entering emacs-lisp-mode.

That sounds wrong to me -- what's the motive for it?

RE: pp-eval-expression enhancements

[Drew Adams]

>     > * Provides a progress message.
>     > * Does not make buffer *Pp Eval Output* read-only.
>     > * Fontifies buffer *Pp Eval Output*.
>
> Those three sound like improvements.
> (But why doesn't it fontify itself anyway,
> now that font lock is normally enabled?
> Is that a bug?)

My bad; it does. (It didn't used to.)

>     > * Inhibits emacs-lisp-mode-hook and change-major-mode-hook
>     >   when entering emacs-lisp-mode.
>
> That sounds wrong to me -- what's the motive for it?

I don't remember details, but I did it because some such hooks I used seemed
inappropriate here. For instance, I automatically add a header to a new lisp
file via `emacs-lisp-mode-hook' - the header is inappropriate for the PP
buffer.

Perhaps there is a better way to make such distinctions, and these hooks
shouldn't be disabled. I don't know.

Re: pp-eval-expression enhancements

[Richard Stallman]

    I don't remember details, but I did it because some such hooks I used seemed
    inappropriate here. For instance, I automatically add a header to a new lisp
    file via `emacs-lisp-mode-hook' - the header is inappropriate for the PP
    buffer.

    Perhaps there is a better way to make such distinctions, and these hooks
    shouldn't be disabled. I don't know.

Your hook function can test the buffer name.
The hook shouldn't be disabled.

Can you please send the two changes that I'd like to install,
with change log?  Then we can install them.

RE: pp-eval-expression enhancements

[Drew Adams]

> Can you please send the two changes that I'd like to install,
> with change log?  Then we can install them.

Below.

What about also replacing the binding of `M-:' so that it invokes
`pp-eval-expression'? What is the downside to that? If it's for the prefix
arg of `eval-expression', we could add the prefix arg to
`pp-eval-expression' also. If it's for `eval-expression-debug-on-error',
then `pp-eval-expression' could be made aware of that also.

It seems to me that for interactive use (`M-:') `pp-eval-expression' is more
useful than `eval-expression'.

--------8<-----------------
Change log:

2007-07-24  Drew Adams  <drew.adams@oracle.com>

      * pp.el: pp-eval-expression: Added progress message. Made buffer
writable.

--------8<-----------------
*** pp-CVS-2007-07-10.el	Tue Jul 10 15:37:26 2007
--- pp-CVS-patched-2007-07-24.el	Tue Jul 24 09:58:02 2007
***************
*** 103,108 ****
--- 103,109 ----
    (interactive
     (list (read-from-minibuffer "Eval: " nil read-expression-map t
                                 'read-expression-history)))
+   (message "Evaluating...")
    (setq values (cons (eval expression) values))
    (let* ((old-show-function temp-buffer-show-function)
  	 ;; Use this function to display the buffer.
***************
*** 126,138 ****
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
! 		       (select-window old-selected)))
! 		 (message "%s" (buffer-substring (point-min) (point)))
! 		 ))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload
--- 127,140 ----
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
!                       (select-window old-selected)
!                       (message "Evaluating...done.  See buffer *Pp Eval
Output*.")))
!                 (message "%s" (buffer-substring (point-min)
(point)))))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
+         (setq buffer-read-only nil)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload

Re: pp-eval-expression enhancements

[Stefan Monnier]

> What about also replacing the binding of `M-:' so that it invokes
> `pp-eval-expression'? What is the downside to that? If it's for the prefix
> arg of `eval-expression', we could add the prefix arg to
> `pp-eval-expression' also. If it's for `eval-expression-debug-on-error',
> then `pp-eval-expression' could be made aware of that also.

I never tried to use pp-eval-expression, but I'm curious [I use a separate
minibuffer frame made of a single long line, so pp-eval-expression wouldn't
be much use for me anyway].

If I try it with M-x pp-eval-expression RET '(let ((x 1)) x) RET
it pops up a new frame showing that sexp on a few lines.  I find this
a bit inconvenient: if I want a separate frame, I'd rather use M-x ielm.


        Stefan

RE: pp-eval-expression enhancements

[Drew Adams]

> > What about also replacing the binding of `M-:' so that it invokes
> > `pp-eval-expression'? What is the downside to that? If it's for
> > the prefix arg of `eval-expression', we could add the prefix arg to
> > `pp-eval-expression' also. If it's for `eval-expression-debug-on-error',
> > then `pp-eval-expression' could be made aware of that also.
>
> I never tried to use pp-eval-expression, but I'm curious
> [I use a separate minibuffer frame made of a single long
> line, so pp-eval-expression wouldn't be much use for me anyway].

I too use a separate minibuffer frame that extends all the way across my
display.

`pp-eval-expression' uses the minibuffer only for short values. It puts a
large result in buffer *Pp Eval Ouput*. In my case and yours, that buffer is
displayed in a separate frame.

> If I try it with M-x pp-eval-expression RET '(let ((x 1)) x) RET
> it pops up a new frame showing that sexp on a few lines.

Yes, it considers the result to be large, not small. It uses this test,
where the cursor is after the printed result:

  (or (< (1+ (point)) (point-max))
      (>= (- (point) (point-min)) (frame-width)))

If that test is nil, it uses `message' to print the result (like
`eval-expression').

> I find this a bit inconvenient: if I want a separate frame,
> I'd rather use M-x ielm.

OK, I can see that different users might prefer different behaviors. I
wonder what most prefer.

I don't use `ielm' much, but I suppose that if you know ahead of time that
the result will be something that you want to manipulate (e.g. edit) then
you might want to use `ielm'. It seems like overkill for this, but yes,
that's one option. Do you have `ielm' on a key? `M-:'? Do you use
`eval-expression' much?

I use `pp-eval-expression' because it decides pretty well, IMO: if the
result is more than it would make sense to show in the echo area, then it's
likely that I want to do something with the result, so it puts it in a
separate buffer, in the right mode.

I find the heuristic is uses pretty handy. I never need to fish the result
out of *Messages*, and if I don't want the result that is displayed in *Pp
Eval Output* I just hit `C-x 0' to delete the frame. Would you find `C-x 0'
inconvenient? Don't you have the same problem (inconvenience) for `C-h f'?

I find it much more inconvenient that `M-:' currently prints a nice result
(though it is difficult to read, because it is not pretty-printed and it is
crammed into the echo area), but I can't get to that result to do anything
with it, without going to buffer *Messages* and fishing it out.

Anyway, this is a question for the benefit of others; I customized `M-:' to
`pp-eval-expression' eons ago.

Re: pp-eval-expression enhancements

[Stefan Monnier]

> Yes, it considers the result to be large, not small. It uses this test,
> where the cursor is after the printed result:

>   (or (< (1+ (point)) (point-max))
>       (>= (- (point) (point-min)) (frame-width)))

That's odd, I just tried it in a "normal" Emacs session (no separate
minibuffer frame) and it also pops up a separate window rather than display
it in the echo area, even tho '(let ((x 1)) x) isn't nearly as long as my
frame's width (80 columns).  Looking at the code, I see the above check is
made after pp and the first part checks whether the output uses a single
line or not, and of course my `let' expression uses 3 lines.

With setups different from mine where the echo area can grow to several
lines, it would make sense to change the logic so as to allow the use of the
echo-area even if the output spans more than one line.

In any case, I'm not sure if pp-eval-expression's behavior would really be
worse than M-: even for me.  It's probably a question of habit.

> I don't use `ielm' much, but I suppose that if you know ahead of time that
> the result will be something that you want to manipulate (e.g. edit) then
> you might want to use `ielm'.  It seems like overkill for this, but yes,
> that's one option.  Do you have `ielm' on a key? `M-:'? Do you use
> `eval-expression' much?

I use M-: extensively.  And I use ielm on a regular basis.  I don't have any
special binding for it: M-x ielm RET is quick enough.  As for overkill,
I actually find it pretty lightweight, so I'd disagree.  The only problem
with `ielm' is that I have to `C-c b' to the proper buffer before being able
to do what I want.

> I use `pp-eval-expression' because it decides pretty well, IMO: if the
> result is more than it would make sense to show in the echo area, then it's
> likely that I want to do something with the result, so it puts it in a
> separate buffer, in the right mode.

> I find the heuristic is uses pretty handy. I never need to fish the result
> out of *Messages*

I never need such fishing, I always use the C-u prefix arg for that.

> Would you find `C-x 0' inconvenient? Don't you have the same problem
> (inconvenience) for `C-h f'?

It's probably a question of habit.

> I find it much more inconvenient that `M-:' currently prints a nice result
> (though it is difficult to read, because it is not pretty-printed and it is
> crammed into the echo area), but I can't get to that result to do anything
> with it, without going to buffer *Messages* and fishing it out.

Yes, pretty printing is good.  I think your idea is right, but it needs
tweaking so as to use the echo-area more often (always?).


        Stefan

RE: pp-eval-expression enhancements

[Drew Adams]

> > Yes, it considers the result to be large, not small. It uses this test,
> > where the cursor is after the printed result:
>
> >   (or (< (1+ (point)) (point-max))
> >       (>= (- (point) (point-min)) (frame-width)))
>
> That's odd, I just tried it in a "normal" Emacs session (no separate
> minibuffer frame) and it also pops up a separate window rather
> than display it in the echo area, even tho '(let ((x 1)) x) isn't
> nearly as long as my frame's width (80 columns).  Looking at the
> code, I see the above check is made after pp and the first part
> checks whether the output uses a single line or not, and of course
> my `let' expression uses 3 lines.
>
> With setups different from mine where the echo area can grow to several
> lines, it would make sense to change the logic so as to allow the
> use of the echo-area even if the output spans more than one line.

I think I disagree. The echo area is not a good place to put something that
you might want to recuperate and reuse. (Perhaps we agree on that much.)

If pretty-printing uses more than one line, then the result is likely to be
something that you might want to do something with. It is structural
complexity more than number of characters that determines this likelihood,
IMO. And newlines, in pretty printing, reflect structural complexity.

Your test, although presumably contrived, is a good example of this. Imagine
that the result came from evaluating some function call, and you wanted to
edit the `let' expression and use that in some Lisp code.

I'd rather have only very simple results (e.g. "42") be printed using
`message', and anything that I might want to edit and reuse be put in an
`emacs-lisp-mode' buffer. As a matter of fact, I think that the only times
I've ever been inconvenienced by `pp-eval-expression' were when it printed
some simple result in the echo area and I wanted to recuperate it. Its
heuristic is spot on most of the time, IMO.

> In any case, I'm not sure if pp-eval-expression's behavior would really be
> worse than M-: even for me.  It's probably a question of habit.

Since you say below that you use `M-:' a lot, why don't you try it for a
while, and see?

> > I don't use `ielm' much, but I suppose that if you know ahead
> > of time that the result will be something that you want to
> > manipulate (e.g. edit) then you might want to use `ielm'.
> > It seems like overkill for this, but yes, that's one option.
> > Do you have `ielm' on a key? `M-:'? Do you use `eval-expression'
> > much?
>
> I use M-: extensively.  And I use ielm on a regular basis.  I
> don't have any special binding for it: M-x ielm RET is quick
> enough.  As for overkill, I actually find it pretty lightweight,
> so I'd disagree.  The only problem with `ielm' is that I have to
> `C-c b' to the proper buffer before being able to do what I want.

Maybe `ielm' should select the buffer for you.

> > I use `pp-eval-expression' because it decides pretty well, IMO:
> > if the result is more than it would make sense to show in the
> > echo area, then it's likely that I want to do something with
> > the result, so it puts it in a separate buffer, in the right mode.
>
> > I find the heuristic is uses pretty handy. I never need to fish
> > the result out of *Messages*
>
> I never need such fishing, I always use the C-u prefix arg for that.

You apparently always (1) know ahead of time that you want to use the
result, and (2) open an appropriate buffer ahead of time, to capture the
pasted result. I often want to see what a value is, and, depending on that,
_perhaps_ do something with it, but I might not be in a buffer or at a
buffer location where I would want it pasted.

In addition, I sometimes use `M-:' on the fly during minibuffer completion
(in Icicles, `M-:' is bound in the minibuffer keymaps to
`pp-eval-expression'). It is quite convenient to have the result displayed
in another buffer, for examination or editing and copying. I often use `M-:'
the same way one would use `C-h f', `C-h k', and `C-h F': to get information
about something. I use both kinds of information during minibuffer input.

This points out that even if you don't want to edit and reuse an eval'd
result - you just want to examine it, it's handy to have it in a separate
place from the echo area.

> > Would you find `C-x 0' inconvenient? Don't you have the same problem
> > (inconvenience) for `C-h f'?
>
> It's probably a question of habit.

Sounds like it. Try it and see.

> > I find it much more inconvenient that `M-:' currently prints a
> > nice result (though it is difficult to read, because it is not
> > pretty-printed and it is crammed into the echo area), but I
> > can't get to that result to do anything
> > with it, without going to buffer *Messages* and fishing it out.
>
> Yes, pretty printing is good.  I think your idea is right, but it needs
> tweaking so as to use the echo-area more often (always?).

If you do that, then please don't do it to `pp-eval-expression' itself, but
to some new command. I'd like to be able to retain the current behavior of
`pp-eval-expression'. I don't want it to start using the echo area more, and
certainly not always. It does not "need tweaking" to use the echo area more.
Less, I might go along with ;-), but it's very good just the way it is, IMO.

Re: pp-eval-expression enhancements

[Stefan Monnier]

>> > I use `pp-eval-expression' because it decides pretty well, IMO:
>> > if the result is more than it would make sense to show in the
>> > echo area, then it's likely that I want to do something with
>> > the result, so it puts it in a separate buffer, in the right mode.
>> 
>> > I find the heuristic is uses pretty handy. I never need to fish
>> > the result out of *Messages*
>> 
>> I never need such fishing, I always use the C-u prefix arg for that.

> You apparently always (1) know ahead of time that you want to use the
> result, and (2) open an appropriate buffer ahead of time, to capture the
> pasted result.

No.  I always do something like:

  M-: <something> RET

then look at the result and think "oh I could do <mumble>" so I go where
I need the thing inserted and then do

  C-u M-: M-p RET

Works just dandy.

> In addition, I sometimes use `M-:' on the fly during minibuffer completion
> (in Icicles, `M-:' is bound in the minibuffer keymaps to
> `pp-eval-expression'). It is quite convenient to have the result displayed
> in another buffer, for examination or editing and copying. I often use `M-:'
> the same way one would use `C-h f', `C-h k', and `C-h F': to get information
> about something. I use both kinds of information during minibuffer input.

That's a separate issue, I believe.  Most uses of `message' should be made
more careful so that they do something more clever if used from within
the minibuffer.


        Stefan

Re: pp-eval-expression enhancements

[Richard Stallman]

    What about also replacing the binding of `M-:' so that it invokes
    `pp-eval-expression'?

I don't know if this is safe.  There may be Lisp objects for which
print works and pretty-print fails.  And others have pointed out
other problems (though we could avoid them by making a new command
which is just like eval-expression except that it pretty-prints).

Re: pp-eval-expression enhancements

[Richard Stallman]

Would someone please install this in the trunk, then ack?

From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>
Date: Tue, 24 Jul 2007 10:18:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-15"
In-Reply-To: <E1IDNW3-0002om-Hk@fencepost.gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: pp-eval-expression enhancements

> Can you please send the two changes that I'd like to install,
> with change log?  Then we can install them.

Below.

What about also replacing the binding of `M-:' so that it invokes
`pp-eval-expression'? What is the downside to that? If it's for the prefix
arg of `eval-expression', we could add the prefix arg to
`pp-eval-expression' also. If it's for `eval-expression-debug-on-error',
then `pp-eval-expression' could be made aware of that also.

It seems to me that for interactive use (`M-:') `pp-eval-expression' is more
useful than `eval-expression'.

--------8<-----------------
Change log:

2007-07-24  Drew Adams  <drew.adams@oracle.com>

      * pp.el: pp-eval-expression: Added progress message. Made buffer
writable.

--------8<-----------------
*** pp-CVS-2007-07-10.el	Tue Jul 10 15:37:26 2007
--- pp-CVS-patched-2007-07-24.el	Tue Jul 24 09:58:02 2007
***************
*** 103,108 ****
--- 103,109 ----
    (interactive
     (list (read-from-minibuffer "Eval: " nil read-expression-map t
                                 'read-expression-history)))
+   (message "Evaluating...")
    (setq values (cons (eval expression) values))
    (let* ((old-show-function temp-buffer-show-function)
  	 ;; Use this function to display the buffer.
***************
*** 126,138 ****
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
! 		       (select-window old-selected)))
! 		 (message "%s" (buffer-substring (point-min) (point)))
! 		 ))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload
--- 127,140 ----
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
!                       (select-window old-selected)
!                       (message "Evaluating...done.  See buffer *Pp Eval
Output*.")))
!                 (message "%s" (buffer-substring (point-min)
(point)))))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
+         (setq buffer-read-only nil)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: pp-eval-expression enhancements

[Juri Linkov]

>                        It is quite convenient to have the result displayed
> in another buffer, for examination or editing and copying. I often use `M-:'
> the same way one would use `C-h f', `C-h k', and `C-h F': to get information
> about something. I use both kinds of information during minibuffer input.

Since it's impossible to find heuristics that would decide whether to
display the result in the echo area, or to pop up a separate result buffer
(because only the user can decide this), I use the following post-advice
on shell-command:

    (when (memq last-input-char '(S-return ?\C-j))
      (message "")
      (pop-to-buffer "*Shell Command Output*"))

i.e. when the minibuffer with the command is exited with S-RET, then
it displays the output buffer regardless on its size.

If `M-:' created the buffer *Pp Eval Output* even without displaying it,
it would be possible to create a similar hook to display it depending
on some key used to exit the `M-:' minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: pp-eval-expression enhancements

[Stefan Monnier]

> Since it's impossible to find heuristics that would decide whether to
> display the result in the echo area, or to pop up a separate result buffer
> (because only the user can decide this), I use the following post-advice
> on shell-command:

>     (when (memq last-input-char '(S-return ?\C-j))
>       (message "")
>       (pop-to-buffer "*Shell Command Output*"))

I'm afraid that it's still too early: the user still has to decide where the
result goes before seeing that result.  A better option might be to provide
a new command that can be executed right after M-: which would show the last
result in a separate buffer, pretty printed, highlighted, and all.


        Stefan

Re: pp-eval-expression enhancements

[Juri Linkov]

> I'm afraid that it's still too early: the user still has to decide where the
> result goes before seeing that result.  A better option might be to provide
> a new command that can be executed right after M-: which would show the last
> result in a separate buffer, pretty printed, highlighted, and all.

I think a new display command to execute after M-: can be useful only
when the user doesn't know beforehand what the output will look like.
But in most cases before executing M-: or M-!, I know what the output
I expect and what I want to do with the output (search/edit/copy-paste...)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: pp-eval-expression enhancements

[Stefan Monnier]

>> I'm afraid that it's still too early: the user still has to decide where the
>> result goes before seeing that result.  A better option might be to provide
>> a new command that can be executed right after M-: which would show the last
>> result in a separate buffer, pretty printed, highlighted, and all.

> I think a new display command to execute after M-: can be useful only
> when the user doesn't know beforehand what the output will look like.
> But in most cases before executing M-: or M-!, I know what the output
> I expect and what I want to do with the output (search/edit/copy-paste...)

That's very much not my case.  The way I typically use M-: is as follows:

- M-: <something> RET
  [ doesn't give me what I want, either because of a typo, or because
  I need to refine the command. ]
- M-: M-p <edit> RET
  [ still doesn't give me what I want. ]
- M-: M-p <moreedits> RET
  [ Ah, now that's what I wanted to see. ]
- And now, if I need to see the result elsewhere, then I'll do
  C-u M-: M-p RET

So even if I know that I will want to insert the output at point, I still
want to first see this result to make sure that it's indeed the one I want.


        Stefan

Re: pp-eval-expression enhancements

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

Would someone please install this in the trunk, then ack?

From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>
Date: Tue, 24 Jul 2007 10:18:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-15"
In-Reply-To: <E1IDNW3-0002om-Hk@fencepost.gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: pp-eval-expression enhancements

> Can you please send the two changes that I'd like to install,
> with change log?  Then we can install them.

Below.

What about also replacing the binding of `M-:' so that it invokes
`pp-eval-expression'? What is the downside to that? If it's for the prefix
arg of `eval-expression', we could add the prefix arg to
`pp-eval-expression' also. If it's for `eval-expression-debug-on-error',
then `pp-eval-expression' could be made aware of that also.

It seems to me that for interactive use (`M-:') `pp-eval-expression' is more
useful than `eval-expression'.

--------8<-----------------
Change log:

2007-07-24  Drew Adams  <drew.adams@oracle.com>

      * pp.el: pp-eval-expression: Added progress message. Made buffer
writable.

--------8<-----------------
*** pp-CVS-2007-07-10.el	Tue Jul 10 15:37:26 2007
--- pp-CVS-patched-2007-07-24.el	Tue Jul 24 09:58:02 2007
***************
*** 103,108 ****
--- 103,109 ----
    (interactive
     (list (read-from-minibuffer "Eval: " nil read-expression-map t
                                 'read-expression-history)))
+   (message "Evaluating...")
    (setq values (cons (eval expression) values))
    (let* ((old-show-function temp-buffer-show-function)
  	 ;; Use this function to display the buffer.
***************
*** 126,138 ****
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
! 		       (select-window old-selected)))
! 		 (message "%s" (buffer-substring (point-min) (point)))
! 		 ))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload
--- 127,140 ----
  			 (progn
  			   (select-window window)
  			   (run-hooks 'temp-buffer-show-hook))
!                       (select-window old-selected)
!                       (message "Evaluating...done.  See buffer *Pp Eval
Output*.")))
!                 (message "%s" (buffer-substring (point-min)
(point)))))))))
      (with-output-to-temp-buffer "*Pp Eval Output*"
        (pp (car values))
        (with-current-buffer standard-output
  	(emacs-lisp-mode)
+         (setq buffer-read-only nil)
  	(set (make-local-variable 'font-lock-verbose) nil)))))

  ;;;###autoload




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: pp-eval-expression enhancements

[Glenn Morris]

Richard Stallman wrote:

> Would someone please install this in the trunk, then ack?

ack

> 2007-07-24  Drew Adams  <drew.adams@oracle.com>
>
>       * pp.el: pp-eval-expression: Added progress message. Made buffer
> writable.

This is not the right format for a ChangeLog entry (compare with the
corrected version).

Re: pp-eval-expression enhancements

[T. V. Raman]

My present solution to this problem is to use a personal wrapper
around cl-prettyprint and cl-prettyexpand 

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:
    >> It is quite convenient to have the result displayed in
    >> another buffer, for examination or editing and copying. I
    >> often use `M-:' the same way one would use `C-h f', `C-h
    >> k', and `C-h F': to get information about something. I use
    >> both kinds of information during minibuffer input.
    Juri> 
    Juri> Since it's impossible to find heuristics that would
    Juri> decide whether to display the result in the echo area,
    Juri> or to pop up a separate result buffer (because only the
    Juri> user can decide this), I use the following post-advice
    Juri> on shell-command:
    Juri> 
    Juri>     (when (memq last-input-char '(S-return ?\C-j))
    Juri> (message "") (pop-to-buffer "*Shell Command Output*"))
    Juri> 
    Juri> i.e. when the minibuffer with the command is exited
    Juri> with S-RET, then it displays the output buffer
    Juri> regardless on its size.
    Juri> 
    Juri> If `M-:' created the buffer *Pp Eval Output* even
    Juri> without displaying it, it would be possible to create a
    Juri> similar hook to display it depending on some key used
    Juri> to exit the `M-:' minibuffer.
    Juri> 
    Juri> -- Juri Linkov http://www.jurta.org/emacs/
    Juri> 
    Juri> 
    Juri> _______________________________________________
    Juri> Emacs-devel mailing list Emacs-devel@gnu.org
    Juri> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs