From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#66267: Document cl-print.el in the CL manual. Date: Tue, 10 Oct 2023 20:42:13 +0000 Message-ID: References: <83fs2wyl5p.fsf@gnu.org> <83v8bevhv2.fsf@gnu.org> <83bkd6ux40.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11317"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66267@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 10 22:42:58 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qqJZB-0002g6-Vn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Oct 2023 22:42:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qqJYx-000120-RX; Tue, 10 Oct 2023 16:42:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qqJYu-00011O-Qk for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2023 16:42:40 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qqJYu-0006sA-IP for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2023 16:42:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qqJZF-0002Yy-NB for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2023 16:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Oct 2023 20:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66267 X-GNU-PR-Package: emacs Original-Received: via spool by 66267-submit@debbugs.gnu.org id=B66267.16969705699603 (code B ref 66267); Tue, 10 Oct 2023 20:43:01 +0000 Original-Received: (at 66267) by debbugs.gnu.org; 10 Oct 2023 20:42:49 +0000 Original-Received: from localhost ([127.0.0.1]:36993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qqJZ2-0002Up-Ii for submit@debbugs.gnu.org; Tue, 10 Oct 2023 16:42:48 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:50364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qqJYx-0002UL-Hd for 66267@debbugs.gnu.org; Tue, 10 Oct 2023 16:42:46 -0400 Original-Received: (qmail 39239 invoked by uid 3782); 10 Oct 2023 22:42:15 +0200 Original-Received: from acm.muc.de (pd953a92c.dip0.t-ipconnect.de [217.83.169.44]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 10 Oct 2023 22:42:14 +0200 Original-Received: (qmail 14162 invoked by uid 1000); 10 Oct 2023 20:42:13 -0000 Content-Disposition: inline In-Reply-To: <83bkd6ux40.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272232 Archived-At: Hello, Eli. On Tue, Oct 10, 2023 at 21:54:23 +0300, Eli Zaretskii wrote: > > Date: Tue, 10 Oct 2023 16:49:29 +0000 > > Cc: monnier@iro.umontreal.ca, 66267@debbugs.gnu.org > > From: Alan Mackenzie > > > > +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. New cl-print-object methods are likely to be for complex structures rather than one-dimensional atoms, hence are likely to abbreviate several substructures rather than just the top-level one. Would, perhaps, the following be better: "Use this function with @code{cl-prin1} to print an object, abbreviating it with ZERO OR MORE ellipses to fit within a size limit."? > > > > +@code{cl-defgeneric} which is defined for several types of > > > Please add here a cross-reference to where cl-defgeneric is described. > > There is no documentation for cl-defgeneric and cl-defmethod except, > > perhaps, in their doc strings. > Of course, there is: see "(elisp) Generic Functions". Sorry about that. I didn't think of looking anywhere but the CL manual for cl- functions. I'll add that/those cross-reference(s). > > > > +You can write @code{cl-print-object} @code{cl-defmethod}s for other > > > > +types of @var{object}, thus extending @code{cl-prin1}. If you write > > > > +such a method which uses ellipses, you should also write a > > > ^^^^^^^^ > > > "ellipsis" > > See above. > See above. No, here the plural is definitely required, because any particular cl-print-object method will print (i.e. "use") many ellipses, not all identical, in the course of its working life. 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! -- Alan Mackenzie (Nuremberg, Germany).