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

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

[Drew Adams]

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@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'

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

[Drew Adams]

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.

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

[Lars Ingebrigtsen]

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

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

[Drew Adams]

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

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

[Drew Adams]

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

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.


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14413 bytes --]