bug#43866: 26.3; italian postfix additions

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  rpluim@gmail.com,  43866@debbugs.gnu.org
> Date: Sat, 30 Apr 2022 14:19:32 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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))

My worries were mainly because this new variable affected print_object
directly, and because print_object is called in many places unrelated
to prin1 etc.

I'm okay with what you propose, but I don't see how would that
eliminate the reasons for my worries.  The implementation of the
effect of this argument is still in print_object, so the question that
is of interest to me is how will we communicate these arguments to
print_object?