bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.

[Eric Abrahamsen]

On 12/15/17 23:26 PM, Pierre Téchoueyres wrote:
> Of course with the good example and patch this will be more obvious.

And there's another problem here, manifesting in the Gnus registry.
Here's the issue:

(setq test-hash (make-hash-table :test #'equal))

(puthash "<msg@id>" '((sender "me")) test-hash)
(gethash "<msg@id>" test-hash)

(let (eval-expression-print-length)
  (prin1 test-hash))

=> Data is correct: ("<msg@id>" ((sender "me")))

(let (eval-expression-print-length)
  (eieio-override-prin1 test-hash))

=> Data is incorrect: ("<msg@id>" (quote ((sender "me"))))

The basic problem is that the code is really only set up to do
single-layer reading/writing, and nesting the process runs into
difficulties.

Hash table values are re-written with:

(maphash
   (lambda (key val)
     (setf (gethash key copy)
           (read
            (with-output-to-string
              (eieio-override-prin1 val)))))
   copy)

If VAL is a list, it ends up in `eieio-list-prin1', which wraps it in a
call to `quote'.

The read process looks for these calls to `quote' and removes them, but
it only does it for top-level slot values. If the data is inside
something else (hash table values, in this case), the `quote' calls
remain in the code.

I'd really like to simplify this whole process (it should just walk the
whole tree and convert objects, nothing else -- why write quotes only to
delete them on read?) but in the meantime, I hope we can get a minimum
viable fix in for 26.

My feeling is that we could just remove the addition of the quote
character in `eieio-list-prin1'. The eieio-persistent load process only
`read's, doesn't `eval', so in theory the quote is superfluous. The
check for its presence would stay in.

Any thoughts on this? Obviously I will test better than I have been...

Eric