From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Shouldn't emacs print long lists with newlines? Date: Wed, 07 Aug 2019 06:51:25 -0400 Message-ID: References: <87muglxxns.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="65918"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: ndame , "emacs-devel@gnu.org" To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 07 12:51:42 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hvJXh-000Gzk-68 for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 12:51:41 +0200 Original-Received: from localhost ([::1]:39686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvJXg-0004mp-51 for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 06:51:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47925) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvJXb-0004ji-K1 for emacs-devel@gnu.org; Wed, 07 Aug 2019 06:51:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvJXZ-0000mH-GB for emacs-devel@gnu.org; Wed, 07 Aug 2019 06:51:35 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19416) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hvJXY-0000lS-Io for emacs-devel@gnu.org; Wed, 07 Aug 2019 06:51:33 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 39385103257; Wed, 7 Aug 2019 06:51:30 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D3752102DA9; Wed, 7 Aug 2019 06:51:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1565175088; bh=RCgyQbPOeTEj3C+7e+T+TGjJoswxvS4tFT/HC3tpaOg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=IK20toh54ArxECBLRXtHUFXqK5BlOwDKjc2I5YxxzM4CQyp5v+36PbkLh5M7rY6Bz D5mkCFuXuKrAL3Jf2TutZh8TGUEyfA06jfKnXp+yqJfcREdGjuec2Zl+On3ISU1Cnd Y0edjwsDw8BObQB06sq2IM2Oq9X5e+NLo/SEZ9giztyjy0Eusg9n63mgjCeCuHuY8d VNr1wafZYOTuUJEuo2nr452juICnlz3xWG0NMgkIAl8ZT08/ONyeuyTMykaJoEu2/A NnEJhzXTdo65zqGocTkDqEWsaid9S3fav/UdeuvbWnJTWya8b/RARQIR0txMPGEqtN uRAQzs0k6jB2g== Original-Received: from alfajor (unknown [78.192.50.77]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 31E9E120F5B; Wed, 7 Aug 2019 06:51:28 -0400 (EDT) In-Reply-To: <87muglxxns.fsf@web.de> (Michael Heerdegen's message of "Wed, 07 Aug 2019 09:05:59 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239216 Archived-At: >> Shouldn't the printing code be smarter and print long lists with >> newlines, every item in a separate line, to avoid the long line >> issue? [ My minibuffer is exactly 1-line tall (and it's a separate frame, so Emacs is not allowed to grow it), so spreading the output on several lines is not always a good solution. ] > If it should depends on the use case. It should be able to do so when > the user wants that - especially pretty printing (pp). So far this has > been discussed here and there, but so far nobody has implemented it. I don't think Edebug tries to pretty print this, currently. But if we want to improve the pretty printer to fold such "parenthesis deserts", we can try a patch like the one below, Stefan diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index de4cbfc0e1..21de326421 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -50,6 +50,33 @@ pp-to-string (pp-buffer) (buffer-string))) +(defun pp--long-line () + "Cut the line before point and before `fill-column' if needed." + ;; FIXME: This still leaves lines longer than fill-column because + ;; When pp-buffer calls us, the text is flush-left rather than + ;; properly indented, so (current-column) is not the real column at + ;; which the text will end up. + (let ((end (point))) + (when (> (current-column) fill-column) + (forward-line 0) + (let ((last nil)) + (while (progn + (skip-syntax-forward "^\"< \\") + (skip-syntax-forward " ") + (and (< (point) end) + (or (< (current-column) fill-column) + (null last)))) + (setq last (point)) + (pcase (char-syntax (char-after)) + (?\\ (forward-char 2)) + (?\" (forward-sexp 1)) + (?\< (end-of-line)))) + (when last + (goto-char last) + (skip-syntax-backward " ") + (delete-region (point) last) + (insert "\n")))))) + ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp object." @@ -58,6 +85,7 @@ pp-buffer ;; (message "%06d" (- (point-max) (point))) (cond ((ignore-errors (down-list 1) t) + (pp--long-line) (save-excursion (backward-char 1) (skip-chars-backward "'`#^") @@ -67,6 +95,7 @@ pp-buffer (progn (skip-chars-backward " \t\n") (point))) (insert "\n")))) ((ignore-errors (up-list 1) t) + (pp--long-line) (skip-syntax-forward ")") (delete-region (point)