Re: Undumpable object type : buffer, extent

> Strings are not (supposed to be[1]) mutable.  Period, end of story.

Operations I talked of do not modify string contents.  E. g., Martin
Stjernholm wrote about calling `forward-sexp'.  Currently we can have
buffer and a point in it, call `forward-sexp', and get a new point
which is an sexp forward from the original one.

One can just the same ask: you have a string and a position in it;
give me a position in the same string which is an sexp forward.
Currently there is no such a function, but AFAIK nothing forbids it to
exist.  And even have an additional syntax-table arg.

> Does adding "(mapcar #'kill-buffer (buffer-list t))" in The Right
> Place help?

The description of The Right Place and other necessary `kill' calls in
it certainly must be in lispref.


All of this concerns only temporary buffers.  But what forbids to
retain extents on strings after dumping?  Extent faces may be symbols
referring to predefined ones, no display data (console, device, frame)
references are involved.

Perhaps even retaining buffers (with no display data references again)
makes sense in some circumstances.