GNU bug report logs - #11934
24.1; provide variable for pp.el to control max display width

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11934 in the body.
You can then email your comments to 11934 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1; provide variable for pp.el to control max display width
Date: Fri, 13 Jul 2012 07:48:04 -0700

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'
 

Message #8 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11934 <at> debbugs.gnu.org
Subject: Re: bug#11934: 24.1;
 provide variable for pp.el to control max display width
Date: Thu, 28 Apr 2016 17:53:43 +0200

"Drew Adams" <drew.adams <at> 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

Message #15 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 11934 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#11934: 24.1;
 provide variable for pp.el to control max display width
Date: Fri, 29 Apr 2016 16:14:56 +0200

Lars Ingebrigtsen <larsi <at> 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.

Message #18 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11934 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#11934: 24.1;
 provide variable for pp.el to control max display width
Date: Fri, 29 Apr 2016 16:24:01 +0200

Michael Heerdegen <michael_heerdegen <at> 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

Message #21 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Lars Ingebrigtsen
 <larsi <at> gnus.org>
Cc: 11934 <at> debbugs.gnu.org
Subject: RE: bug#11934: 24.1; provide variable for pp.el to control max
 display width
Date: Fri, 29 Apr 2016 10:44:30 -0700 (PDT)

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

Message #24 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Michael Heerdegen
 <michael_heerdegen <at> web.de>
Cc: 11934 <at> debbugs.gnu.org
Subject: RE: bug#11934: 24.1; provide variable for pp.el to control max
 display width
Date: Fri, 29 Apr 2016 10:47:36 -0700 (PDT)

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

Message #27 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11934 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#11934: 24.1;
 provide variable for pp.el to control max display width
Date: Fri, 29 Apr 2016 21:26:58 +0200

Drew Adams <drew.adams <at> 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.

Message #30 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11934 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: bug#11934: 24.1; provide variable for pp.el to control max
 display width
Date: Fri, 29 Apr 2016 12:37:03 -0700 (PDT)

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

Message #33 received at 11934 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11934 <at> debbugs.gnu.org
Subject: Re: bug#11934: 24.1; provide variable for pp.el to control max
 display width
Date: Fri, 05 Nov 2021 15:27:18 +0100

"Drew Adams" <drew.adams <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.