[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30786: Save text properties in desktop
From: |
Drew Adams |
Subject: |
bug#30786: Save text properties in desktop |
Date: |
Wed, 14 Mar 2018 20:09:46 +0000 (UTC) |
> >> > 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.