From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: How to restore the layout? Date: Mon, 01 Jul 2013 08:50:12 +0200 Message-ID: <51D126A4.50402@gmx.at> 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-00010841 3C47@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1372661426 19699 80.91.229.3 (1 Jul 2013 06:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 06:50:26 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 08:50:26 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 1UtXwO-0002fk-DG for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 08:50:24 +0200 Original-Received: from localhost ([::1]:53213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtXwO-0005lr-3y for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 02:50:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtXwL-0005ll-Db for emacs-devel@gnu.org; Mon, 01 Jul 2013 02:50:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtXwK-000422-G2 for emacs-devel@gnu.org; Mon, 01 Jul 2013 02:50:21 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:59874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtXwK-00041j-4s for emacs-devel@gnu.org; Mon, 01 Jul 2013 02:50:20 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lsdt9-1UDegU2GmP-012FX2 for ; Mon, 01 Jul 2013 08:50:19 +0200 Original-Received: (qmail invoked by alias); 01 Jul 2013 06:50:19 -0000 Original-Received: from 62-47-61-240.adsl.highway.telekom.at (EHLO [62.47.61.240]) [62.47.61.240] by mail.gmx.net (mp004) with SMTP; 01 Jul 2013 08:50:19 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/JdXgxxhLJeaTPNpe0m+B5KsikzY8ndGwld9A75j /Qx0Y74umG0YC1 In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.20 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:161397 Archived-At: > I've pushed a new patch. It renames the restore option to > desktop-restore-frames, adds a new one > desktop-restore-in-current-display, and includes a few bugfixes. Thank you! > I've been forced to filter out the > font frame parameter because it didn't really survive the roundtrip > and caused an error. Could you please add a comment about this in the code. > There's some work to do deciding which parameters > make sense to save and which ones do not, specially when doing that > GUI -> tty -> GUI roundtrip (on Windows and elsewhere). If really needed, we can make this customizable. > Other things to do: > > - Detect that frames are restored in a non-visible area and do > something about it (discussion ongoing about the precise way to do > it). > - What to do about minibufferless frames and minibuffer-only frames? 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). When at this time a normal frame (with minibuffer window) remains, we probably have to delete it - AFAIK there's no function to convert an existing minibuffer-equipped frame to a minibuffer-less one. I think anyone needing such an arrangement will have to write the appropriate code. 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. > - In my tests, fullscreen frames (i.e., (fullscreen . fullscreen), not > the other kinds) restore with the wrong height, about two lines longer > that they should. Could be related to settings of tool-bar-mode, etc. > Not very serious because there's a binding for > toggle-frame-fullscreen, but it is still a bit ugly. Is it possible that you call `desktop--make-full-frame' too "early", in some sense? Does maximize have the same problem? martin