[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
default pp-fill behaviour
From: |
Madhu |
Subject: |
default pp-fill behaviour |
Date: |
Sun, 25 Jun 2023 07:39:47 +0530 (IST) |
This is about the state after the series of commits including:
* commit 2f181d60323bd9e0196775828de633100479f4c2
|Author: Stefan Monnier <monnier@iro.umontreal.ca>
|AuthorDate: Fri Jun 16 13:35:06 2023 -0400
|Commit: Stefan Monnier <monnier@iro.umontreal.ca>
|CommitDate: Sat Jun 17 17:24:38 2023 -0400
|
| pp.el (pp-fill): New default pp function
|
| * lisp/emacs-lisp/pp.el (pp-default-function): Change default.
| (pp--within-fill-column-p): New helper function.
| (pp-fill): New function.
The problem is to print an alist in a buffer one element per line:
```
(setq $alist '((1 . a) (2 . b) (3 . c)))
(with-output-to-temp-buffer "*temp*"
(let ((print-level nil) (print-length nil))
(pp $alist)))
```
This would give you a temp buffer with this contents
```
((1 . a)
(2 . b)
(3 . c))
```
Emacs-30.0.50 now produces
```
((1 . a) (2 . b) (3 . c))
```
If I try to use the new global level variable pp-max-width
pp-use-max-width to prevent filling and get back the old behaviour, I
can't.
```
(if (fboundp 'pp-28)
(let ((pp-default-function 'pp-28))
(pp $alist))
(pp $alist))))
```
I'd like the old behaviour to be accessible with a global switch. The
new pp machinery is complex and ( uses the usual impenetrable
undebuggable functional paradims) but if it is not powerful enough
produce the old behaviour in one of its code paths, isn't the power is
in question.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- default pp-fill behaviour,
Madhu <=