From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: How to restore the layout? Date: Mon, 1 Jul 2013 12:38:32 +0200 Message-ID: References: <51C5AA68.4000204@alice.it> <2FB4C583-960C-4DA8-8B2E-29DF8D96770E@swipnet.se> <51CD6324.2040504@gmx.at> <834ncifkq9.fsf@gnu.org> <83zjuae19s.fsf@gnu.org> <83r4fmdsw5.fsf@gnu.org> <85k3ldtion.fsf@member.fsf.org> <4E4C522D-DBCC-4133-A764-82C9CCE81E2D@swipnet.se> <8913208E-7FE2-41F5-AC93-000108413C47@swipnet.se> <51D126A4.50402@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1372675165 449 80.91.229.3 (1 Jul 2013 10:39:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 10:39:25 +0000 (UTC) Cc: Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 12:39:23 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UtbVv-0008IT-6F for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 12:39:19 +0200 Original-Received: from localhost ([::1]:47054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtbVu-0007af-Ps for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 06:39:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtbVq-0007aP-R7 for emacs-devel@gnu.org; Mon, 01 Jul 2013 06:39:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtbVp-0000PW-NC for emacs-devel@gnu.org; Mon, 01 Jul 2013 06:39:14 -0400 Original-Received: from mail-ee0-x233.google.com ([2a00:1450:4013:c00::233]:62196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtbVp-0000PQ-Fz for emacs-devel@gnu.org; Mon, 01 Jul 2013 06:39:13 -0400 Original-Received: by mail-ee0-f51.google.com with SMTP id e52so1947839eek.24 for ; Mon, 01 Jul 2013 03:39:12 -0700 (PDT) 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:content-type; bh=OVkXyZ6Mfza3yivtu+Yuu41tn+B5An0wu5f0q48O+E4=; b=RbXocV2FfmUbwIyMR/vtcy71r1GGJg9yh98baapri+pF52tKjU5jwsoLCTS4J4p5wH iERfVPp9MFg/KRW7Be+yW8lUxDGxG83OvS+gxGlbFk9hizQf8HPhRF7Qr2C2p06nW1OC KxfW5zHSZ3WRpojR6V6bu6hFNGGbAQzhJsZalpgh4z5R5j9PQE2ZoG8liAkD79pIv89J 9/2qVWwX0TTe15Rcv0cdqfaJPf+Toj5O3/ze6QndsFQDN6t34sbjoEpfM/Rb7n0bn+1O I0/ofBjiuNUoS4Y/q78vo1KCTFWZve2pO4BHjX9K0Tfbt9esUw1sMovwvKSBgpFXIzCv kKbA== X-Received: by 10.14.213.135 with SMTP id a7mr20266187eep.152.1372675152579; Mon, 01 Jul 2013 03:39:12 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Mon, 1 Jul 2013 03:38:32 -0700 (PDT) In-Reply-To: <51D126A4.50402@gmx.at> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:161400 Archived-At: On Mon, Jul 1, 2013 at 8:50 AM, martin rudalics wrote: > Could you please add a comment about this in the code. Yes. will do. > If really needed, we can make this customizable. If you mean through desfcustom, I don't really think that's something the user should care/know about. But I'll change the defconst to a defvar to make it clear that users doing low-level customization (via hooks and elisp code) can of course alter it. I have not yet given much thought to these kinds of customizations, but I'll likely add some hooks or whatever is necessary so people wanting to mess with the save&restore process in their .emacs (for example, making sure that some window or frame is deleted before saving, etc.) will be able to. > When saving we will have to establish a relationship between each > minibuffer-less frame and its associated minibuffer frame. When > restoring we first have to create the minibuffer frame(s) and then > create the minibuffer-less frames and redirect them to their minibuffer > frame(s). Yes. > I think anyone needing such an arrangement will have to write the > appropriate code. I don't know whether minibuffer-less frames are unusual (frequency-wise), but they are documented on the manual, and have built-in support, so they should work (wrt saving&restoring) out of the box. > Here we only have to make sure that (some sort of) > frame names can be written by desktop so we can use them later when > restoring the frame/minibuffer relationships. We can add desktop-* frame parameters easily with all kind of information we need (as long as it can be read back). > Is it possible that you call `desktop--make-full-frame' too "early", in > some sense? If so, I don't know in which sense. > Does maximize have the same problem? No, maximized frames have their correct height. J