unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#11934: 24.1; provide variable for pp.el to control max display width
@ 2012-07-13 14:48 Drew Adams
  2016-04-28 15:53 ` Lars Ingebrigtsen
  2021-11-05 14:27 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 9+ messages in thread
From: Drew Adams @ 2012-07-13 14:48 UTC (permalink / raw)
  To: 11934

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'
 






^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2012-07-13 14:48 bug#11934: 24.1; provide variable for pp.el to control max display width Drew Adams
@ 2016-04-28 15:53 ` Lars Ingebrigtsen
  2016-04-29 14:14   ` Michael Heerdegen
  2021-11-05 14:27 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-28 15:53 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11934

"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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-28 15:53 ` Lars Ingebrigtsen
@ 2016-04-29 14:14   ` Michael Heerdegen
  2016-04-29 14:24     ` Lars Ingebrigtsen
  2016-04-29 17:44     ` Drew Adams
  0 siblings, 2 replies; 9+ messages in thread
From: Michael Heerdegen @ 2016-04-29 14:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 11934

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.






^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-29 14:14   ` Michael Heerdegen
@ 2016-04-29 14:24     ` Lars Ingebrigtsen
  2016-04-29 17:47       ` Drew Adams
  2016-04-29 17:44     ` Drew Adams
  1 sibling, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-29 14:24 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 11934

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-29 14:14   ` Michael Heerdegen
  2016-04-29 14:24     ` Lars Ingebrigtsen
@ 2016-04-29 17:44     ` Drew Adams
  2016-04-29 19:26       ` Michael Heerdegen
  1 sibling, 1 reply; 9+ messages in thread
From: Drew Adams @ 2016-04-29 17:44 UTC (permalink / raw)
  To: Michael Heerdegen, Lars Ingebrigtsen; +Cc: 11934

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-29 14:24     ` Lars Ingebrigtsen
@ 2016-04-29 17:47       ` Drew Adams
  0 siblings, 0 replies; 9+ messages in thread
From: Drew Adams @ 2016-04-29 17:47 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Michael Heerdegen; +Cc: 11934

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-29 17:44     ` Drew Adams
@ 2016-04-29 19:26       ` Michael Heerdegen
  2016-04-29 19:37         ` Drew Adams
  0 siblings, 1 reply; 9+ messages in thread
From: Michael Heerdegen @ 2016-04-29 19:26 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11934, Lars Ingebrigtsen

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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2016-04-29 19:26       ` Michael Heerdegen
@ 2016-04-29 19:37         ` Drew Adams
  0 siblings, 0 replies; 9+ messages in thread
From: Drew Adams @ 2016-04-29 19:37 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 11934, Lars Ingebrigtsen

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#11934: 24.1; provide variable for pp.el to control max display width
  2012-07-13 14:48 bug#11934: 24.1; provide variable for pp.el to control max display width Drew Adams
  2016-04-28 15:53 ` Lars Ingebrigtsen
@ 2021-11-05 14:27 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-05 14:27 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11934

"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





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-11-05 14:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-13 14:48 bug#11934: 24.1; provide variable for pp.el to control max display width Drew Adams
2016-04-28 15:53 ` Lars Ingebrigtsen
2016-04-29 14:14   ` Michael Heerdegen
2016-04-29 14:24     ` Lars Ingebrigtsen
2016-04-29 17:47       ` Drew Adams
2016-04-29 17:44     ` Drew Adams
2016-04-29 19:26       ` Michael Heerdegen
2016-04-29 19:37         ` Drew Adams
2021-11-05 14:27 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).