From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: How to restore the layout? Date: Mon, 1 Jul 2013 07:11:16 -0700 (PDT) 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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372687895 14964 80.91.229.3 (1 Jul 2013 14:11:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 14:11:35 +0000 (UTC) Cc: Emacs developers To: martin rudalics , Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 16:11:32 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 1UtepI-0003Gc-2F for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 16:11:32 +0200 Original-Received: from localhost ([::1]:46554 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtepH-0004JY-Gs for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 10:11:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtepE-0004JO-Gx for emacs-devel@gnu.org; Mon, 01 Jul 2013 10:11:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Utep9-000395-Qa for emacs-devel@gnu.org; Mon, 01 Jul 2013 10:11:28 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:19584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utep9-000390-Ks for emacs-devel@gnu.org; Mon, 01 Jul 2013 10:11:23 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r61EBJuP031666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jul 2013 14:11:19 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61EBIRX024965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 14:11:18 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61EBIvE005008; Mon, 1 Jul 2013 14:11:18 GMT In-Reply-To: <51D126A4.50402@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:161412 Archived-At: > > - What to do about minibufferless frames and minibuffer-only frames? >=20 > 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. >=20 > 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. Another possibility/suggestion, from little-to-no knowledge of this stuff: Simply do not record or restore a minibuffer-only frame. Otherwise, record the `minibuffer' property of a frame, including the case where it is nil (no minibuffer). That should at least handle the case of someone who restores a desktop in an Emacs session that already has a standalone minibuffer. (But from your message I now have a doubt: is it necessary to associate the ordinary restored frames with the existing standalone minibuffer?) And I think that is the common (only?) standalone minibuffer frame scenario, I believe. There are perhaps other use cases, e.g., where the desktop is invoked/restored before the Emacs session has created its standalone minibuffer. Dunno - can't really speak to such scenarios. But for the usual (?) case, where an Emacs session exists with a standalone minibuffer and *then* you restore a desktop, I would guess (naively) that it should work perfectly. Keep in mind that to use a standalone minibuffer you really need to set it up at startup time, e.g., from the command line or from your init file. You cannot add a (useful) standalone minibuffer after Emacs has already created its first frame, which has its own minibuffer. Correction of that last observation welcome. But it seems to be the case. My simple proposal above (do not record/restore minibuffer-only frames) is, I guess, based on it.