all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: RE: pp-eval-expression enhancements
Date: Tue, 24 Jul 2007 13:23:52 -0700	[thread overview]
Message-ID: <BNELLINCGFJLDJIKDGACAEONCAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvvec9zkkb.fsf-monnier+emacs@gnu.org>

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

  reply	other threads:[~2007-07-24 20:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 22:54 pp-eval-expression enhancements Drew Adams
2007-07-22 23:42 ` Drew Adams
2007-07-23 18:06   ` Richard Stallman
2007-07-23 20:54     ` Drew Adams
2007-07-24 16:45       ` Richard Stallman
2007-07-24 17:18         ` Drew Adams
2007-07-24 18:17           ` Stefan Monnier
2007-07-24 18:50             ` Drew Adams
2007-07-24 19:24               ` Stefan Monnier
2007-07-24 20:23                 ` Drew Adams [this message]
2007-07-24 22:02                   ` Stefan Monnier
2007-07-25 21:40                   ` Juri Linkov
2007-07-26  0:49                     ` Stefan Monnier
2007-07-26  8:48                       ` Juri Linkov
2007-07-26 19:12                         ` Stefan Monnier
2007-08-04 23:42                     ` T. V. Raman
2007-07-25 15:02           ` Richard Stallman
2007-07-25 15:02           ` Richard Stallman
2007-08-02 15:45           ` Richard Stallman
2007-08-03  3:26             ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BNELLINCGFJLDJIKDGACAEONCAAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.