bug#66267: Document cl-print.el in the CL manual.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 10 Oct 2023 20:42:13 +0000
> Cc: monnier@iro.umontreal.ca, 66267@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > > +should respect @code{print-length}, @code{print-level}, and
> > > > > +@code{cl-print-string-length}.  @var{limit} may be @code{nil} or zero
> > > > > +in which case @var{print-function} will be called with these settings
> > > > > +bound to @code{nil}, and it can also be @code{t} in which case
> > > > > +@var{print-function} will be called with their current values.
> > > > > +
> > > > > +Use this function with @code{cl-prin1} to print an object,
> > > > > +abbreviating it with ellipses to fit within a size limit.
> > > >                         ^^^^^^^^
> > > > "ellipsis"
> 
> > > No.  "EllipsEs" is the plural of "ellipsIs".
> 
> > ??? You say "abbreviating it with ellipses".  "It" is singular, so it
> > gets abbreviated with only one ellipsis, not with several ones.
> 
> Not necessarily.  Something like a cons structure or vector printed by
> cl-prin1 can have several, or even many ellipses in it.  Last week I got
> a line from an ERT backtrace containing 42 ellipses - which incidentally
> made it nearly useless for debugging.

Then something like this is in order, I think:

  Use this function with @code{cl-prin1} to print an object, possibly
  abbreviating it with one or more ellipses to fit within the size
  limit.

> By the way, I forgot one detail about the patch.  I've written it on the
> assumption that bug #66392 "Add raw printing for byte compiled functions
> to cl-prin1, etc." gets OK'd.  Stefan M. has already explicitly expressed
> no objection to it.  If that bug isn't OK, it's a simple matter to amend
> the cl.texi patch.  Would you take a quick peep at it, please?  Thanks!

I have no objections to it.