unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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

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