Re: Undumpable object type : buffer

Moving it to xemacs-design.

> (if you dump object x, you must
> be able to dump every object x has a reference to)

Any object x (even cons) may have a reference to any object.
Currently:

. conses itself are dumped;

. if cons references to dumpable y, y is dumped;

. if y is not dumpable, it is an error.

Why is it impossible that

. buffers itself are dumped;

. if buffer references to dumpable y, y is dumped;

. if y is not dumpable, it is an error?

Or the same for x = extent-info?

> I suspect you don't want to go anywhere near console, frame or device.

Does every buffer have to reference them?  Even if it was created
while running temacs in batch mode, so that no (interactive) console
(let alone devices or frames) was ever created?

Having permanently stored and dumped global variable values that are
strings with extents attached to them (or values that are extents in
strings) is done in some packages, and seems quite feasible to me.  I
do not see why should it be forbidden.

Pehaps *permanent* buffer values are not so feasible, an even should
not exist at all.  But Martin Stjernholm <[email protected]>
writes

> To use strings instead it would e.g. be necessary to be able
> to call forward-sexp on a string, and to set the syntax-table text
> property on strings. Afaik that isn't supported.

That is, some computations that eventually will leave only strings are
impossible or very hard without using *temporary* buffers.  So at
least there must be a way for an elisp code writer to ensure after
killing temporary buffers that they are destroyed and will not break
dumping.

Also, if some operations may easibly be specified for strings, and
sometimes are needed, but currently are supported only on buffers,
this looks like a bug to me.  Fixing it will make temporary buffers
unnecessary.

This is clearly a question for xemacs-design: which way of solving
"temporary buffers before dumping" problem is better?