GNU bug report logs - #53592
26.3; Bind `M-:' to `pp-eval-expression' and enhance output

Previous Next

To reply to this bug, email your comments to 53592 AT debbugs.gnu.org.

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.3; Bind `M-:' to `pp-eval-expression' and enhance output
Date: Thu, 27 Jan 2022 23:35:22 +0000

[Message part 1 (text/plain, inline)]

Enhancement request.  Feel free to split into separate requests, if you
think that's appropriate.  To me, all of what I suggest is related.

1. Bind `M-:' to `pp-eval-expression' by default, not to
   `eval-expression' - makes the input reading better and the output
   more useful.

2. Add keymap `pp-read-expression-map' (or similar).  It binds keys for
   `lisp-indent-line', `lisp-complete-symbol', `indent-sexp',
   `eval-defun', and `indent-pp-sexp'.

3. Define and use `pp-read--expression' instead of `read--expression'.
   (Only difference is that it uses `pp-read-expression-map'.)

2. Add option `pp-max-tooltip-size', so commands `pp-eval-last-sexp' and
  `pp-eval-expression' can optionally show output in a tooltip, and
  control its size.

3. Add options `pp-eval-expression-print-length' and
   `pp-eval-expression-print-level', which act like `print-length' and
   `print-level', but only for pretty-printing.  (No reason to suppose
   that the same values are appropriate for general printing and for
   pretty-printing.)  See definitions below.

4. Redefine `pp-display-expression', to do the following:
   a. Respect option `pp-max-tooltip-size'.
   b. Use no `emacs-lisp-mode-hook' or `change-major-mode-hook'.
   c. Call `font-lock-fontify-buffer'.
   d. Provide undo to buffer OUT-BUFFER-NAME.

5. Redefine `pp-eval-expression' to do the following:

   a. Add optional args, corresponding to prefix-arg behaviors.

      `INSERT-VALUE': non-nil (non-zero prefix arg) lets the command act
        the way `eval-expression' acts: inserts the result in the
        current buffer.

      `SWAP-TOOLTIP': non-nil (zero prefix arg) swaps the behavior
        defined by `pp-max-tooltip-size': if option says use tooltip
        then don't, and vice versa.

   b. With no prefix arg, respect `pp-max-tooltip-size'.  If tooltip not
      used then if value fits on one (frame-width) line then show value
      in the echo area.  Otherwise, show it in buffer `*Pp Eval
      Output*'.

   c. With negative prefix arg, print string values with "...".  With
      positive arg, omit the double-quotes.

   d.  Respect options `pp-eval-expression-print-length',
      `pp-eval-expression-print-level', `pp-max-tooltip-size', and
      `eval-expression-debug-on-error'.

6. Redefine `pp-eval-last-sexp': Same as `pp-eval-expression' wrt
   optional args `INSERT-VALUE' and `SWAP-TOOLTIP', and options
   `pp-eval-expression-print-length', `pp-eval-expression-print-level',
   `pp-max-tooltip-size', and `eval-expression-debug-on-error'.

The code (`pp+.el') is attached.  It's offered as is.  If it's generally
acceptable I can provide a patch.  If not, then please consider doing
what's requested in another way.


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19043
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

[pp+.el (application/octet-stream, attachment)]

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

From: ndame <laszlomail <at> protonmail.com>
To: "53592 <at> debbugs.gnu.org" <53592 <at> debbugs.gnu.org>
Subject: bug#53592: 26.3; Bind `M-:' to `pp-eval-expression' and enhance output
Date: Fri, 28 Jan 2022 11:04:10 +0000

[Message part 1 (text/plain, inline)]

You put too many things in the bug IMO. It's a lot. We talked about better eval output,
so this bug should be about that. The output.

Changing the output can be done in parallel to implementing syntax highlight which
the other bug is about. Mixing rebinding M-: here is just confusing things.

Like when you change a system you don't submit a single huge patch which changes
many things at once, because it's harder to see through. You submit multiple smaller
patches which are easier to digest. Similarly, bugs should have a narrower focus and
when that is done, then there can be a next bug about a some other change, etc.

Just my 2 cents..

[Message part 2 (text/html, inline)]

Previous Next

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