bug#11934: 24.1; provide variable for pp.el to control max display width

bug#11934: 24.1; provide variable for pp.el to control max display width

[Drew Adams]

Enhancement request.
 
The functions in pp.el that produce pretty-printed output are used for
things like `describe-variable' to produce output that is read in *Help*
buffers.  The content of *Help* is normally limited in width.
 
The request is to provide a variable that controls the width of the
displayed expression, or at least tries to as much as possible.
 
For example, I have a variable whose value is this:
 
(bbdb-complete-name comint-completion-at-point
comint-dynamic-complete-filename comint-replace-by-expanded-filename
ess-complete-object-name gud-gdb-complete-command Info-goto-node
Info-index Info-menu lisp-complete-symbol lisp-completion-at-point
minibuffer-default-add-completions read-char-by-name read-color
read-from-minibuffer read-string recentf-make-menu-items)
 
In Message mode, where I am composing this, that is automatically
filled.  But with the pp functions, that value is written with no
newline chars, as a single line that is 369 chars wide.  That sticks
out like a sore thumb in a *Help* buffer that is otherwise designed
to be limited in width.
 
It would be good to be able to bind a max-width variable that lets the
pp functions know that it is better, if possible, to insert newline
chars to try to keep the width below that var's value.
 
I'm not sure what the implementation would look like.  Perhaps it would
involve calling `fill-paragraph' at various points
(`lisp-fill-paragraph' would add nothing here, AFAICT).  Dunno.
 
But it seems like we could somehow do better in a case like this than
just print everything on a single line, which might be hundreds of chars
wide.
 
 
 
In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#11934: 24.1; provide variable for pp.el to control max display width

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> The request is to provide a variable that controls the width of the
> displayed expression, or at least tries to as much as possible.
>
> For example, I have a variable whose value is this:
>
> (bbdb-complete-name comint-completion-at-point
> comint-dynamic-complete-filename comint-replace-by-expanded-filename
> ess-complete-object-name gud-gdb-complete-command Info-goto-node
> Info-index Info-menu lisp-complete-symbol lisp-completion-at-point
> minibuffer-default-add-completions read-char-by-name read-color
> read-from-minibuffer read-string recentf-make-menu-items)

[...]

> It would be good to be able to bind a max-width variable that lets the
> pp functions know that it is better, if possible, to insert newline
> chars to try to keep the width below that var's value.

I agree.  What pp does now with simple lists isn't optimal.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11934: 24.1; provide variable for pp.el to control max display width

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I agree.  What pp does now with simple lists isn't optimal.

AFAICT pp.el could be extended easily for handling this problem.

pp is currently very simple - see `pp-to-string'.  It does just `prin1'
(which does most of the work already) the object into a temp buffer.
Then it does some simple cleanups: `pp-buffer'.  That would be the
function to extend (Drew, wanne give it a try?).

But of course handling this problem is not trivial: we can't distinguish
"simple lists" from code, and what might look good for the first might
look weird for a macro call with a special lisp-indent-function value
(e.g. imagine a `defun' call with a line break inserted just after
"defun").

Another challenge is what to do if we have already nearly exhausted the
width limit.


Michael.

bug#11934: 24.1; provide variable for pp.el to control max display width

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> But of course handling this problem is not trivial: we can't distinguish
> "simple lists" from code, and what might look good for the first might
> look weird for a macro call with a special lisp-indent-function value
> (e.g. imagine a `defun' call with a line break inserted just after
> "defun").

Well, pp isn't really designed for handling code.  I pp'd a function at
random...  it may be pretty, but it sure is unusual for code...

So I don't really think that's a consideration here.

(defun menu-bar-buffer-vector
    (alist)
  (let
      ((buffers-vec
	(make-vector
	 (length alist)
	 nil))
       (i
	(length alist)))
    (dolist
	(pair alist)
      (setq i
	    (1- i))
      (aset buffers-vec i
	    (cons
	     (car pair)
	     `(lambda nil
		(interactive)
		(funcall menu-bar-select-buffer-function ,(cdr pair))))))
    buffers-vec))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11934: 24.1; provide variable for pp.el to control max display width

[Drew Adams]

> Well, pp isn't really designed for handling code.

Maybe you mean that it doesn't do a good enough job
of it?  I think it is designed for handling code, as much
as for handling data.  It just doesn't handle them differently.

Lisp code and Lisp data structures are not very different,
though yes, we generally follow some code-specific formatting
conventions - and pp.el does not bother with those (as it
cannot know whether you want to consider the sexp as code
or data).

> I pp'd a function at random...  it may be pretty, but it
> sure is unusual for code...

It's pretty-printed.  And not too bad.

> So I don't really think that's a consideration here.

If you mean that pp.el shouldn't bother to do something
special for code then I agree.  At least until/unless
we add an optional arg to indicate the intention to
interpret the result as code and not data.

bug#11934: 24.1; provide variable for pp.el to control max display width

[Drew Adams]

> `pp-buffer'.  That would be the function to extend
> (Drew, wanne give it a try?).

Sorry, I really don't have the time.  But I welcome improvements. ;-)
 
> But of course handling this problem is not trivial: we can't distinguish
> "simple lists" from code, and what might look good for the first might
> look weird for a macro call with a special lisp-indent-function value
> (e.g. imagine a `defun' call with a line break inserted just after
> "defun").

Yes.

> Another challenge is what to do if we have already
> nearly exhausted the width limit.

Not sure what you mean, there.

bug#11934: 24.1; provide variable for pp.el to control max display width

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > Another challenge is what to do if we have already
> > nearly exhausted the width limit.
>
> Not sure what you mean, there.

I mean what we do with code that is very nested so that the indentation
becomes a large amount of the maximum specified width (or even larger).

Then we should not end up with something like e.g.

(a (b (c .... (1;limit is here at the colon
               2
               3
               4
               5
              )
           )))


Michael.

bug#11934: 24.1; provide variable for pp.el to control max display width

[Drew Adams]

> > > Another challenge is what to do if we have already
> > > nearly exhausted the width limit.
> >
> > Not sure what you mean, there.
> 
> I mean what we do with code that is very nested so that the indentation
> becomes a large amount of the maximum specified width (or even larger).
> 
> Then we should not end up with something like e.g.
> 
> (a (b (c .... (1;limit is here at the colon
>                2
>                3
>                4
>                5
>               )
>            )))

Ah, right.  I think we should try for something at
least a little bit better, for now.  There will no doubt
be room for improvement after that.  And things can no
doubt get complicated, with various tradeoffs possible.

One way to handle tradeoffs, perhaps, is to allow optional
arguments that let callers indicate which behaviors to
choose, among several whose effects might conflict.

bug#11934: 24.1; provide variable for pp.el to control max display width

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> The functions in pp.el that produce pretty-printed output are used for
> things like `describe-variable' to produce output that is read in *Help*
> buffers.  The content of *Help* is normally limited in width.

I've now added this to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no