Re: Preview: portable dumper

[Philippe Vaucher]

> Can that be fixed by creating new equivalent windows and frames?

Yes: you'd want to reuse desktop's code to save window and frame
configuration. I plan to provide a both-dump-hook and after-dump-hook
mechanism that Lisp code can use for tasks like this.

This comment remembered me about a proposal I was waiting to be polished about the lisp objects representation, but since it's related it kinda forces me to talk about it earlier :-)

I wrote an utility that lets you see your keyboards macros as emacs lisp (https://github.com/Silex/elmacro).

In this utility, I have to deal with all kind of lisp objects that needed to be serialized, and I found myself writing utilities that dumped windows, frames & buffers differently than was "print" does.

Basically, instead of the traditional "#<window 3 on bla.el>" that does not eval well, I dump it as "(elmacro-get-window 3)". This function just loops over "(window-list)" and returns the correct window, that way I can eval that code and it works (of course it does not work of the window 3 gets destroyed before the code evaluation, but that's ok). A good example are mouse clicks: https://github.com/Silex/elmacro#mouse-events-support

During the implementation I often thought "wouldn't it be nice if 'print' (and prin1/prin1-to-string/etc) dumped ALL lisp objects as something evalable?".

So, here is my proposal. Make all emacs lisp objects always have an "read" friendly text representation (or at least as much as possible).

Maybe by doing so it also simplifies the dumper.

Kind regards,

Philippe