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: Tue, 2 Jul 2013 02:25:57 +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 1372724804 18016 80.91.229.3 (2 Jul 2013 00:26:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2013 00:26:44 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 02 02:26:46 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 1UtoQf-0001jb-D8 for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 02:26:45 +0200 Original-Received: from localhost ([::1]:36246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtoQe-0003f4-Vl for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 20:26:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtoQa-0003eq-My for emacs-devel@gnu.org; Mon, 01 Jul 2013 20:26:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtoQY-0003zK-K0 for emacs-devel@gnu.org; Mon, 01 Jul 2013 20:26:40 -0400 Original-Received: from mail-ee0-x233.google.com ([2a00:1450:4013:c00::233]:44250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtoQY-0003zB-Ax for emacs-devel@gnu.org; Mon, 01 Jul 2013 20:26:38 -0400 Original-Received: by mail-ee0-f51.google.com with SMTP id e52so2366735eek.24 for ; Mon, 01 Jul 2013 17:26:37 -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=yVbzv9BXe/1blu553m07BnQsKHbphXD7rErzPvJiroo=; b=v9YfQyRz4/dopWgTE1lnaVx9JJ69G2TAdWSxJl57mHfq18raTQ+ecQo2Q9kPxB0cTr abn2vFpJ/ykG9IZdRcW1glY7Ho+eYafZBcWBgNQGYcsq7vBFXXDkjaDENEhYJzNOqe8R b3OKHbrdDKC0wqNbS5eXOyFQApZe2Zk1sgO+qMNZfsO5twXLUGXftq2+sALLN9ou972g 70E4RKvA5fuD8USAbIK3u3PRL30oBY6CH64Nv1S1sNC804MxefW7XHpptvfnTOKdCOKN rBVjuo++xlVxwLHYzKKB0/JFToq98HSd9WqvGawyTZQR1H0P89zqCBlChEn6z8sN0GFD FceA== X-Received: by 10.15.21.78 with SMTP id c54mr23371291eeu.14.1372724797602; Mon, 01 Jul 2013 17:26:37 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Mon, 1 Jul 2013 17:25:57 -0700 (PDT) In-Reply-To: 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:161435 Archived-At: > On Mon, Jul 1, 2013 at 8:03 PM, Drew Adams wrote: > "Already" when? You mean before restoring a desktop? If so, agreed. Yes. in the init file, or via X resources / W32 registry. > Restore when? In all this discussion, when I say "restore" I'm mostly talking about automatic (desktop) restoration while starting emacs, but I don't think a later M-x desktop-read would be any different. > Sorry, I don't follow you. Restore how - via a desktop? Yes. > I don't see `initial-frame-alist' entering the discussion anyway, but that > might be because I don't make any use of it. I use only `default-frame-alist'. That doesn't really change much of what is being discussed. > Typically, a user with a standalone minibuffer will (must?) set it up when Emacs starts, > from the command line or the init file. If s?he then moves that frame > for some reason, I would NOT assume that s?he wants the next Emacs session to > remember the last position/size of that frame. I would assume that the same > startup code would be used to configure the frame anew the same way. That's weird. If I set up default-frame-alist to create frames of size 80x50, and then I resize them, after desktop-save/desktop-read (or exit Emacs and restart it) I would expect them to be just like I left them, not how the "code to configure the frame[s] anew" would make them. That's the *whole* reason I'm using desktop-restore-frames. I assume you would expect the same. How is the minibuffer-only frame any different? > IOW, I would assume that if a user wants to change what the standalone minibuffer > frame looks like, s?he would do that in the startup code. Yes, for new minibuffer frames. But when you're using desktop-restore-frames, you're asking your frames, and the changes (in size, position, window setup and buffers displayed) to be persistent... Hmm. While writing the above sentences, it dawned on me: it seems like you're thinking of desktop-restore-frames as a way to set (quasi-)immutable snapshots (or desktop bookmarks). You want to use them to be able to roll back to defined window&frame states. Is that so? That is, of course, perfectly valid, but desktop-restore-frames must also support a more transient use case, where what the user wants is for the current state to be saved upon exit and restored on restart. If I were to use a separate minibuffer-only frame, my expectation would definitely not be for that frame to appear always at the sample place, but at the place it was when I exited from Emacs. To me, that's not a new frame recreated anew in each Emacs run (though it really is, from Emacs' POV); it's the same one I moved aside or resized in my previous working session. > Or perhaps, if there is already a minibuffer frame, just MODIFY its parameters > based on the recorded ones from the desktop - as opposed to creating a new > minibuffer frame. That's more or less what I'm trying right now. > In any case, I think you need to avoid trying to create another minibuffer frame. > And avoiding that might just eliminate some of the problems I saw. (Dunno.) Yes, agreed. Creating a second minibuffer-only frame would be a bug. > What "new minibuffer frame"? My suggestion was to NOT record or restore > a minibuffer frame. So restoring a desktop should not be creating any "new > minibuffer frame". I think you're talking about a desktop-save/desktop-read use case: that is, you say that if you have a current setup, with a minibuffer-only frame, and you do M-x desktop-read, no new minibuffer-only frame should be created. And I was talking about kill-emacs / run emacs. A new minibuffer-only frame is created. > It's hard to talk about this and follow each other, with just descriptions. > I suggest we take it off list for a while and we stick to easy-to-follow > recipes. OK, though public discussion helps to integrate other people's opinions. Surely you're not the only one using multi-frame setups and minibuffer-only frames :-) > IOW, we might be able to (optionally) accommodate > save/restore of a minibuffer-only frame, if the restore operation avoided > trying to create a new standalone minibuffer frame when one already exists. Of course, that's always been the goal. Let's not forget that we're talking about unfinished code and evolving designs here. > Great. Good to hear that at least the simple solution works. (That should > be enough for my own use.) Yes, though it wouldn't be for mine, if I used a setup like yours. Now would be a great time for different opinions to enter the discussion (hint, hint). > As to the missing appeal: > > 1. Single place to look for all user command input and echoed messages. > No matter what frame might be selected, your visual focus for commands and > messages is always the same. In my case, that would be a disadvantage, when using multiple frames (for a one-work-frame, one-minibuffer-frame, I could bear it, though it wouldn't really be much different or better than the default setup). Non-locality kills me. That's the same reason, I suppose, I can not stand the recentering scrolling of stock Emacs and must resort to line-by-line scrolling. > 2. Long, long minibuffer - full-screen width. > And in my case, expands to any number of lines. (I use the minibuffer for > lots of stuff, including sometimes large sexps.) You don't need minibuffer-only frames for that. I have my minibuffer set up so it can grow up to 1/3 of the frame height, which I find more than enough for most uses. You could potentially make it almost full-screen height. > However, if Emacs did dynamicaly show/hide minibuffers in frames that way, > it might be distracting/disorienting. In any case, I would prefer the > single-location, permanent, standalone minibuffer frame solution. Goes to show why both of us use the Extensible, Customizable Text Editor. J