From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 20:55:43 +0100 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <727ccd66-3bc3-2a41-7d1d-ef6dae9f0d1e@dancol.org> <7A914757-B1A4-4EEE-9DF0-68EFDDA9A5DB@autodesk.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114401260dafa8054275fb3f X-Trace: blaine.gmane.org 1480449591 2526 195.159.176.226 (29 Nov 2016 19:59:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 19:59:51 +0000 (UTC) Cc: Eli Zaretskii , burton.samograd@autodesk.com, Richard Stallman , Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 20:59:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBoZ4-0007UY-CB for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 20:59:42 +0100 Original-Received: from localhost ([::1]:39057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBoZ6-0008FM-JB for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 14:59:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBoVo-0006Rr-6N for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:56:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBoVn-0000m8-7D for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:56:20 -0500 Original-Received: from mail-vk0-x22b.google.com ([2607:f8b0:400c:c05::22b]:33321) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBoVj-0000iZ-Sf; Tue, 29 Nov 2016 14:56:16 -0500 Original-Received: by mail-vk0-x22b.google.com with SMTP id 137so98259269vkl.0; Tue, 29 Nov 2016 11:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q4llAD3SMUDdJorNPMVO1WCxyTL3LUAAGPmiD+tYA2E=; b=aKVep/Cn3kFP/4mK9ONAcntw3gEmza+bLgAJQuF0qsx5WHjo/gLuzPaBKXQTLCT60s l1JjuOrXYO5NuJpw13KQRxstZmd10IYT2ngiE7PztCz5blgpIZrn2n/UrjSH4i5PIO7J zGL4MOi4P9/872teu5qe21IgDP+BgTD2UDjHcqqJeh9pGjaEQR1RNzjqFJGdQG31zLf1 XRDWj3jm5fK4dqS0E1nfynlRwi5bVtqljh2rX3Su8ksBEIQ7+b2VHB9T+439yGcR6qpt BUtX8uy0gU5NZMbRnJu6jIzsbKlKO8Ey4nSl25qAO59gGUbtjy/x0pE1jVDi97f6gH5c FOYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q4llAD3SMUDdJorNPMVO1WCxyTL3LUAAGPmiD+tYA2E=; b=OJElwJIl0RLTyW3G4ikfoV2HbP4v5GOI46KXgGmBLQKeuSeE4gOH4ndE5teZ/eiNgy feXhtgiusspQfJs1aP7LqV7YhLH34R9lecuMQPptHg+QlxNZfeQQ8/RnDV/ZbX5B80bC V7AgJ7QyIYrI9rUOcEldGFou+kWF53hX+7/oEnvFsXcsruYH9M4BCufDNS+aYubFKXpm PADZWNvaTJzP9093IO4NYEJ6LIvHBX1hHgi3kYDLiE6kkK0RXVc7hoqKcpjLMJcYsmzn r4hPr2LWSlye7HrfVAXxUnYrx80jNVkounQgNFV/9oNKHYKkn13cUIMo1uzElbyXLU1h aE0A== X-Gm-Message-State: AKaTC037DBz3+syuceJjcjXtpF+JAh++DfTTuk1K2BopUBtMWDXF165iLbHvRfcuQySk7/GgZZYm6IYpSobd6Q== X-Received: by 10.31.52.5 with SMTP id b5mr11042872vka.65.1480449374136; Tue, 29 Nov 2016 11:56:14 -0800 (PST) Original-Received: by 10.103.125.149 with HTTP; Tue, 29 Nov 2016 11:55:43 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209759 Archived-At: --001a114401260dafa8054275fb3f Content-Type: text/plain; charset=UTF-8 > > > 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 "#" 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 --001a114401260dafa8054275fb3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Can that be fixed = by creating new equivalent windows and frames?

Yes: you'd want to reuse desktop's code to save window and f= rame
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 rela= ted 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/elma= cro).

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

Basically, instead of th= e traditional "#<window 3 on bla.el>" that does not eval we= ll, I dump it as "(elmacro-get-window 3)". This function just loo= ps 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 ex= ample are mouse clicks:=C2=A0https://github.com/Silex/elmacro#mouse-events-support


=
So, here is my proposal. Make all emacs lisp objects always have an &q= uot;read" friendly text representation (or at least as much as possibl= e).

Maybe by doing so it also simplifies the dumpe= r.

Kind regards,
Philippe
--001a114401260dafa8054275fb3f--