bug#54612: 29.0.50; eww-bookmarks data loss when print-length not nil

[Thomas Fitzsimmons]

Hi,

In GNU Emacs 29.0.50 (build 1, powerpc64le-unknown-linux-gnu, X toolkit, cairo 
version 1.16.0, Xaw scroll bars)
 of 2022-02-27 built on orca.fitzsim.org
Repository revision: 6a10a3e8d489d7b4dcffd6b4c63cee77e73e2535
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --with-x-toolkit=lucid'

Somehow print-length got set to 10 globally -- I don't know who the
culprit was -- and I lost about 80 EWW bookmarks.  I've looked around
and they seem to have been well and truly purged from this Emacs
session's memory.  I'll have to restore from backups, I suppose.

When a bookmark is added, and print-length is less than the length of
eww-bookmarks, the contents of ~/.emacs.d/eww-bookmarks is truncated:

;; Auto-generated file; don't edit -*- mode: lisp-data -*-
((:url "" :title "" :time "")
 [(- print-length 1) more items]
 ...)

I haven't investigated fully, but it seems like a terrible design that a
global variable like print-length can have influence over princ/print in
this way.  This makes all printing fundamentally unreliable and subject
to data loss if some rogue package or the end user goes (setq
print-length <some small number>).

What about this to at least insulate eww-write-bookmarks from this
behaviour:

diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 700a6c3e82..f5139819fb 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -2053,7 +2053,8 @@ eww-add-bookmark
 (defun eww-write-bookmarks ()
   (with-temp-file (expand-file-name "eww-bookmarks" eww-bookmarks-directory)
     (insert ";; Auto-generated file; don't edit -*- mode: lisp-data -*-\n")
-    (pp eww-bookmarks (current-buffer))))
+    (let ((print-length nil))
+      (pp eww-bookmarks (current-buffer)))))
 
 (defun eww-read-bookmarks (&optional error-out)
   "Read bookmarks from `eww-bookmarks'.

I'm not sure what a more general solution to the
print-length/print-level data loss problem could be.

Thomas