bug#30786: Save text properties in desktop

[Drew Adams <drew.adams@oracle.com>]

> >> > Maybe solving Bug#24982 would help?
> >>
> >> This would help on reading the desktop, but maybe better not to save
> >> non-readable values in the first place.
> >
> > No.  If the problem is reading then that's where the solution
> > should be located - not writing.  It has happened quite a few
> > times that something unreadable by Emacs has later become
> > readable.
> 
> You mean the print syntax changes to become readable?  But not that
> Emacs can later read some unreadable #<...> syntax, right?

I mean what I said further down: a given syntax is not readable
in Emacs version N (e.g. 20), and so raises an error there, but
it is readable in Emacs N+M (e.g. 22).  If we had provided a
way in version N of ignoring such error raising then that would
let you read the rest of a file (for example), ignoring syntax
that is illegal in Emacs N.

> > We have `condition-case' for most errors.  We have little or
> > no control over read errors.
> >
> > Dunno whether we need a complete read-error-handling construct
> > a la `condition-case', but we at least need a way to let Emacs
> > ignore all read errors.  And preferably within some scope (e.g.
> > let-bind a variable).
> 
> `condition-case' works for read errors too, afaik,

Can you specify a particular read error to handle/ignore?

> but you're suggesting a different kind of control is needed.
> Something more like Common Lisp restart-case, I guess?

Dunno.  I actually am not familiar with CL `restart-case', or
else I've forgotten it.  Perhaps it was added after CLTL1?

> That could be useful in general, but solving this particular bug by
> avoiding writing unreadable objects as Juri suggests seems okay too (and
> much less work, hence more likely to actually happen instead of just
> sitting for years).

It's fine not to write unreadable objects here.

It's better to provide a simple way to not provoke a read
error for such objects.  It's a read problem, not a write
problem.