* bug#12985: eval-last-sexp looks broken when executed twice @ 2012-11-25 1:52 Kelly Dean 2012-11-25 8:44 ` Andreas Schwab 0 siblings, 1 reply; 6+ messages in thread From: Kelly Dean @ 2012-11-25 1:52 UTC (permalink / raw) To: 12985 Using 24.2, type: 5 Then do C-x C-e, and as expected it echoes: 5 But then do C-x C-e again, and unexpectedly it echoes: 5 (#o5, #x5, ?\C-e) The same thing happens if you type 5 then do C-u C-x C-e C-u C-x C-e; first as expected you get: 55 Then unexpectedly you get: 5555 (#o67, #x37, ?7) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12985: eval-last-sexp looks broken when executed twice 2012-11-25 1:52 bug#12985: eval-last-sexp looks broken when executed twice Kelly Dean @ 2012-11-25 8:44 ` Andreas Schwab 2012-11-27 12:41 ` Kelly Dean 0 siblings, 1 reply; 6+ messages in thread From: Andreas Schwab @ 2012-11-25 8:44 UTC (permalink / raw) To: Kelly Dean; +Cc: 12985 Kelly Dean <kellydeanch@yahoo.com> writes: > Using 24.2, type: > 5 > Then do C-x C-e, and as expected it echoes: > 5 > But then do C-x C-e again, and unexpectedly it echoes: > 5 (#o5, #x5, ?\C-e) It's not a bug, it's a feature of eval-expression-print-format. 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." ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12985: eval-last-sexp looks broken when executed twice 2012-11-25 8:44 ` Andreas Schwab @ 2012-11-27 12:41 ` Kelly Dean 2013-05-06 19:57 ` Juri Linkov 2013-12-19 21:03 ` Juri Linkov 0 siblings, 2 replies; 6+ messages in thread From: Kelly Dean @ 2012-11-27 12:41 UTC (permalink / raw) To: Andreas Schwab; +Cc: 12985 > It's not a bug, it's a feature of > eval-expression-print-format. Sorry for the mistaken bug report. I should have read the source code, and reported this bug as a documentation deficiency instead, since the help pages for eval-last-sexp and eval-print-last-sexp say nothing about eval-expression-print-format or about behaving differently when called twice. I propose adding to the doc strings for eval-last-sexp and eval-print-last-sexp, "If the value is an integer, and this command is called twice in succession, then in addition to printing the decimal representation, also print the octal and hex representations and char interpretation of the value." BTW the doc string for eval-last-sexp says "print value in minibuffer." which should be "print value into echo area." Also, eval-expression-print-format omits the char if the invoking command name is not eval-last-sexp or eval-print-last-sexp. Why? For example, if I do M-x eval-expression [ret] 5 [ret] I only get 5 (#o5, #x5) I don't see why not simplify it to: (defun eval-expression-print-format (value) "Format VALUE as a result of evaluated expression if invoked twice, invoked as a name other than eval-last-sexp or eval-print-last-sexp, or if in debug mode. Return a formatted string that is displayed in the echo area in addition to the value printed by prin1 in functions which display the result of expression evaluation." (if (and (integerp value) (or (not (memq this-command '(eval-last-sexp eval-print-last-sexp))) (eq this-command last-command) (if (boundp 'edebug-active) edebug-active))) (let ((char-string (prin1-char value))) (if char-string (format " (#o%o, #x%x, %s)" value value char-string) (format " (#o%o, #x%x)" value value))))) Even then the design seems wrong. It's designed to avoid producing the string the first time eval-last-sexp or eval-print-last-sexp is called, regardless of whether the result will be displayed in the echo area (in which case I don't see any reason to avoid it) or printed into the buffer (in which case avoiding it is good since the user probably wants just the decimal representation). And it makes one of my custom functions fail to work the same as eval-last-sexp when intended, which is what brought all this to my attention in the first place: (defun eval-region-or-last-sexp () "Eval region if active; otherwise, eval last sexp and print value into echo area or, with prefix argument, into current buffer. See `eval-region' and `eval-last-sexp' for details." (interactive) (if mark-active (call-interactively 'eval-region) (call-interactively 'eval-last-sexp))) I can fix my function using (setq this-command 'eval-last-sexp), but that's a kludge. It seems a better design would be to always include the string, even the first time, when displaying in the echo area, and never include the string when printing into the buffer, regardless of the invoking command name. This is simpler, and it's how eval-expression already works. Regarding lack of hard word wrap in the doc strings above, it's because I propose (add-hook 'help-mode-hook (lambda () (toggle-word-wrap 1))) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12985: eval-last-sexp looks broken when executed twice 2012-11-27 12:41 ` Kelly Dean @ 2013-05-06 19:57 ` Juri Linkov 2013-05-08 21:19 ` Juri Linkov 2013-12-19 21:03 ` Juri Linkov 1 sibling, 1 reply; 6+ messages in thread From: Juri Linkov @ 2013-05-06 19:57 UTC (permalink / raw) To: Kelly Dean; +Cc: 12985 > Even then the design seems wrong. It's designed to avoid producing the > string the first time eval-last-sexp or eval-print-last-sexp is > called, regardless of whether the result will be displayed in the echo > area (in which case I don't see any reason to avoid it) or printed > into the buffer (in which case avoiding it is good since the user > probably wants just the decimal representation). > > It seems a better design would be to always include the string, even > the first time, when displaying in the echo area, and never include > the string when printing into the buffer, regardless of the invoking > command name. This is simpler, and it's how eval-expression already works. Thank you for suggesting a new design. I agree it is better than the current design. The patch below implements it and removes the feature of behaving differently when called twice. > And it makes one of my custom functions fail to work the same as > eval-last-sexp when intended, which is what brought all this to my > attention in the first place: > > (defun eval-region-or-last-sexp () > (interactive) > (if mark-active > (call-interactively 'eval-region) > (call-interactively 'eval-last-sexp))) > > I can fix my function using (setq this-command 'eval-last-sexp), but > that's a kludge. The function `eval-expression-print-format' in this patch doesn't compare the command name with `this-command' anymore, so your function `eval-region-or-last-sexp' above should work now as intended. Additionally, it allows a new prefix arg `M-0' to be used as `M-0 C-x C-e' to print more information with the octal and hex representations into the current buffer. It replaces the old feature of calling 'C-x C-e' twice to do the same. The documentation could be updated accordingly later. === modified file 'lisp/simple.el' --- lisp/simple.el 2013-04-18 13:15:08 +0000 +++ lisp/simple.el 2013-05-06 19:57:05 +0000 @@ -1280,12 +1280,10 @@ (defun eval-expression-print-format (val in addition to the value printed by prin1 in functions which display the result of expression evaluation." (if (and (integerp value) - (or (not (memq this-command '(eval-last-sexp eval-print-last-sexp))) - (eq this-command last-command) - (if (boundp 'edebug-active) edebug-active))) + (or (eq standard-output t) + (zerop (prefix-numeric-value current-prefix-arg)))) (let ((char-string - (if (or (if (boundp 'edebug-active) edebug-active) - (memq this-command '(eval-last-sexp eval-print-last-sexp))) + (if (char-displayable-p value) (prin1-char value)))) (if char-string (format " (#o%o, #x%x, %s)" value value char-string) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12985: eval-last-sexp looks broken when executed twice 2013-05-06 19:57 ` Juri Linkov @ 2013-05-08 21:19 ` Juri Linkov 0 siblings, 0 replies; 6+ messages in thread From: Juri Linkov @ 2013-05-08 21:19 UTC (permalink / raw) To: Kelly Dean; +Cc: 12985 >> It seems a better design would be to always include the string, even >> the first time, when displaying in the echo area, and never include >> the string when printing into the buffer, regardless of the invoking >> command name. This is simpler, and it's how eval-expression already works. > > Thank you for suggesting a new design. I agree it is better > than the current design. The patch below implements it and > removes the feature of behaving differently when called twice. Since this feature will use a better design now, more commands could benefit from this feature: `C-M-x' (`eval-defun' and `edebug-eval-defun') and `ielm-send-input'. === modified file 'lisp/emacs-lisp/lisp-mode.el' --- lisp/emacs-lisp/lisp-mode.el 2013-05-06 20:23:40 +0000 +++ lisp/emacs-lisp/lisp-mode.el 2013-05-08 21:12:52 +0000 @@ -928,6 +928,8 @@ (defun eval-defun-2 () ;; will make eval-region return. (goto-char ,end) ',form)))))) + (let ((str (eval-expression-print-format (car values)))) + (if str (princ str))) ;; The result of evaluation has been put onto VALUES. So return it. (car values)) === modified file 'lisp/emacs-lisp/edebug.el' --- lisp/emacs-lisp/edebug.el 2013-04-08 02:21:59 +0000 +++ lisp/emacs-lisp/edebug.el 2013-05-08 21:17:06 +0000 @@ -528,7 +528,10 @@ (defun edebug-eval-defun (edebug-it) (put (nth 1 form) 'saved-face nil))))) (setq edebug-result (eval (eval-sexp-add-defvars form) lexical-binding)) (if (not edebugging) - (princ edebug-result) + (prog1 + (princ edebug-result) + (let ((str (eval-expression-print-format edebug-result))) + (if str (princ str)))) edebug-result))) === modified file 'lisp/ielm.el' --- lisp/ielm.el 2013-01-01 09:11:05 +0000 +++ lisp/ielm.el 2013-05-08 21:10:23 +0000 @@ -408,7 +408,8 @@ (defun ielm-eval-input (input-string) (condition-case nil ;; Self-referential objects cause loops in the printer, so ;; trap quits here. May as well do errors, too - (setq ielm-output (concat ielm-output (pp-to-string ielm-result))) + (setq ielm-output (concat ielm-output (pp-to-string ielm-result) + (eval-expression-print-format ielm-result))) (error (setq ielm-error-type "IELM Error") (setq ielm-result "Error during pretty-printing (bug in pp)")) (quit (setq ielm-error-type "IELM Error") ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12985: eval-last-sexp looks broken when executed twice 2012-11-27 12:41 ` Kelly Dean 2013-05-06 19:57 ` Juri Linkov @ 2013-12-19 21:03 ` Juri Linkov 1 sibling, 0 replies; 6+ messages in thread From: Juri Linkov @ 2013-12-19 21:03 UTC (permalink / raw) To: Kelly Dean; +Cc: 12985-done > It seems a better design would be to always include the string, even > the first time, when displaying in the echo area, and never include > the string when printing into the buffer, regardless of the invoking > command name. This is simpler, and it's how eval-expression > already works. This is implemented now, including other discussed changes. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-19 21:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-25 1:52 bug#12985: eval-last-sexp looks broken when executed twice Kelly Dean 2012-11-25 8:44 ` Andreas Schwab 2012-11-27 12:41 ` Kelly Dean 2013-05-06 19:57 ` Juri Linkov 2013-05-08 21:19 ` Juri Linkov 2013-12-19 21:03 ` Juri Linkov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).