Subject: bug#43866: 26.3; italian postfix additions

From: Lars Ingebrigtsen <[email-masked]>
Date: Sat, 30 Apr 2022 14:19:32 +0200

Eli Zaretskii <[email-masked]> writes:

>> +  DEFVAR_LISP ("print-integers-as-chars", Vprint_integers_as_chars,
>> +	       doc: /* Print integers as characters.  */);
>> +  Vprint_integers_as_chars = Qnil;
>
> I wonder whether it wouldn't be cleaner to add another optional
> argument to prin1, and let it bind some internal variable so that
> print_object does this, instead  of exposing this knob to Lisp.
> Because print_object is used all over the place, and who knows what
> will this do to other callers?

There's also prin1-to-string, and adding a parameter to these functions
just for this doesn't seem quite right.

However, I agree with you that adding a new print-* variable is bad, too
(because users will invariably set them in .emacs and then things break
in some obscure package).

So I wonder whether we could come up with a new convention for print
variables like this, which would allow us to extend printing more
without adding new print variables.

What about -- adding a new parameter to prin1 and prin1-to-string that's
a plist of printing features?  That is, something like:

(prin1 object nil '(length 20 integers-as-chars t))

And this would allow us to introduce a special value for that parameter,
like t, which means "use the standard values for everything".

That means we could get rid of the gazillion places where we have

(let ((print-length nil)
      (print-level nil))
  (prin1 object))

That would instead just be (prin1 object nil t).  (And the same with
prin1-to-string.)  This would hopefully be less error-prone than what we
have today -- we've had so many bug reports from packages forgetting to
bind one or the other when saving data.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no