From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Steingold Newsgroups: gmane.emacs.devel Subject: Re: `unreadablep' Date: Wed, 15 Dec 2021 11:09:58 -0500 Organization: disorganization Message-ID: References: <87bl1imhnd.fsf@gnus.org> Reply-To: sds@gnu.org Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25219"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) To: emacs-devel@gnu.org Cancel-Lock: sha1:5Hjm3LPeSrv3lvP3X2lj6j1rqvI= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 17:26:00 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mxX6N-0006Ld-Kf for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 17:25:59 +0100 Original-Received: from localhost ([::1]:60120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxX6M-0003vR-M3 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 11:25:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxWr4-0001po-FS for emacs-devel@gnu.org; Wed, 15 Dec 2021 11:10:11 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:45408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxWr0-00027H-Rd for emacs-devel@gnu.org; Wed, 15 Dec 2021 11:10:10 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mxWqy-0004Qt-BJ for emacs-devel@gnu.org; Wed, 15 Dec 2021 17:10:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-Attribution: Sam X-Disclaimer: You should not expect anyone to agree with me. Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:282067 Archived-At: > * Lars Ingebrigtsen [2021-12-15 08:49:58 +0100]: > > Do we have any primitive that can be used to check whether an object is > printable or not? Code like this (from savehist.el) makes me believe > "not": > > ;; Print elements of VALUE one by one, carefully. > (dolist (elt value) > (let ((start (point))) > (insert " ") > ;; Try to print and then to read an element. > (condition-case nil > (progn > (prin1 elt (current-buffer)) > (save-excursion > (goto-char start) > (read (current-buffer)))) > (error > ;; If writing or reading gave an error, comment it out. > (goto-char start) > (insert "\n") > (while (not (eobp)) > (insert ";;; ") > (forward-line 1)) > (insert "\n"))) > (goto-char (point-max)))) I think the above code would have been perfect, if 1. prin1 were replaced with something like `(write ... :readably t)` (http://clhs.lisp.se/Body/f_wr_pr.htm), _and_ 2. there were no `read` after `prin1` (BTW, the return value of `read` is ignored, to be "honest", it should be compared to `elt` using `equal`) > It would be nice to have such a function (i.e., that says whether it can > be read back after printing it). The problem is, of course, complex > structures that require recursing (and then checking for loops), etc, so > you basically have to implement it the way printing is done if you want > it to be fast, I think? > > Does anybody have any thoughts on this issue? Why would one want to know in advance if the object is printable readably? Only to decide how to print it, right? Then the optimal approach is to _try_ to print readably and then take an alternative/remedial action on failure. This will usually save a structure traversal. Thus I would advocate for a `print-readably' variable that would emulate the CL behavior . > I wonder whether this could be efficiently implemented by, say, having > some kind of special value for PRINTCHARFUN for prin1, but I haven't > looked at the code yet. Yeah, we could create a "/dev/null"-type object and pass it to prin1. However, this would still make the above approach better in most cases. (My original reply was, apparently, sent just to Lars, and was incorrect) -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2022 http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com https://www.memritv.org https://www.dhimmitude.org http://think-israel.org When you are arguing with an idiot, your opponent is doing the same.