GNU bug report logs - #14754
24.3.50; `C-h v' needs to fill wide `pp' lines (493 chars wide?!)

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 14754 in the body.
You can then email your comments to 14754 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.3.50; `C-h v' needs to fill wide `pp' lines (493 chars wide?!)
Date: Sun, 30 Jun 2013 00:10:19 -0700 (PDT)

The lines in the *Help* buffer should respect `fill-column' as much as
possible, other things being equal.

emacs -Q

C-h v imagemagick-enabled-types

You see the value printed on a single line that is 493 chars wide!
That's ridiculous, and it does not play well with code that fits the
*Help* frame or window to its buffer text etc.

The problem is this part of `describe-variable':

(let ((from (point))
      (line-beg (line-beginning-position))
      (print-rep
       (let ((print-quoted t))
         (prin1-to-string val))))
  (if (< (+ (length print-rep) (point) (- line-beg)) 68)
      (insert print-rep)
    (terpri)
    (pp val)
    (if (< (point) (+ 68 (line-beginning-position 0)))
        (delete-region from (1+ from))
      (delete-region (1- from) from)))
  (let* ((sv (get variable 'standard-value))
         (origval (and (consp sv)
                       (condition-case nil
                           (eval (car sv))
                         (error :help-eval-error)))))
    (when (and (consp sv)
               (not (equal origval val))
               (not (equal origval :help-eval-error)))
      (princ "\nOriginal value was \n")
      (setq from (point))
      (pp origval)
      (if (< (point) (+ from 20))
          (delete-region (1- from) from)))))

Better would be something like the following.  It fills the
pretty-printed value, and it adds a newline before it if the
value to be printed is not a number, a symbol, a character,
or a string with no newlines.  That's a simple heuristic,
but it's not too bad.

(let ((from (point))
      (line-beg (line-beginning-position))
      (print-rep
       (let ((print-quoted t))
         (prin1-to-string val))))
  (if (< (+ (length print-rep) (point) (- line-beg)) 68)
      (insert print-rep)
    (terpri)
    (unless (or (numberp val) (symbolp val) (characterp val)
                (and (stringp val) (string-match-p "[n]" val)))
      (terpri))
    (let ((beg  (point)))
      (pp val)
      (fill-region beg (point)))
    (if (< (point) (+ 68 (line-beginning-position 0)))
        (delete-region from (1+ from))
      (delete-region (1- from) from)))
  (let* ((sv (get variable 'standard-value))
         (origval (and (consp sv)
                       (condition-case nil
                           (eval (car sv))
                         (error :help-eval-error)))))
    (when (and (consp sv)
               (not (equal origval val))
               (not (equal origval :help-eval-error)))
      (princ "\nOriginal value was \n")
      (setq from (point))
      (unless (or (numberp origval) (symbolp origval) (characterp origval)
                  (and (stringp origval) (string-match-p "[n]" origval)))
        (terpri))
      (let ((beg  (point)))
        (pp origval)
        (fill-region beg (point)))
      (if (< (point) (+ from 20))
          (delete-region (1- from) from)))))

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-27 on ODIEONE
Bzr revision: 113205 dgutov <at> yandex.ru-20130627095155-f1lv1c7xf99g1sss
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

From: Drew Adams <drew.adams <at> oracle.com>
To: 14754 <at> debbugs.gnu.org
Subject: RE: bug#14754: 24.3.50; `C-h v' needs to fill wide `pp' lines (493
 chars wide?!)
Date: Mon, 1 Jul 2013 10:07:23 -0700 (PDT)

Sorry, but the patch I sent is no good.  Filling something that was
pretty-printed destroys pretty-printing (duh).

The problem remains.  It is that `pp' prints a flat list using a very
large width, which is inappropriate for buffer *Help* etc.

One solution might be to have a variable controlling the max width
(when possible) for pretty-printing, much as we have vars to control the
print-length etc.

> The lines in the *Help* buffer should respect `fill-column' as much as
> possible, other things being equal.
> emacs -Q
> C-h v imagemagick-enabled-types
> 
> You see the value printed on a single line that is 493 chars wide!
> That's ridiculous, and it does not play well with code that fits the
> *Help* frame or window to its buffer text etc.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14754 <at> debbugs.gnu.org
Subject: Re: bug#14754: 24.3.50;
 `C-h v' needs to fill wide `pp' lines (493 chars wide?!)
Date: Fri, 07 Feb 2014 22:38:52 -0800

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

> The lines in the *Help* buffer should respect `fill-column' as much as
> possible, other things being equal.
>
> emacs -Q
>
> C-h v imagemagick-enabled-types
>
> You see the value printed on a single line that is 493 chars wide!
> That's ridiculous, and it does not play well with code that fits the
> *Help* frame or window to its buffer text etc.
>
> The problem is this part of `describe-variable':
>
> (let ((from (point))
>       (line-beg (line-beginning-position))
>       (print-rep
>        (let ((print-quoted t))
>          (prin1-to-string val))))
>   (if (< (+ (length print-rep) (point) (- line-beg)) 68)
>       (insert print-rep)
>     (terpri)
>     (pp val)

etc

Is there any reason why it doesn't just pretty-print the values always?

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 14754 <at> debbugs.gnu.org
Subject: RE: bug#14754: 24.3.50; `C-h v' needs to fill wide `pp' lines (493
 chars wide?!)
Date: Sun, 9 Feb 2014 19:56:49 -0800 (PST)

> Is there any reason why it doesn't just pretty-print the values
> always?

It's not so simple.  See my followup message, after the original
report.  The bug is really about filling long lines.
Pretty-printing does not help with that.

E.g., do this:

Load file bytecomp.el, then C-h v byte-compile-cl-functions.

The value is a flat list of 456 symbols.  Pretty-printing
inserts no newline chars when printing it.

And as my followup message points out, filling something
that has been pretty-printed destroys pretty-printing.

Perhaps what might be useful (dunno) is a new pretty-printer
variable, to go along with `(eval-expression-)print-length'
and `print-circle', and which would insert a newline between
atoms when the line length is sufficiently long.  Dunno.

I don't have a solution for this enhancement request.  Maybe
someone else does.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: 'Drew Adams'
 <IMCEAORCL-drew+2Eadams+40oracle+2Ecom <at> namprd10.prod.outlook.com>, Lars
 Ingebrigtsen <larsi <at> gnus.org>
Cc: "14754 <at> debbugs.gnu.org" <14754 <at> debbugs.gnu.org>
Subject: RE: bug#14754: 24.3.50; `C-h v' needs to fill wide `pp' lines (493
 chars wide?!)
Date: Thu, 9 Jun 2022 16:36:26 +0000

[Message part 1 (text/plain, inline)]

This was closed as fixed in 29.1.  I don't have
that release, so I can't check this.

I hope this problem is fixed.  I was wrong about
the solution being to just fill.  That would be
catastrophic for some variable values, such as
for `directory-listing-before-filename-regexp',
where SPC chars are significant etc.  (For that
var the result of filling ended up, in effect,
replacing the SPC before the + at the end of the
regexp with just a newline.)

Some enhancement of pretty-printing, to control
(or at least to try to control) the width is
needed.  Maybe that's what's been implemented as
part of the fix.  If so, great.

The problem, in general, is this:

* We need to be able to print (e.g. pretty-print)
  any Lisp value.

* Buffer `*Help*' should not have lines longer
  than what the style convention calls for.

Trying to finesse those two different rules is
the difficulty.  If you've come up with a good
solution, bravo.

[winmail.dat (application/ms-tnef, attachment)]

Previous Next

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