fix(render): serialize the source header in full regardless of print-length

The #+LINEAR-SOURCE descriptor was written with a bare prin1-to-string, which honors the user's print-length and print-level. A long source, like a Custom View's (it carries a sort vector, a url, and several keys), truncated to "..." for anyone whose config caps those (mine sits at 10). The header then read back as a malformed, odd-length plist, so refresh and the new sort commands errored on the view. A short source like my-open-issues fit under the cap and hid the bug.

pearl--linear-source-string binds both to nil around the serialization, and the two header writers (the full render and the sort header rewrite) go through it. I caught it dogfooding the interactive sort live on a real view.

1 files changed, 12 insertions, 0 deletions

diff --git a/tests/test-pearl-sort.el b/tests/test-pearl-sort.el
index a5292b3..8833675 100644
--- a/tests/test-pearl-sort.el
+++ b/tests/test-pearl-sort.el
@@ -127,6 +127,18 @@ leaving its server :sort (an IssueSortInput) untouched."
       (should (eq (plist-get src :sort) 'priority))
       (should (eq (plist-get src :order) 'asc)))))
 
+(ert-deftest test-pearl-write-source-header-survives-print-length ()
+  "A long source serializes in full even when print-length/level are bound low.
+A view source is long enough to truncate under a user's `print-length', which
+would persist an unreadable #+LINEAR-SOURCE and break refresh/sort."
+  (test-pearl-sort--in-org test-pearl-sort--flat
+    (let ((print-length 2) (print-level 2)
+          (src '(:type view :name "V" :id "vid" :url "u" :sort ((:a 1))
+                 :show-completed "none" :group "x"
+                 :client-sort priority :client-order asc)))
+      (pearl--write-linear-source-header src)
+      (should (equal (pearl--read-active-source) src)))))
+
 ;;; client-side reorder
 
 (ert-deftest test-pearl-reorder-priority-ascending ()