Eli Zaretskii 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.