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 09:03:10 -0700 (PDT) Message-ID: <55419fed-b69d-4d07-81b2-b5b70f113929@default> 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 1372694606 935 80.91.229.3 (1 Jul 2013 16:03:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 16:03:26 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 18:03:27 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 1UtgZZ-0004ul-0p for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 18:03:25 +0200 Original-Received: from localhost ([::1]:60245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtgZY-0007Fv-L2 for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 12:03:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtgZU-0007Fo-Ep for emacs-devel@gnu.org; Mon, 01 Jul 2013 12:03:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtgZR-0002sS-MA for emacs-devel@gnu.org; Mon, 01 Jul 2013 12:03:20 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:23949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtgZR-0002ry-Du for emacs-devel@gnu.org; Mon, 01 Jul 2013 12:03:17 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r61G3Cfd011313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jul 2013 16:03:13 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61G3BeY022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 16:03:12 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61G3BUj022084; Mon, 1 Jul 2013 16:03:11 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:161415 Archived-At: > > Another possibility/suggestion, from little-to-no knowledge of this > > stuff: Simply do not record or restore a minibuffer-only frame. >=20 > Yes, that's one posibility, but then, if the user moved or resized it, > these changes won't be restored. Not a deal breaker, but something to > take into account. My guess is that, for the reasons I gave earlier (must set up during startup), someone using a standalone minibuffer frame will already have set it up, including its position and size, before trying to restore a desktop. Users will neither want nor need a desktop to record and restore a standalone minibuffer frame. My suggestion is to record & restore only the frames that do not have an `only' value for frame parameter `minibuffer'. No one will miss the "fe= ature" of recording & restoring a standalone minibuffer frame. This assumes that everything works as expected otherwise: 1. Restoring a frame with nil `minibuffer' property correctly associates it with the standalone minibuffer frame. I assume that that is the case, because that is what happens today when `default-frame-alist' specifies nil as the `minibuffer' property value. That is the only that makes sense to me. 2. Restoring a frame that had a non-nil, non-`only' `minibuffer' property correctly associates it with an existing standalone minibuffer frame. I assume that is the only reasonable behavior, but I'm no expert on that. Perhaps there is someone who uses both a standalone minibuffer and separate minibuffers in some frames? I doubt it, however. If I prove wrong about the expected use cases then you can think later about providing a user option. The default behavior should anyway, IMO, be what I described: do not record or restore any frame that has `only' as its `minibuffer' frame parameter value. That is at least the first behavior to try out for your prototype, IMO. > OTOH, restoring a minibuffer-only frame does not > really make much sense unless you do it first of all and set > default-minibuffer-frame to it... Time to go doing some > experimenting. Exactly. > > Otherwise, record the `minibuffer' property of a frame, including the > > case where it is nil (no minibuffer). >=20 > The `minibuffer' property can contain non-readable things, like a > window reference. Yes. I don't know whether anyone uses that, or whether it is used somehow internally by Emacs. In any case, I have nothing useful to offer about that. If the value is a window then it supposedly must be a minibuffer window on some other frame. How you would deal with that in the context of desktop.el I don't know. I guess if you are actually restoring windows in general then you could restore that value (and hence the association) as well. But again, what is a use case for that? It would not be needed for the usual case of input redirection, AFAIK. For that, you would just redirect input to your standalone minibuffer. (That's what I do for a separate *Completions* frame, for instance.) > > (But from your message I now have a doubt: is it necessary to > > associate the ordinary restored frames with the existing standalone > > minibuffer?) >=20 > minibuffer can be t/n/only, but also a reference to a minibuffer > window in another frame. > - t : nothing to do, it works out of the box > - nil: emacs will try to associate the frame with > default-minibuffer-frame or create one minibuffer frame for it > - only: as discussed above > - a window: we currently can do nothing about this, because we do not > have a way to name windows and restore references to them. See above. I wouldn't worry about the window-valued case, at least for now. Note too: it is not just any old window - it should (must?) be a minibuffer window. > > 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. >=20 > Yes. minibuffer-only frames and their brethren are strange beasts. Every beast is a strange beast. Every Emacs feature that one is not used to using seems strange at first. FWIW, a standalone minibuffer frame was not only not strange but was the DEFAULT and the TYPICAL way for users to interact with Emacs back in the days of Epoch. And Epoch's standalone minibuffer worked even better than what I've been able to cobble together for GNU Emacs. >From http://tonic.physics.sunysb.edu/docs/emacs/emacsFAQ.html#sec93 (long ago): 93: What is the difference between GNU Emacs and Epoch? =20 Marc Andreessen writes: =20 Epoch is GNU Emacs on steroids: an adaptation of GNU Emacs with lots of additional support for features made possible by the X11 windowing system. These features include multiple editing windows, arbitrary colors and fonts (fixed-width and proportional), selectable zones per buffer with arbitrary display styles (font, color, underline, stipple, pixmap), an optional separate minibuffer window, improved keyboard and mouse handling, full 8-bit character set support, and more. >From http://www.cs.utah.edu/dept/old/texinfo/epoch/epoch.html#SEC9: Epoch supports two different kinds of minibuffers. The default is a non-local minibuffer, which is displayed in its own distinct screen; this is what Epoch has traditionally done. The alternative is to have minibuffer windows local to each edit screen; this is similar to traditional GNU Emacs. In the case of non-local minibuffers, there will always be exactly one minibuffer screen, and one or more edit screens; a single edit screen and minibuffer screen together act similarly to normal GNU Emacs. For local minibuffers, the real minibuffer will be located at the bottom of the current edit screen.=20 Yes, GNU Emacs has caught up with much of what Epoch offered more than 20 years ago. And it has added important features that Epoch did not have. But in spite of being the best thing around today, GNU Emacs has still not caught up with some of what Epoch offered, out of the box, many, many moon ago. Strange? "Bizarre" ? Moi, j'ai dit "bizarre, bizarre" ? Comme c'est drole. Pourquoi aurais-je dit "bizarre, bizarre" ? ... Moi, j'ai dit "bizarre" ? Comme c'est bizarre. http://www.youtube.com/watch?v=3DKu-ChVdBwDs [Louis Jouvet, "Drole de Drame", 1937] Longer extract (3.5 min): http://www.youtube.com/watch?v=3D4QiuzDEWD8I