From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70868: 30.0.50; Date: Sun, 12 May 2024 16:50:40 +0200 Message-ID: <87v83jozi7.fsf@web.de> References: <663fb841.050a0220.ffcbb.b84f@mx.google.com> <86jzk019u0.fsf@gnu.org> <86h6f419mi.fsf@gnu.org> Reply-To: Michael Heerdegen Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14883"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: iarchivedmywholelife@gmail.com, 70868@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 12 16:51:22 2024 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 1s6AXp-0003l8-UQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 May 2024 16:51:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6AXZ-0001Hd-1l; Sun, 12 May 2024 10:51:05 -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 1s6AXX-0001F1-4o for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 10:51:03 -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 1s6AXV-00038m-Sk for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 10:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s6AXV-0001cn-Pi for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 10:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 May 2024 14:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70868 X-GNU-PR-Package: emacs Original-Received: via spool by 70868-submit@debbugs.gnu.org id=B70868.17155254076232 (code B ref 70868); Sun, 12 May 2024 14:51:01 +0000 Original-Received: (at 70868) by debbugs.gnu.org; 12 May 2024 14:50:07 +0000 Original-Received: from localhost ([127.0.0.1]:54791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6AWd-0001cS-53 for submit@debbugs.gnu.org; Sun, 12 May 2024 10:50:07 -0400 Original-Received: from mout.web.de ([212.227.17.11]:59125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6AWZ-0001bs-O9 for 70868@debbugs.gnu.org; Sun, 12 May 2024 10:50:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1715525396; x=1716130196; i=michael_heerdegen@web.de; bh=ten0tI0ySD7FZmiwNnIe95BWbA4EwiIzCG2SgOfqNQI=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=fyKKZuumzARibSfpcvW0qH85eaoZ+A/QLvIWnWMlOaInYmobxpV6RiLA8HfBJWbw MyyyI1n39jLOXuczQ8pUjwA0YeaGmP0w3UaA8NXLB/sfwmtESQSOL9gTYCfxlw5uh HPkVuPL2V3t6I+WIeWTS6rMaJqIUixJwT7X98uxqrBrqZU4juRz16kEPfhkzqPano AyNAMOdeJBe+G1Vyxp4z6q1TT6TMyIeHrgTXnSXXsuHKBC0btCOzjTVIC/9kNIjAv VqwFn4AtHsN0OWI0YiVQoaGAUtBhd0GhDPFCdWsHnwL0/LexK0svpOi4KufmxNZbf fIc+Wvm6aiT2H0hjnw== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([84.57.248.23]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MLAVc-1rp37037DO-00IF2r; Sun, 12 May 2024 16:49:56 +0200 In-Reply-To: <86h6f419mi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 May 2024 21:33:41 +0300") X-Provags-ID: V03:K1:rGWz4eoD5dQb4z6Incl6Ea+DkPgfJsPzMKptu0/f2QF2O1C1U51 JbBEZAmrGTFfMoZdepzb9DY3tIhpY9dqIqA8LGX/EsksmNwfz5Mh+G8WAyUAA7B+J6LIBkT XffYTcOb223SvTGlyijjpj4e8IoP1PS2zkgMq9p3EHgDdgvHgGii+f6j5dcsZ6f1H76fd0S o0JAy56GphN8WzHaegAkQ== UI-OutboundReport: notjunk:1;M01:P0:yOoFRpoeuNA=;IIQrG+41MNTYeboR9DWrq5X5aGt GQtooA0TKmVvoMAW9bM9vdvOTP0omh8zGm0Ym8XNkCD475J+YwgT8jh7Y86LMWpGwuzNKD58S WRlhRtcnPbIBd04ek8x+/NfbssO190m5ni9RBEZahMris7TBelpa2fEOKln2pVD33bw9/YPQX /dWvQbo/Pf2dHo8mWQ4KADHdBoc3cUmIPiM52eRXb0VORkIz6VRrxLbHgiI2qNYPPeLQtnqxN W7tK0m7hJ6dNcb9Yw7pRmPRgzhF3AgzPU8+TFwPhlfF80EqkmHtb1BT+yLgQbO2dHiDrmDZqb yM3vK6UrIKqGTTRkWj07ShTZij3pOp/6pZL0eEbgcR1Yps+7PznaqIFACl8VlMbK8phEWeN/+ lYb26pCyoa4aYBwOJ8HuayZW9hJASFD7MtJdANMz/H8dC38XIOv/QHHI8/yali9ypG44QTxMN o5a3vdH7Htlm0E+t63CIc4P6pGSqVJjSekh7A3cb6N9/ACx+0kcmE5meDbSq/k2H1vkfk4rny chqQDOi+/LivA4Nntu/1mZAw73pIkzDFkRIeElrFgvtmriFMkx85Z7c2Sn/oWsBB0CZ/P/WMn NofzCL0qu/JTpfEfncuYsuf05WRlzFTsLwKMOeSOn2aDjey6FRqFOY47OzRij+M50H31zrxzl yboGTqJBiF8W8BNmNOALvrfg6L0eA3vDP1hCiCJb76u2pLbCSZzKy5t51PXXEjhcTfi8KfYEp c3uudUa5wLQ8pqmGWNe3gsjkEteg2ZTmqxGJNB5Bj4KKNtV8fu3OKoPZtsU3sljjEFBj0z0n 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:284921 Archived-At: Eli Zaretskii writes: > M-: (pp-emacs-lisp-code '((quote a))) RET > =3D> ('a) Another one is nil vs. () or '() vs. 'nil, like in (defun f () ...) vs. (defun f nil ...) or (delq nil my-list) vs. (delq () my-list) etc, then - when to use dot syntax? - there is `(foo . (,b)) vs. `(foo ,b) or (let ((my-alist '((a . (1 2)) (b . (3 4))))) ...) vs. (let ((my-alist '((a 1 2)) (b 3 4))) ...) then (list +1 -1) vs. (list 1 -1), ?c vs. n vs ?\x... vs. ?\N..., then there is "\n" vs " " (docstrings!!!) - there is a ton of such ambiguities! And note that we have only brought up silly one-line code examples so far. In real code, what the user expects will be _different_ for different places in one and the same larger expression. I totally agree that this problem is surprising and APITA, but please don't expect that `pp-emacs-lisp-code' will ever produce satisfying results when fed with existing code written by humans (i.e., when we `read' and reprint it). This will mess up as much as it prettifies, and more. And note there are even more problems of other kinds. Another one is that we don't discriminate context dependent semantics. Is (let ...) a `let' expression? Or a `let' `pcase' form? Or a list of names of special forms? Or maybe something which is meant to be macroexpanded to a `let' expression, and the second element of the list is not a binding list but something like ,(compute-let-bindings)? I know these kinds of problems well and for years from my experience with my "el-search" package - when I first tried an automatic rewriting rule like `(if ,cond ,form) --> `(when ,cond ,form) I was very disappointed about how ugly everything got when all in FORM got folded to syntactical defaults. [ For completion, if anyone wonders: in "el-search" I try to identify the code parts that get part of the replacement expression - COND and FORM in the above example - in the original code in the buffer operated on and reuse the print syntax from there. ] In sum I'm quite sure that M-: (pp--insert-lisp 'my-large-thunk-of-real-life-code) is something that will never produce really good looking code whatever guessing and heuristical cleverness we might be able to invent. It will always produce a result that a human will have to tune and correct manually line by line. Which is actually exactly the work we wanted to delegate to this function! So, my opinion is that Elisp pretty printing with input expressions, in contrast to text, is, if at all, only useful for automatically generated expressions (like macro expansions). It's trivial that this will come with the same problems (though in this case they are a bit less surprising and annoying at least). We should still fix this bug, obviously. Michael.