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 11:03:37 -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> <55419fed-b69d-4d07-81b2-b5b70f113929@default> 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 1372701834 17229 80.91.229.3 (1 Jul 2013 18:03:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jul 2013 18:03:54 +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 20:03:54 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 1UtiS9-0002Ju-1P for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 20:03:53 +0200 Original-Received: from localhost ([::1]:36501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtiS8-0004Ji-K2 for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 14:03:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtiS2-0004DS-FJ for emacs-devel@gnu.org; Mon, 01 Jul 2013 14:03:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtiRz-0003I9-Te for emacs-devel@gnu.org; Mon, 01 Jul 2013 14:03:46 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:16660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtiRz-0003Hh-LX for emacs-devel@gnu.org; Mon, 01 Jul 2013 14:03:43 -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 r61I3cXd008782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jul 2013 18:03:39 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 r61I3b89005974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 18:03:38 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r61I3bEL020405; Mon, 1 Jul 2013 18:03:37 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: 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:161421 Archived-At: > > 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. >=20 > In many cases, the user will already have set up other frames "Already" when? You mean before restoring a desktop? If so, agreed. That was my point, wrt the minibuffer frame: a user will already have it set up, before trying to restore a desktop. > 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 Restore when? > at the new position, not the one in initial-frame-alist. Sorry, I don't follow you. Restore how - via a desktop? 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-ali= st'. I guess if I wanted to see the initial frame with different properties from `default-frame-alist' then I would do something like this: (setq default-frame-alist nil initial-frame-alist '((background-color . "Whatever"))) default-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 implemen= t > correctly, of course ;-). It's not clear to me what you mean by restoring, or when that happens. 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 t= hat 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 sam= e startup code would be used to configure the frame anew the same way. IOW, I would assume that if a user wants to change what the standalone mini= buffer frame looks like, s?he would do that in the startup code. Perhaps you are suggesting something like this: A user might want different desktops that have different standalone minibuffer properties (e.g. size, p= osition). If so, yes, I can see that possibility. But I would advise leaving handlin= g that possibility for later, as it's not obvious in that case how to deal wi= th the various problems I reported to you (separately). There needs to be (IM= O, AFAIK) at most one standalone minibuffer. Perhaps one solution would be to go ahead and (as you have done so far, I believe) record the standalone minibuffer frame, but when it comes to resto= ring from a desktop, do NOT try to restore it if there already is a standalone minibuffer frame. Or perhaps, if there is already a minibuffer frame, just MODIFY its paramet= ers based on the recorded ones from the desktop - as opposed to creating a new minibuffer frame. 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.= ) > > 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. >=20 > 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. 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". > 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 ma= in > frame. 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. > 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. I'd suggest that we start with that. See my other suggestions above, for possible use afterward. 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. > > That is at least the first behavior to try out for your prototype, IMO. >=20 > Already tested. Now let me try with saving&restoring the > minibuffer-only frame; I can fall back to your proposal easily enough. Great. Good to hear that at least the simple solution works. (That should be enough for my own use.) > > Every beast is a strange beast. Every Emacs feature that one is not > > used to using seems strange at first. >=20 > 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. I see. Yes, I mistakenly thought you were talking about a user point of vi= ew. > 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 ;-) Thanks for the last part. ;-) 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 a= nd messages is always the same. 2. Long, long minibuffer - full-screen width. And in my case, expands to any number of lines. (I use the minibuffer f= or lots of stuff, including sometimes large sexps.) 3. Less wasted screen real estate. This (minor) advantage would go away if Emacs showed a minibuffer only for the selected frame. No need for e= ach frame to show a minibuffer/echo area, even if it cannot currently be use= d. However, if Emacs did dynamicaly show/hide minibuffers in frames that wa= y, it might be distracting/disorienting. In any case, I would prefer the single-location, permanent, standalone minibuffer frame solution.