Shouldn't emacs print long lists with newlines?

Shouldn't emacs print long lists with newlines?

[ndame]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

I'm trying to debug a vc problem with edebug and when stepping
through the source edebug prints the expression results.

VC code sometimes returns long lists with file names. In my
example one step returns a list of 1380 files and prints it to
the Message buffer as a single line which is quite long, so it
impacts scrolling.

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?
 

[-- Attachment #2: Type: text/html, Size: 543 bytes --]

Re: Shouldn't emacs print long lists with newlines?

[Michael Heerdegen]

ndame <emacsuser@freemail.hu> writes:

> 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?

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.

Michael.

Re: Shouldn't emacs print long lists with newlines?

[Stefan Monnier]

>> 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)

Re: Shouldn't emacs print long lists with newlines?

[martin rudalics]

 > [ My minibuffer is exactly 1-line tall (and it's a separate frame, so
 >    Emacs is not allowed to grow it)

Since you can now customize 'resize-mini-frames' this restriction no
longer applies (at least not as stated here).

, so spreading the output on several
 >    lines is not always a good solution.  ]

martin

Re: Shouldn't emacs print long lists with newlines?

[ndame]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

> 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.


Long lists as output is pretty hard to read when the list is on a
single line and it is displayed on multiple screen lines.

So those parts of emacs which print lists for human consumption
(debug, printing expressions resulting in long lists, etc.) should
benefit from some heuristics to display the list as one item per line
when it's better.

E.g. if the disaplayed list is longer than a screen line then it could
display an item per line. Maybe depending on a user option.

[-- Attachment #2: Type: text/html, Size: 805 bytes --]

Re: Shouldn't emacs print long lists with newlines?

[Michael Heerdegen]

ndame <emacsuser@freemail.hu> writes:

> E.g. if the disaplayed list is longer than a screen line then it could
> display an item per line. Maybe depending on a user option.

A good heuristic is not easy to find:

- When list elements are small (e.g. small integers), one item per line
is annoying because the list fills the whole screen although it would
fit in three lines or so.

- Code is sometimes pretty printed.  Adding newlines at bad places makes
the result look quite strange, e.g.

 (defun
  ()
  ...)

- What if the expression is deeply nested (like code) and subexpressions
already start near fill-column?

- Not everything that doesn't fit into one line is a list.  Should we
handle other objects too?

Michael.

Re: Shouldn't emacs print long lists with newlines?

[Stefan Monnier]

>> [ My minibuffer is exactly 1-line tall (and it's a separate frame, so
>>    Emacs is not allowed to grow it)
> Since you can now customize 'resize-mini-frames' this restriction no
> longer applies (at least not as stated here).

FWIW, resize-mini-frames doesn't work very well for me:

- at startup it resizes the frame to a one-line frame of maybe 10-20
  chars long, which is oddly short.  The length is updated on the fly,
  but I find this a bit annoying.  Nothing too serious tho.
- I have my minibuffer frame at the bottom of the screen.  When it grows
  to two or more lines, it correctly moves up.  But when it shrinks back
  to a single line, it doesn't move back down, so it ends up "near" the
  bottom rather than at the bottom.

The second problem is probably partly linked to the window-manager, but
I've found size-varying windows at the bottom of the screen to be poorly
handled under X11 in general (not only with the window-manager
I'm using), so I think I'd have to move my minibuffer-only frame to the
top of the screen to avoid those problem :-(

>> , so spreading the output on several
>>    lines is not always a good solution.  ]

So this still holds :-(


        Stefan

Re: Shouldn't emacs print long lists with newlines?

[martin rudalics]

 >> Since you can now customize 'resize-mini-frames' this restriction no
 >> longer applies (at least not as stated here).
 >
 > FWIW, resize-mini-frames doesn't work very well for me:
 >
 > - at startup it resizes the frame to a one-line frame of maybe 10-20
 >    chars long, which is oddly short.  The length is updated on the fly,
 >    but I find this a bit annoying.  Nothing too serious tho.

You could try to customize 'fit-frame-to-buffer-sizes' for this.

 > - I have my minibuffer frame at the bottom of the screen.  When it grows
 >    to two or more lines, it correctly moves up.  But when it shrinks back
 >    to a single line, it doesn't move back down, so it ends up "near" the
 >    bottom rather than at the bottom.

Attaching a frame to the bottom of the screen is more tricky.  I'm
afraid it wouldn't even help to set the second element of
'fit-frame-to-buffer-margins' to a value that just fits into the
display.

 > The second problem is probably partly linked to the window-manager, but
 > I've found size-varying windows at the bottom of the screen to be poorly
 > handled under X11 in general (not only with the window-manager
 > I'm using), so I think I'd have to move my minibuffer-only frame to the
 > top of the screen to avoid those problem :-(

The solution is to write your own function to (1) resize your frame
less noisily and, once you know its size, (2) make sure the minibuffer
frame's bottom aligns with the bottom of the workarea where it appears
and (3) set 'resize-mini-frames' to that function.

 >>> , so spreading the output on several
 >>>     lines is not always a good solution.  ]
 >
 > So this still holds :-(

It shouldn't since it negatively impacts the design of solutions for
adjustable minibuffer windows.

martin