bug#16828: 24.3.50; eval-expression, character representation of integer results time-consuming

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

> I would suggest to also mention eval-expression here.

Right, I also noticed eval-expression-print-format's docstring refers to
`prin1' which seems to be wrong.

 (defcustom eval-expression-print-maximum-character 127
   "The largest integer that will be displayed as a character.
-This affects printing by `eval-expression-print-format'."
+This affects printing by `eval-expression' (via
+`eval-expression-print-format')."
   :group 'lisp
   :type 'integer
   :version "26.1")
 
 (defun eval-expression-print-format (value)
   "If VALUE in an integer, return a specially formatted string.
 This string will typically look like \" (#o1, #x1, ?\\C-a)\".
 If VALUE is not an integer, nil is returned.
-This function is used by functions like `prin1' that display the
-result of expression evaluation."
+This function is used by commands like `eval-expression' that
+display the result of expression evaluation."

>> +(octal, hexadecimal, and character if
>> +@code{eval-expression-print-maximum-character} allows it).
>
> Please add a "see below" here, as the description of the variable is
> several dozens of lines farther.

Right.  Is it okay to have nested parentheses?  I use this quite often
when I write emails and such, but I have the idea it might be frowned
upon in more formal contexts.

+@code{eval-expression-print-maximum-character} (see below) allows it).

>
> This is too terse, IMO; please state explicitly that values larger
> than this will not be displayed as characters.

Yeah, I have a tendency to be overly terse.

+@code{eval-expression-print-maximum-character} prevents integers which
+are larger than it from being displayed as characters.

v3-0002-Limit-integers-printed-as-characters-Bug-16828.patch
Description: patch