C-x C-e with prefix arg

C-x C-e with prefix arg

[Drew Adams]

How about letting the particular prefix arg control whether to print the full
value?

You use a prefix arg to insert the value in the current buffer at point.  How
often do you really want the inserted value to have pieces missing (elided)?
You typically want to (edit and) use the inserted value in code you are writing,
no?

How about letting a non-negative prefix arg insert the full value (in effect,
binding `eval-expression-print-length' and `eval-expression-print-level' to
nil)?  And letting a negative prefix arg do what any prefix arg does today:
respect the current values of `eval-expression-print-length' and
`eval-expression-print-level'?

Today, to get the full value inserted you need to avoid `C-x C-e' and instead
select the sexp and use `eval-region' - or use some other workaround.

Re: C-x C-e with prefix arg

[Xue Fuqiao]

On Fri, May 3, 2013 at 11:42 PM, Drew Adams <drew.adams@oracle.com> wrote:
> How about letting the particular prefix arg control whether to print the full
> value?

Good idea.

> You use a prefix arg to insert the value in the current buffer at point.  How
> often do you really want the inserted value to have pieces missing (elided)?
> You typically want to (edit and) use the inserted value in code you are writing,
> no?
>
> How about letting a non-negative prefix arg insert the full value (in effect,
> binding `eval-expression-print-length' and `eval-expression-print-level' to
> nil)?  And letting a negative prefix arg do what any prefix arg does today:
> respect the current values of `eval-expression-print-length' and
> `eval-expression-print-level'?

Agreed.  Would you like to submit a patch here or to bug-gnu-emacs?

> Today, to get the full value inserted you need to avoid `C-x C-e' and instead
> select the sexp and use `eval-region' - or use some other workaround.

That's true.  It's somewhat annnoying.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

RE: C-x C-e with prefix arg [patch]

[Drew Adams]

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

> > How about letting a non-negative prefix arg insert the full 
> > value (in effect, binding `eval-expression-print-length' and 
> > `eval-expression-print-level' to nil)?  And letting a negative
> > prefix arg do what any prefix arg does today: respect the
> > current values of `eval-expression-print-length' and
> > `eval-expression-print-level'?
> 
> Agreed.  Would you like to submit a patch here or to bug-gnu-emacs?

Attached.

I also changed `eval-print-last-sexp' similarly: a negative prefix arg for it
does what the function always did before: print the abbreviated value.
Otherwise it now prints the full value.

Someone might want to check that the other, non-interactive uses of
`eval-last-sexp' in `lisp-mode.el' still do what is expected (no change).  I
think so.

--

2013-05-04 Drew Adams  <drew.adams@oracle.com>
	* lisp-mode.el:
	(eval-last-sexp):
	Print full value if non-negative prefix arg.
	(eval-print-last-sexp):
	Added optional argument RESPECT-PRINT-OPTIONS.
	If nil, print full value, else abbreviated value.

[-- Attachment #2: lisp-mode-2013-05-04a.patch --]
[-- Type: application/octet-stream, Size: 4131 bytes --]

diff -c lisp-mode.el lisp-mode-patched-2013-05-04.el
*** lisp-mode.el	Sat May  4 19:58:08 2013
--- lisp-mode-patched-2013-05-04.el	Sat May  4 20:32:10 2013
***************
*** 618,636 ****
  if that value is non-nil."
    :abbrev-table nil)
  
! (defun eval-print-last-sexp ()
    "Evaluate sexp before point; print value into current buffer.
- 
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger.
  
! Note that printing the result is controlled by the variables
! `eval-expression-print-length' and `eval-expression-print-level',
! which see."
!   (interactive)
    (let ((standard-output (current-buffer)))
      (terpri)
!     (eval-last-sexp t)
      (terpri)))
  
  
--- 618,635 ----
  if that value is non-nil."
    :abbrev-table nil)
  
! (defun eval-print-last-sexp (&optional respect-print-options)
    "Evaluate sexp before point; print value into current buffer.
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger.
  
! Print the full value, as if options `eval-expression-print-length' and
! `eval-expression-print-level' were both nil, unless you use a negative
! prefix argument, in which case respect the option values."
!   (interactive (list (< (prefix-numeric-value current-prefix-arg) 0)))
    (let ((standard-output (current-buffer)))
      (terpri)
!     (eval-last-sexp (if respect-print-options -1 1))
      (terpri)))
  
  
***************
*** 827,847 ****
  (defun eval-last-sexp (eval-last-sexp-arg-internal)
    "Evaluate sexp before point; print value in minibuffer.
  Interactively, with prefix argument, print output into current buffer.
! Truncates long output according to the value of the variables
! `eval-expression-print-length' and `eval-expression-print-level'.
  
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger."
    (interactive "P")
!   (if (null eval-expression-debug-on-error)
!       (eval-last-sexp-1 eval-last-sexp-arg-internal)
!     (let ((value
! 	   (let ((debug-on-error eval-last-sexp-fake-value))
! 	     (cons (eval-last-sexp-1 eval-last-sexp-arg-internal)
! 		   debug-on-error))))
!       (unless (eq (cdr value) eval-last-sexp-fake-value)
! 	(setq debug-on-error (cdr value)))
!       (car value))))
  
  (defun eval-defun-1 (form)
    "Treat some expressions specially.
--- 826,853 ----
  (defun eval-last-sexp (eval-last-sexp-arg-internal)
    "Evaluate sexp before point; print value in minibuffer.
  Interactively, with prefix argument, print output into current buffer.
! 
! When using the current buffer, print the full value, as if options
! `eval-expression-print-length' and `eval-expression-print-level' were
! both nil.  Otherwise, respect the option values.
  
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger."
    (interactive "P")
!   (let* ((print-full-value              (and eval-last-sexp-arg-internal
!                                              (natnump (prefix-numeric-value
!                                                        eval-last-sexp-arg-internal))))
!          (eval-expression-print-length  (and (not print-full-value)  eval-expression-print-length))
!          (eval-expression-print-level   (and (not print-full-value)  eval-expression-print-level)))
!     (if (null eval-expression-debug-on-error)
!         (eval-last-sexp-1 eval-last-sexp-arg-internal)
!       (let ((value
!              (let ((debug-on-error eval-last-sexp-fake-value))
!                (cons (eval-last-sexp-1 eval-last-sexp-arg-internal)
!                      debug-on-error))))
!         (unless (eq (cdr value) eval-last-sexp-fake-value)
!           (setq debug-on-error (cdr value)))
!         (car value)))))
  
  (defun eval-defun-1 (form)
    "Treat some expressions specially.

Diff finished.  Sat May  4 20:33:01 2013

Re: C-x C-e with prefix arg [patch]

[Xue Fuqiao]

On Sun, May 5, 2013 at 11:51 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > How about letting a non-negative prefix arg insert the full
>> > value (in effect, binding `eval-expression-print-length' and
>> > `eval-expression-print-level' to nil)?  And letting a negative
>> > prefix arg do what any prefix arg does today: respect the
>> > current values of `eval-expression-print-length' and
>> > `eval-expression-print-level'?
>>
>> Agreed.  Would you like to submit a patch here or to bug-gnu-emacs?
>
> Attached.
>
> I also changed `eval-print-last-sexp' similarly: a negative prefix arg for it
> does what the function always did before: print the abbreviated value.
> Otherwise it now prints the full value.

Looks fine.  Can anyone install it?  I often receive a time out when
performing `bzr update' and some other operations recently.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: C-x C-e with prefix arg

[Juri Linkov]

> How about letting a non-negative prefix arg insert the full value (in effect,
> binding `eval-expression-print-length' and `eval-expression-print-level' to
> nil)?  And letting a negative prefix arg do what any prefix arg does today:
> respect the current values of `eval-expression-print-length' and
> `eval-expression-print-level'?

Why a numeric prefix arg?  A numeric prefix usually defines countable elements,
e.g. for this case it could define the number of values to insert to the buffer
or the depth of list nesting to print.  Otherwise, a better prefix to toggle
would be `C-u' or `M-0'.  Consider the prefixes of the related commands that

1. insert to the buffer

   C-u M-x shell-command RET
   C-u M-x eval-last-sexp RET
   M-x eval-print-last-sexp RET

2. print full information

   C-u M-x what-cursor-position RET
   M-0 M-x dired-copy-filename-as-kill RET
   M-0 M-x Info-copy-current-node-name RET
   M-x eval-last-sexp RET M-x eval-last-sexp RET
   M-x eval-expression RET

Perhaps `M-0' is more suitable than `C-u' to print full information
(or the full value) where the mnemonics of `M-0' could be
"Reset `eval-expression-print-length' to nil".

See also bug#12985 for discussion about adding a prefix argument
to `eval-last-sexp' to toggle full information (or the full value).
They could be toggled simultaneously because printing the full value
with a nil `eval-expression-print-level' is applicable only to lists,
and printing full information (octal and hex representations, etc)
is applicable only to numeric values.

RE: C-x C-e with prefix arg

[Drew Adams]

> Why a numeric prefix arg?  A numeric prefix usually defines 
> countable elements,

No.

And even if you actually checked all the source code and counted and proved
that, yes, it is used to define countable elements more than 50% of the time,
I'd say "So what?".  An Emacs prefix arg can be used to do anything we want.

We should pick the most appropriate, most useful prefix-arg behavior _for the
particular command_.  Argue for a different, better behavior wrt this command,
if you like.  But "usually" doesn't, by itself, convince me (for one) when it
comes to prefix arg behavior.

> e.g. for this case it could define the number of values to 
> insert to the buffer or the depth of list nesting to print.

It could, but it doesn't.  If you want to propose either of those, go for it.

* Negative in this case is mnemonic for "less".  It hints at the
elision/abbreviation.

* Plain C-u, which is probably what most people who have been using a prefix arg
for this command have been using, now prints the full value, which is the most
useful behavior most of the time, I think.

Those were the two reasons behind the behavior I proposed.  Likewise wrt a
negative prefix arg for `eval-print-last-sexp'.

> Otherwise, a better prefix to toggle would be `C-u' or `M-0'.

Toggle?  What do you want to toggle here?  I would not want any prefix arg here
to toggle, so that every other time it had some opposite behavior.  What for?

> Consider the prefixes of the related commands that
> 
> 1. insert to the buffer
>    C-u M-x shell-command RET
>    C-u M-x eval-last-sexp RET
>    M-x eval-print-last-sexp RET
> 
> 2. print full information
>    C-u M-x what-cursor-position RET
>    M-0 M-x dired-copy-filename-as-kill RET
>    M-0 M-x Info-copy-current-node-name RET
>    M-x eval-last-sexp RET M-x eval-last-sexp RET
>    M-x eval-expression RET
> 
> Perhaps `M-0' is more suitable than `C-u' to print full 
> information (or the full value) where the mnemonics of
> `M-0' could be "Reset `eval-expression-print-length'
> to nil".

If you want to propose something different, please go for it.  Send a patch or
whatever.

But be prepared for someone like Juri L. to reply that `M-0' is "usually" for
counting and should mean only zero inserts or zeroth print level, not print full
information. ;-)

IMHO, the proposal I made is better, but I really don't care.  I never use
either `eval-last-sexp' or `eval-print-last-sexp', personally.  I use
`pp-eval-last-sexp' instead (and my own version of it), and I use *scratch* in
Emacs-Lisp mode (so C-j is not `eval-print-last-sexp').

BTW, for my patch, and something perhaps to keep in mind for yours as well:
(emacs) `Lisp Eval' should be updated to remove this sentence: "The argument's
value does not matter."

I believe that is the only doc change needed, but I could be wrong.  I searched
only the Emacs and Elisp manuals, and only for `C-x C-e', `M-:', and `C-j'.

Re: C-x C-e with prefix arg

[Juri Linkov]

> We should pick the most appropriate, most useful prefix-arg behavior
> _for the particular command_.

A numeric prefix arg is not the most appropriate, most useful
prefix-arg behavior for the particular command `eval-last-sexp'.
E.g. `C-u -42 C-x C-e' is useless and meaningless for binding
`eval-expression-print-length' and `eval-expression-print-level'
to nil (or using their default values that differ from the arg value).

>> e.g. for this case it could define the number of values to
>> insert to the buffer or the depth of list nesting to print.
>
> If you want to propose either of those, go for it.

I don't want to propose those now, but we should try to reserve
numeric prefixes for features where numbers make sense like
e.g. `C-u -42 C-x C-e' to bind `eval-expression-print-length' to the
numeric arg 42, or `C-u 42 C-x C-e' to bind `eval-expression-print-level'
to the given number.

> * Negative in this case is mnemonic for "less".  It hints at the
> elision/abbreviation.

Fine, then use the symbol `-' (just a minus sign) as the prefix arg.

> `M-0' is "usually" for counting and should mean only zero inserts or
> zeroth print level

Which is the most appropriate prefix where zero means to bind
`eval-expression-print-length' and `eval-expression-print-level'
to nil.

> IMHO, the proposal I made is better, but I really don't care.  I never use
> either `eval-last-sexp' or `eval-print-last-sexp', personally.  I use
> `pp-eval-last-sexp' instead (and my own version of it), and I use *scratch* in
> Emacs-Lisp mode (so C-j is not `eval-print-last-sexp').

I like your proposal, but I strive to find the most appropriate prefix arg
that could be shared between lists and numeric output of `C-x C-e', `M-:',
and `C-j'. i.e. the same prefix arg to define whether to print the full
list value or not, and whether to print full information about numbers
(octal, hexadecimal).  This is required for bug#12985.

RE: C-x C-e with prefix arg

[Drew Adams]

> > * Negative in this case is mnemonic for "less".  It hints at the
> > elision/abbreviation.
> 
> Fine, then use the symbol `-' (just a minus sign) as the prefix arg.

OK by me.  +1.

(I assume you mean keys `C--' and `M--', which lead to symbol `-' as the raw
prefix arg.)

> > IMHO, the proposal I made is better, but I really don't 
> > care.  I never use either `eval-last-sexp' or
> > `eval-print-last-sexp', personally.  I use
> > `pp-eval-last-sexp' instead (and my own version of it),
> > and I use *scratch* in Emacs-Lisp mode (so C-j is not
> > `eval-print-last-sexp').
> 
> I like your proposal, but I strive to find the most 
> appropriate prefix arg that could be shared between lists
> and numeric output of `C-x C-e', `M-:', and `C-j'. i.e. the
> same prefix arg to define whether to print the full
> list value or not, and whether to print full information about numbers
> (octal, hexadecimal).  This is required for bug#12985.

As I said, I really don't care whether or what changes are made.  Use your
judgment - I'm fine with whatever you decide.

---

FWIW, I also don't think, personally, that we ever should have (in Emacs 22)
cobbled a print-integer-value-in-different-radixes functionality onto the
eval-and-maybe-print functionality.

To be clear, I mean the following (mis)feature, which applies
`eval-expression-print-format' to the last evaluation value (i.e., the car of
`values'), in `eval-expression':

 "**** Typing C-x C-e twice prints the value of the integer result
  in additional formats (octal, hexadecimal, character) specified
  by the new function `eval-expression-print-format'.  The same
  function also defines the result format for `eval-expression' (M-:),
  `eval-print-last-sexp' (C-j) and some edebug evaluation functions."

    - from the NEWS, Emacs 22

Personally, I think that was a dumb - er - misguided user interface that never
should have been plopped on top of the longstanding eval-and-maybe-print
functionality.  Others are free, of course, to think it is handy and extremely
clever.

The surprise expressed by Kelly Dean in his report for bug #12985 supports my
view of the UI somewhat, I think.  The right fix is not just to document the
feature (finally, years after it was introduced) but to just rip it out.  (There
are other ways to print an integer value in various formats, and it is easy
enough to have a separate command that does just that.)  But I doubt the feature
will be removed in consequence.

Re: C-x C-e with prefix arg

[Juri Linkov]

> Personally, I think that was a dumb - er - misguided user interface that never
> should have been plopped on top of the longstanding eval-and-maybe-print
> functionality.  Others are free, of course, to think it is handy and extremely
> clever.
>
> The surprise expressed by Kelly Dean in his report for bug #12985 supports my
> view of the UI somewhat, I think.  The right fix is not just to document the
> feature (finally, years after it was introduced) but to just rip it out.  (There
> are other ways to print an integer value in various formats, and it is easy
> enough to have a separate command that does just that.)

There are many other commands that change their behavior when called twice,
e.g. running `recenter' twice doesn't recenter but unexpectedly moves
the current line to window's top.  Do you think that typing `C-l' twice
is dumb and should be ripped out and reverted to the longstanding
recentering functionality because there are other ways to do that?
(This question is rhetorical, I don't want to remove it.)

> But I doubt the feature will be removed in consequence.

The feature could be removed if we will find a better replacement.
I see at least two alternatives to improve the `eval-expression'
functionality:

1. Use the prefix arg `M-0' to request more information about the value
   printed by `C-x C-e', `M-:', and `C-j'.  Then typing `M-0 C-x C-e'
   will have the same effect as typing `C-x C-e' twice (the same way
   as typing `M-0 C-l' has the same effect as typing `C-l' twice).

2. Add a new customizable option to define the default printing format
   for the numeric values printed by `C-x C-e', `M-:', and `C-j'
   to accompany two other existing options `eval-expression-print-length'
   and `eval-expression-print-level' that define the format of the list
   values while printing list value in `eval-expression'.

RE: C-x C-e with prefix arg

[Drew Adams]

> There are many other commands that change their behavior when 
> called twice, e.g. running `recenter' twice doesn't recenter
> but unexpectedly moves the current line to window's top.
> Do you think that typing `C-l' twice is dumb and should be
> ripped out and reverted to the longstanding recentering
> functionality because there are other ways to do that?
> (This question is rhetorical, I don't want to remove it.)

No, I don't think removing that `C-l' enhancement would be an improvement (as
might be expected, since adding it was my idea).

The behavior a given command should have depends on the command (duh).  `C-l'
moves the window around point.  Repeating it just moves the window to two other
positions around point.  Pretty natural.  And a prefix arg gives more precise
control over the positioning.

`C-x C-e' etc. are about evaluating a sexp.  Letting you optionally (and not by
default) print that value in the current buffer is a natural extension.

I don't see the integer radix printing in the same way.  Rather, as you suggest
below, it is about formatting the value in a different way.  That is, it is more
akin to the formatting that `eval-expression-print-length' and
`eval-expression-print-level' do.

> > But I doubt the feature will be removed in consequence.
> 
> The feature could be removed if we will find a better replacement.
> I see at least two alternatives to improve the `eval-expression'
> functionality:
> 
> 1. Use the prefix arg `M-0' to request more information about 
>    the value
>    printed by `C-x C-e', `M-:', and `C-j'.  Then typing `M-0 C-x C-e'
>    will have the same effect as typing `C-x C-e' twice (the same way
>    as typing `M-0 C-l' has the same effect as typing `C-l' twice).

I have no great objection.  But I prefer your other suggestion:

> 2. Add a new customizable option to define the default printing format
>    for the numeric values printed by `C-x C-e', `M-:', and `C-j'
>    to accompany two other existing options
>    `eval-expression-print-length' and `eval-expression-print-level'
>    that define the format of the list values while printing list
>    value in `eval-expression'.

That makes sense to me.  And like those other options, it should be ignored
except via `C--' or `M--'.

Re: C-x C-e with prefix arg

[Juri Linkov]

> And like those other options, it should be ignored except via `C--' or `M--'.

The default values should not be ignored by default.

The default values of `eval-expression-print-length' and
`eval-expression-print-level' should be respected by all
`eval-expression' related functions by default because
they are _default_ values.

An additional prefix arg like `M--' could be used to
override the default values.  Although `M-0' would make
more sense because it will display more information
(the full value of the list printed by `M-0 C-x C-e').

RE: C-x C-e with prefix arg

[Drew Adams]

> > And like those other options, it should be ignored except 
> > via `C--' or `M--'.
> 
> The default values should not be ignored by default.
> 
> The default values of `eval-expression-print-length' and
> `eval-expression-print-level' should be respected by all
> `eval-expression' related functions by default because
> they are _default_ values.
> 
> An additional prefix arg like `M--' could be used to
> override the default values.  Although `M-0' would make
> more sense because it will display more information
> (the full value of the list printed by `M-0 C-x C-e').

We've been through all of this before, I believe.

1. We've already spoken about `M-- and `C--' vs `M-0'.  The former (which was
your proposed restriction of my initial proposal of any negative prefix arg) is
preferable to the latter, IMO.  We've been through the reasons.

2. The default values of those options will, by my proposal, be for use only
with `M--' and `C--' (for `eval-last-sexp'), not for use with a non-negative
prefix arg.  That is the design I proposed.

There is nothing wrong with offering options that take effect only in certain
circumstances.  Just because an option has a default value (and every option
does) does not mean that the option takes effect by default for all commands
that make might use of it.  It is fine for a given command to make use of it in
only some contexts.

IMO, it is important that `C-x C-e' with a plain `C-u' (more generally, with a
non-negative prefix arg) ignore those options altogether and print the full
value.  That was the _point_ of my suggestion, from the beginning.  Most of the
time when you want to print the value, you want the whole value, not an
abbreviation.  That's my claim.

3. The _default_ behavior of the command, on the other hand, does not print
anything!  We are discussing only the behavior of the command when the value is
printed in the current buffer, which for `C-x C-e' means when you use a prefix
arg.

Re: C-x C-e with prefix arg

[Juri Linkov]

> IMO, it is important that `C-x C-e' with a plain `C-u' (more generally, with
> a non-negative prefix arg) ignore those options altogether and print the
> full value.  That was the _point_ of my suggestion, from the beginning.

Isn't truncated output intended mostly for beginners
to not overwhelm them with long output?  If yes,
then it should be used by default.

> Most of the time when you want to print the value, you want the whole value,
> not an abbreviation.  That's my claim.

I agree that most of the time you want the whole value.
That's why I have in ~/.emacs ;-)

  (custom-set-variables
   '(eval-expression-print-length nil)
   '(eval-expression-print-level nil)

But the question is what should be the default behavior.
It seems this feature for the elided display of long lists
was created with the intention to be used by default.

RE: C-x C-e with prefix arg

[Drew Adams]

> > IMO, it is important that `C-x C-e' with a plain `C-u' 
> > (more generally, with a non-negative prefix arg) ignore
> > those options altogether and print the
> > full value.  That was the _point_ of my suggestion, from 
> > the beginning.
> 
> Isn't truncated output intended mostly for beginners
> to not overwhelm them with long output?  If yes,
> then it should be used by default.

For me, truncated output is useful for anyone who wants to see the overall
picture and doesn't need the exact value.

That is especially important for printing to the echo area.

To me, it does not make sense as the default behavior for printing the value
into the current buffer.  Why?  Because, as I said at the beginning, I think
that most users do that in order to _do something_ with the value - something
that requires the full value.  Typically, I want to edit it or perhaps examine
parts of it in detail.

You don't have to be an expert to want to do such things.  By your logic, `C-h
v' should also print using elision.

When I do `C-h v bookmark-alist' I really want to see the full alist.  But maybe
another user does not.  We could imagine options governing printing there too.

My point is that wanting to see the full value is not something limited to
experts, and wanting to see only an executive overview of the value is not
something limited to novices.  A better distinction is wrt the buffer,
minibuffer or other, and we can make a reasonable guess as to the need (full or
partial view) for each kind of buffer.

I've made my suggestion wrt such guessing: when users print the value to the
current buffer, I think they usually want the full value.

> > Most of the time when you want to print the value, you want 
> > the whole value, not an abbreviation.  That's my claim.
> 
> I agree that most of the time you want the whole value.
> That's why I have in ~/.emacs ;-)
> 
>   (custom-set-variables
>    '(eval-expression-print-length nil)
>    '(eval-expression-print-level nil)
> 
> But the question is what should be the default behavior.
> It seems this feature for the elided display of long lists
> was created with the intention to be used by default.

Who knows what was behind the original design?  Maybe someone just took the
behavior that made sense for the minibuffer and continued it for the current
buffer too.  Maybe someone was too lazy to figure out another way to do things.
Maybe someone, like you apparently, felt that giving users options to configure
would give them enough control over the printing.

IMO, users should have a quick way of getting the full value in the current
buffer, _even if_ they generally prefer the partial value and have reflected
that more general preference in the user options.

If you really wanted to complicate things, you could make the option record a
preference for the minibuffer and another one for the current buffer.  But even
then, maybe a user would want to sometimes choose another behavior on the fly
(e.g., using a prefix arg).

Re: C-x C-e with prefix arg

[Juri Linkov]

> By your logic, `C-h v' should also print using elision.

`C-h v' uses the special treatment of large values too:
it moves long lists to the end of the *Help* buffer
and puts the text "Its value is shown below" on the top.
To see the full value, you have to click the button "[below]".

Similarly, you have to click on the abbreviated list
printed by `C-x C-e' to see its full value.

> IMO, users should have a quick way of getting the full value in the current
> buffer, _even if_ they generally prefer the partial value and have reflected
> that more general preference in the user options.

Currently the quickest way to get the full value is `C-u C-x C-e C-b RET'
(`C-b' moves point to the abbreviated list where `RET' is bound to
`last-sexp-toggle-display').  Implementing a shorter key sequence to do the
same `M-0 C-x C-e' or `M-- C-x C-e' like you proposed is a good improvement.
So I see no need to change the default behavior of `C-u C-x C-e'
from printing an abbreviated list to printing the full value
since both key sequences will have the same length.

RE: C-x C-e with prefix arg

[Drew Adams]

> > By your logic, `C-h v' should also print using elision.
> 
> `C-h v' uses the special treatment of large values too:
> it moves long lists to the end of the *Help* buffer
> and puts the text "Its value is shown below" on the top.
> To see the full value, you have to click the button "[below]".

No, you don't have to click any button.  The full value is shown, without you
having to do anything at all.  It's just there, period.  There is no
intermediate, partial value printed, ever.

And this is the case even for a help command, not for a command that inserts the
value in the buffer, for you to edit or otherwise use.  IOW, even just for help,
Emacs gives you the full value.

> Similarly, you have to click on the abbreviated list
> printed by `C-x C-e' to see its full value.

Not similar - see above.  You're twisting things.

For `C-x C-e', the full value should be printed when you print to the current
buffer.  If you instead want to insert only part of the value, then you can jump
through a (minor) extra hoop: `C--' instead of `C-u'.  Neither is harder than
the other, of course, but `M--' is less commonly used by some users.

People should not have to guess that they can "click on the abbreviated list
printed by `C-x C-e' to see its full value."  That's nuts, IMHO.

> > IMO, users should have a quick way of getting the full 
> > value in the current buffer, _even if_ they generally prefer
> > the partial value and have reflected that more general preference
> > in the user options.
> 
> Currently the quickest way to get the full value is `C-u C-x 
> C-e C-b RET' (`C-b' moves point to the abbreviated list where
> `RET' is bound to `last-sexp-toggle-display').

That's crazy.  No one should have to guess that and then jump through such
hoops.  Who would think that `C-b RET' would magically give them the full value?

When you print to the current buffer, you _usually_ want the full value.  That's
my assumption, and I'm sticking to it.  That most common use case should be
simple to realize.  Let people jump through a (minor) hoop if they really want
to insert only an abbreviated value in the current buffer.

> Implementing a shorter key sequence to do the same `M-0 C-x C-e' or
> `M-- C-x C-e' like you proposed is a good improvement.

I most certainly did not propose any such thing.  That's your proposal (I
guess).  Saying that it is my proposal and that it is a good improvement is a
bit disingenuous.

I proposed that anytime you print to the current buffer, except if you jump
through the minor hoop of using `M--', you should get the full value printed.

> So I see no need to change the default behavior of `C-u C-x C-e'
> from printing an abbreviated list to printing the full value
> since both key sequences will have the same length.

We disagree.

But let me say it again: I really don't care, beyond trying to improve Emacs for
others.  For my own use, `C-x C-e' is `pp-eval-last-sexp', and `M-:' is
`icicle-pp-eval-expression' (like `pp-eval-expression').  IOW, I already get
behavior similar to what I proposed for Emacs.  Always have.

So if you want to go with your proposal rather than what I suggested in this
thread, please do so.  But please stop saying that it is my proposal.

Re: C-x C-e with prefix arg

[Juri Linkov]

> So if you want to go with your proposal rather than what I suggested in this
> thread, please do so.  But please stop saying that it is my proposal.

In fact, I see your two proposals:

1. Add a prefix arg to `C-x C-e' to control the variables
  `eval-expression-print-level' and `eval-expression-print-length'.
  This was the first question in your message that started this thread:
  "How about letting the particular prefix arg control whether to print
   the full value?"

2. And your second question was "How about letting a non-negative prefix arg
   insert the full value?".  Your second proposal changes the default behavior
   of `C-x C-e' to insert the full value by default.

I agreed that the first is an improvement, but have doubts about the second.