Re: Preview: portable dumper

[Philippe Vaucher <philippe.vaucher@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

>
> > 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

[-- Attachment #2: Type: text/html, Size: 2240 bytes --]