From: Drew Adams <drew.adams@oracle.com>
To: ndame <laszlomail@protonmail.com>,
Michael Heerdegen <michael_heerdegen@web.de>
Cc: "53507@debbugs.gnu.org" <53507@debbugs.gnu.org>,
"larsi@gnus.org" <larsi@gnus.org>,
"46092@debbugs.gnu.org" <46092@debbugs.gnu.org>
Subject: bug#46092: [External] : bug#53507: 27.1; syntax highlight in the eval-expression prompt
Date: Wed, 26 Jan 2022 19:53:33 +0000 [thread overview]
Message-ID: <SJ0PR10MB548805B80B3373752C7063FAF3209@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <_4HT5Zir6jtMz0tMVkAv21AKQoFlXcqM-W6PQki147C7hd47OGx6D-bN_3pM5ckEJ8kSeu0oZ3amuodEoL7dPrn4DTJ3f9YFuoaAIWsRyJ0=@protonmail.com>
> So then I guess it's only a matter of merging the minibuffer
> keymap with emacs lisp mode map in the eval-expression prompt.
FWIW -
I know that this enhancement request is about having
Lisp font-locking while typing a sexp to evaluate.
My remarks are only partly related, I guess, and are
offered as food for thought.
1. Font-locking a sexp you're typing isn't very
important.
Not saying it can't or shouldn't happen. But
compared to font-locking the _resulting value_,
it's really not so important, IMHO.
2. Turning on `emacs-lisp-mode' for reading the sexp
is overkill. Unless you prevent it, it entails
running the mode hook, which can do all kinds of
things and might take a while. It's likely to be
problematic.
3. Although in principle it's only orthogonal, what
I'd propose is to concentrate on the _result_
sexp, instead of the input sexp to evaluate.
___
This is what I do, for #3. I think it, or similar,
makes sense also for vanilla Emacs:
1. Bind `M-:' to `pp-eval-expression', not to
`eval-expression'. This means you can get the
output in the echo area or a separate buffer,
and that buffer can be better Lisp-enabled:
font-lock, undo, `emacs-lisp-mode'.
2. Optionally show the result in a tooltip.
Provide a user option, but commands can flip
the behavior on the fly (with a prefix arg).
3. `pp-display-expression':
* When result is shown in a buffer: Put
buffer in `emacs-lisp-mode', with undo
and font-locked.
* But use NO `emacs-lisp-mode-hook' or
`change-major-mode-hook'.
`pp-eval-expression':
* Read the input sexp with completion.
Completion uses a PP+ keymap, which is like
`read-expression-map' but with some Elisp
key bindings.
* By default, use `pp-display-expression'.
But with non-zero prefix arg insert result
into current buffer, with or without
double-quotes if result is a string (prefix
arg < 0 means without).
* Respect pp versions of print options:
`pp-eval-expression-print-length',
`pp-eval-expression-print-level', and
`pp-max-tooltip-size'. (No reason to
force the same behavior for pretty-printing
as for nonpretty-printing.)
* Respect `eval-expression-debug-on-error'.
* Return result of evaluation (as well as
having it as car variable `values').
The code for pp+.el is here:
https://www.emacswiki.org/emacs/download/pp%2b.el
next prev parent reply other threads:[~2022-01-26 19:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 17:23 bug#53507: 27.1; syntax highlight in the eval-expression prompt ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-25 12:52 ` bug#46092: " Lars Ingebrigtsen
2022-01-25 13:17 ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-25 13:23 ` bug#46092: " Lars Ingebrigtsen
2022-01-25 13:28 ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-26 0:13 ` bug#46092: " Michael Heerdegen
2022-01-26 6:14 ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-26 19:53 ` Drew Adams [this message]
2022-01-26 23:39 ` bug#46092: [External] : " Michael Heerdegen
2022-01-27 0:06 ` bug#53507: " Drew Adams
2022-01-27 3:08 ` bug#46092: " ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-27 3:19 ` bug#53507: " Drew Adams
2022-01-27 9:28 ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-27 23:44 ` bug#46092: " Drew Adams
2022-01-26 0:16 ` bug#53507: bug#46092: " Michael Heerdegen
2022-01-26 14:41 ` Lars Ingebrigtsen
2022-01-26 16:39 ` bug#53507: " Michael Heerdegen
2022-01-27 15:34 ` Lars Ingebrigtsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB548805B80B3373752C7063FAF3209@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=46092@debbugs.gnu.org \
--cc=53507@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=laszlomail@protonmail.com \
--cc=michael_heerdegen@web.de \
/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 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).