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 18:37:38 +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> <55419fed-b69d-4d07-81b2-b5b70f113929@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1372698410 11981 80.91.229.3 (1 Jul 2013 17:06:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 17:06:50 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 19:06:52 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 1UthYw-0005ck-Nu for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 19:06:51 +0200 Original-Received: from localhost ([::1]:57829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UthYw-00005M-8x for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 13:06:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UthYs-00005A-AT for emacs-devel@gnu.org; Mon, 01 Jul 2013 13:06:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UthF1-0005be-Ja for emacs-devel@gnu.org; Mon, 01 Jul 2013 12:46:17 -0400 Original-Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]:56247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uth7L-0000aL-R7 for emacs-devel@gnu.org; Mon, 01 Jul 2013 12:38:19 -0400 Original-Received: by mail-ie0-f179.google.com with SMTP id c10so10000896ieb.10 for ; Mon, 01 Jul 2013 09:38:19 -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=XgUzbr4lL/BWZTUlKR05bm2RaO7cnVDqasiK0M7KMMs=; b=nesJaS70vmMMuLyd9jBvbhZ1vD08g3e8bqAhxqxbVCc+uNmGTVXYgRkpGhTF/qjE2J ocqtrhReSX/iCP6RRw5y1sxknt7KX86OJncXzv6n0JHkn++EMsOT7ctlzGA49PA6E7Ei hEllS+k0viaVymYHqKVL+32V5lW+5NHDKEhJfNT3C8RzW/+g1e7A5C3VngOfCkDINcem V7MagU1CCsoZvrOJg8+6bP0miyvceKyuj6+s4ATuG5FbF37px/Ewii40wScAbqgr5Mlt 0jgmQZupe2eitbIJpS6MARwiO3nKPAzEh9XpAM75T/fP7dFK+j+M1FCVuvC1i9gYfS5b h74g== X-Received: by 10.50.1.20 with SMTP id 20mr15902382igi.56.1372696698552; Mon, 01 Jul 2013 09:38:18 -0700 (PDT) Original-Received: by 10.64.126.161 with HTTP; Mon, 1 Jul 2013 09:37:38 -0700 (PDT) In-Reply-To: <55419fed-b69d-4d07-81b2-b5b70f113929@default> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::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:161419 Archived-At: On Mon, Jul 1, 2013 at 6:03 PM, Drew Adams wrote: > 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. In many cases, the user will already have set up other frames in precise detail, the initial one for example (until now, I usually set my initial frame with specific size & position). But if she moves the frame and saves Emacs, she will expect the frame to restore at the new position, not the one in initial-frame-alist. I don't really see why moving a minibuffer-only frame from its default position should be different (other that because it is harder to implement correctly, of course ;-). > 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 > "feature" of recording & restoring a standalone minibuffer frame. I've tested that and it works, but it is a bit jarring. Your frame will restore at the same place it was saved, but the new minibuffer frame is restored all over the place. Of course, if you set up minibuffer-frame-alist for a specific position, it will be recreated there, which is still jarring if you've moved the main frame. That said, as a last resort I can live with not saving the minibuffer-only frame and document clearly that the user is reponsible of its appearance *and* position and should set minibuffer-frame-alist correctly when using desktop-restore-frames. > 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. Yes. > 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. No idea. > That is at least the first behavior to try out for your prototype, IMO. Already tested. Now let me try with saving&restoring the minibuffer-only frame; I can fall back to your proposal easily enough. > 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. That's currently not possible because we don't have a way to identify a window (in the window state returned by window-state-get). Martin said it could be added, if required, but let's try to avoid it if at all possible. > Every beast is a strange beast. Every Emacs feature that one is not > used to using seems strange at first. You're talking about UI. I can understand why you do think that they are not that strange (or stranger than any other setup). I was talking about implementation. From a cursory look at frames.el and other code, I'd say minibuffer-only frames add a lot of complexity. > 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. Individual tastes and diversity are wonderful things. From using minibuffer-only frames for a few minutes, I wouldn't touch them with a ten foot pole. Multi-frame setups yes, they are nice and, as Stephen said, in many cases is easier to deal with many open frames than switch between Emacs windows. But I fail entirely to see the appeal of having the minibuffer in another frame. Which is not to say that I won't work hard on make them work with this feature ;-) > http://www.youtube.com/watch?v=Ku-ChVdBwDs > [Louis Jouvet, "Drole de Drame", 1937] Funny. Juanma