GNU bug report logs - #30786
Save text properties in desktop

Previous Next

Full log

Message #20 received at 30786 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 30786 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: RE: 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.