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: Tue, 2 Jul 2013 12:40:10 -0700 (PDT) Message-ID: <54cfe77b-f378-4402-b185-21372177ed60@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> <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 1372794037 31202 80.91.229.3 (2 Jul 2013 19:40:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2013 19:40:37 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 02 21:40:36 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 1Uu6RC-00024r-1t for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 21:40:30 +0200 Original-Received: from localhost ([::1]:52731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu6RB-0007qE-Na for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 15:40:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu6R5-0007q4-50 for emacs-devel@gnu.org; Tue, 02 Jul 2013 15:40:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu6R1-0003Pg-Jy for emacs-devel@gnu.org; Tue, 02 Jul 2013 15:40:23 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:29836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu6R1-0003PR-9c for emacs-devel@gnu.org; Tue, 02 Jul 2013 15:40:19 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r62JeDvw022035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 19:40:14 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r62JeCLX022494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 19:40:13 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r62JeC6l023943; Tue, 2 Jul 2013 19:40:12 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: ucsinet21.oracle.com [156.151.31.93] 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:161451 Archived-At: > > I was talking only about a standalone minibuffer frame. Sorry if that > > was not clear. How is it different? In the ways I've already describe= d, > > i.e., the uses I described as being, I think, typical. >=20 > I disagree about "typical" here. The alternate use case I'm suggesting > is neither convoluted nor artificial. 1. I was quite clear that it is just a guess on my part wrt the typical or common use case for a minibuffer frame. I gave reasons why I think this might be likely, including the fact that to have such a frame a user must set it up during startup, and `minibuffer-frame-alist' is a customization. 2. No one has said that anything you have suggested is convoluted or artificial. I don't even think that, let alone have not said it. > > And in the fact that it uses `minibuffer-frame-alist', which supersedes > > `default-frame-alist'. IOW, almost the same answer for why we even hav= e > > a `minibuffer-frame-alist' user option. >=20 > Well, the initial frame also has a `initial-frame-alist' that > supersedes `default-frame-alist', but you're not proposing to treat it > different that other (non-minibuffer-only) frames. I'm no expert on any of this stuff, but certainly not about `initial-frame-alist'. Its doc string, like that of `minibuffer-frame-alis= t', says that it "supersedes" `default-frame-alist', without saying what that means. What I said about `m-f-alist' is based on my experience with it. I have almost no experience with `i-f-a'. If you feel it should be handled the same as is `m-f-a', give that a try. > > In general, yes. My assumption was that that is not generally the case > > for a standalone minibuffer frame. Whereas there can often be many > > frames that are built off of the `default-frame-alist', and which a use= r > > might well move here and there and resize, I don't see that kind of thi= ng > > happening typically for a minibuffer frame. >=20 > My assumption is that, just as `initial-frame-alist' is a template for > the first frame (but changes are persistently saved by > desktop-reuse-frames), `minbuffer-frame-alist' is a template for the > minibuffer-only frame, but once created, the user is free to change it > (and expect these changes to stick). We have different assumptions wrt the typical use of `m-f-alist'. Yes, anyone is free to change properties of the minibuffer frame after it is created. So what? It does not follow that everyone or most will want Desktop to save and restore such changes. Time will tell, I guess. Here's another data point you might consider: AFAIK, Desktop will save and restore frame parameters, but those parameter values at any time do not necessarily specify the frame completely from a user point of view. What do I mean by that? In oneonone.el, for example, the position and size of the minibuffer frame is customizable. But generally I recommend that absolute values not be=20 used for this and that users instead let the code determine the width and necessary `top' value to position the frame across the full screen width at screen bottom. That way, the frame is created correctly regardless of what screen you view it on: laptop, large monitor, remote VNC window mgr... IOW, whereas what frame parameters record are literal values, what a user might want to express in some cases can be a behavior that does not reduce to a literal value. In Lisp terms, if frame paramters included functional values then we might be talking apples & apples, but until then we are talking apples & oranges. Note that the recently added `fullscreen' parameter values are similar to specifying functional behavior: they do not specify frame boundaries explicitly but record the user wish that the frame fill the full screen or whatever. The implementation presumably leaves it up to the window mgr to implement that function, and one cannot specify an arbitrary function, but the idea is a bit similar: we do not record literal frame coordinates & boundaries for a fullscreen frame. If useful or common values (symbols) were implemented to encompass the idea of a minibuffer frame extending across the screen bottom then one would not need code to do that using code. Until then, simply recording and playing back frame parameters will not accomplish the same thing. It's just an example. > > I nevertheless see changes to the > > minibuffer frame due to the dynamic use of Emacs to be something (a) > > rare and (b) you probably do not want to save. >=20 > That's the point where we disagree. That said, you have much more > experience with minibuffer-only frames than me. It'd be good if other > minibuffer-only-frame users would speak now. I have experience only in a limited range. I've made Emacs do more or less what I want; that's all. I can't speak to what others might want. But I would point to the experience of lots of people with Epoch, back in the day - FWIW. As I mentioned, a standalone minibuffer was optional, but it was the default. I never saw anyone who chose not to use it (and I saw lots of people using Epoch). And the frame was at the bottom, stretching the full screen width (IIRC, and I think I do). So my own setup is so particular, it is copied from something that lots of people used to use. Yes, GNU Emacs has taken over the landscape, but that was not because of Epoch's standalone minibuffer. FWIW. > > I think I saw that you mentioned that you cannot currently save/restore > > a frame's font. To me, that ability is far more important that letting > > users record and restore any dynamic changes they might have made to a > > standalone minibuffer frame. It is important to me, at least. >=20 > Not saving the font parameter right now is not a decision or a > feature, just a stopgap measure. Eventually I'll have to revamp the > whole "save/restore frame parameters" code to allow more flexibility, > and then I'll re-save font. Sounds good. That was my guess, that this is just something that you cannot implement immediately, for whatever reasons. Nothing wrong with that. It is wonderful that you are working on this general enhancement to Desktop. > > (I realize that not everything will be perfect in the first draft. > > I'm just saying that, to me, restoring the font is important.) >=20 > Yes, agreed. >=20 > > Where would you expect that you would be moving it, and why? Again, > > I'm not talking about customizing where you want it, and perhaps > > changing your mind about that customization once in a while. >=20 > In my tests of the minibuffer-only frame (MOF from now on), I like to > have it near the main, or only, frame. So if I move the frame aside, > because I want to see something that's below it (let's say I'm typing > something related to something I'm reading in a browser tab), I > immediately move the MOF too. I suppose that's uncommon for you > because you put the MOF at a fixed place in the screen, likely not > overlapping or overlapped with any other application's window. That's > not how I work, I have Chrome open all the time, and it uses perhaps > 80% of my screen space, so other things, including Emacs, do overlap > it. Moving Emacs aside is a pretty common operation for me. Got it. I could be wrong, but I'd suggest using it for a month and then see what you think. Not joking. I don't pretend to have discovered the only way of working with frames - far from it. But I have a right to guess. ;-) > > I was trying to make your job easier by pointing out that > > in most cases no one need that feature. But if it works well then I > > have no problem with it. >=20 > "Works well" is not how I would define it right now. "Works most of > the time" is more like it, but of course, that difference is quite > important. So I don't reject at all the idea of falling back into the > do-not-save-MOF implementation strategy; I'm just wasting a little > time trying alternatives. That's good to do, and not a waste, no doubt. > > Here's a probably lousy analogy, but it is one that comes to my mind: > > The Windows task bar. You can move it to the top, bottom, left or > > right. Most people do not move it every 30 minutes. Moving it is, > > effectively, customizing its position. But yes, the fact that Windows > > remembers the last position as the customization is fine. >=20 > Nothing overlaps with my Windows taskbar, so I don't need to move it > anywhere. Things don't overlap my MF, unless I put them there (e.g., make something fullscreen). But I do hear what you are saying (and I did say it was a lousy analogy - if it doesn't help, ignore it). =20 > > if Desktop handles that right then it lets users not worry about settin= g > > things up using Lisp code. They can simply drag the frame to where the= y > > want it and give it the size they want, and that will be remembered > > (provided they start up with Desktop) each time. Formidable! >=20 > That's what I'm trying to do. Great. =20 > > You might want to reread what I wrote about the creation of a > > minibuffer frame. To have one, you need to create it during startup. > > That means that users do so in their Emacs startup. And there can be a= t > > most one such frame. >=20 > Not exactly, though it will likely not work as expected: >=20 > (progn > (dotimes (i 5) (make-frame '((minibuffer . only) (visibility . icon)))= ) > (mapcar (lambda (f) (frame-parameter f 'minibuffer)) (frame-list))) OK. > > If a user uses Desktop to restore the last state and that state now > > tries to also restore a saved minibuffer frame, then that restoration > > code needs to check whether there is already a minibuffer frame, and if > > so then either (as I said before): (a) ignore its saved info for the > > minibuffer frame (leave the user's frame alone) or (b) MODIFY the > > already existing minibuffer frame - as opposed to trying to create > > another such. > >=20 > > If you implement a way for a user to choose between (a) and (b), no > > problem. If you offer only (b) then that would be limiting for a > > user who wants to control the frame properties via setup at start time. >=20 > Not really. She could use desktop-after-read-hook to reapply settings, > for example. Some things we should allow via customization options, > some others via hooks, etc. It is too soon to decide which one belongs > to each category, I think. And customization options can always be > added later as needed. Sounds like trying to make a virtue of the necessity of a particular implementation. I sincerely hope that you allow for both (a) and (b) and give users a choice. > > Users use frames for different things. A user might well have > > particular other frames, besides the minibuffer, that s?he wants to > > have defined each time based on a startup-time setup, i.e., that s?he > > does not want to have changed by Desktop. >=20 > Yes. Currently there's no hook run just before saving the frames and > buffers, but I will have to add one. In general, I would suggest saving stuff but letting restoration ignore some of it, according to user preference etc. IOW, it seems like it would be more flexible to save and optionally not restore than to optionally not save (and then not have the possibility of restoring). This is assuming other things are equal, which they might not be. But if they are, then late binding here is better: let the decision be made at the next session. What I said earlier about use with different monitors applies here as well. Your next session might be with a different monitor or on a different platform. Users might use desktop files across different platforms, equipment/media, whatever. You can easily do that now, using desktop bookmarks, for instance. As a general rule, it is more flexible to let the consuming software/session decide, not the producing software/session. Again, assuming other things are equal, which you can judge better than I. > A practical example where I need > it: I very often have IELM buffers open. IELM is the kind of buffer > that does not make real sense to save&restore, because its usefulness > often depends on its state (variables changed, commands typed, etc.). > So I add it to desktop-buffers-not-to-save or > desktop-modes-not-to-save... But window-state-put will restore the > "buffer", if empty and in fundamental-mode. So I really need to be > able to run a hook before desktop--save-frames which runs > (delete-windows-on (get-buffer "*ielm*") 'all). Or accomplish the same end some other way. Worth thinking about. > > IOW, once you get something like a minibuffer frame the way you general= ly > > want it, you want to be able to say Basta! Hands off from now on, until= I > > change my mind. >=20 > Also called M-: (insert (format "(setq minibuffer-frame-alist '%S)" > (frame-parameters default-minibuffer-frame))) plus deleting the > MOF.plus some hand-tweaking. ;-) Hopefully accomplish the same end another way. This is something users should be able to do easily. > > But, as I mentioned, since a minibuffer frame must be created during > > startup >=20 > That's not really correct. You can do, at any point in time: >=20 > (let ((f (make-frame '((minibuffer . only) > (height . 2) > (tool-bar-lines .0) > (menu-bar-lines . 0))))) > (make-frame `((minibuffer . ,(minibuffer-window f))))) AFAIK, you will never be able to get rid of the frame created initially, which has its own minibuffer. That was the point here. If you want a standalone minibuffer frame, and if you want it to be the only such (which I would again argue is the typical case of MF users), then AFAIK you must create the MF at the outset. Believe me, I've submitted enough bug reports for which I had to point out a startup sequence, because adding a standalone minibuffer frame later does not give you the same behavior. > > Now just maybe, if you make Desktop get in the act and try to restore > > the minibuffer frame, the user will then need to start worrying about > > just when to invoke Desktop, relative to the user code that creates the > > minibuffer frame. >=20 > M-x report-emacs-bug Better to think about some of these things ahead of time. Sounds like you're thinking more in terms of hooks to dance around Desktop than customization options to prevent it from doing the things you would have users dance around. I could be wrong but that's my impression based on some of what you wrote above. I would sooner you implemented (a) and (b) above, and let users choose. > > Or maybe s?he will now have to worry about having > > conditional code that checks whether desktop (which might have run firs= t) > > has already created a standalone minibuffer, and then skip doing that > > in the user startup code. >=20 > At some point, for some combination of user customizations and use > cases, the user will have to resort to worring and checking and > configuring via hooks. I wouldn't have ~2,000 lines in my .emacs if > that were not the case. Or decide it's not worth it and not use Desktop to restore frames. I hope, at least, that users will be able to use Desktop without the frame/window restoration. And I hope they will be able to restore windows & frames without necessarily restoring all the other stuff that Desktop can handle. IOW, I hope we give users control over the various things that Desktop can save & restore. And I hope that control will be available both in terms of saving (don't bother saving stuff you know you don't want to restore) and in terms of restoring (save, but do not restore if told not to - see above for the flexibility this offers, at a cost of save/restore time and desktop-file storage space). > > But the default Desktop behavior should, IMO, be the simple one (from > > a user point of view): YAGNI, i.e., Desktop hands off the minibuffer. >=20 > My "simple behavior" would be: do not treat the MOF differently than > any other frame. :-) Which is why I wrote "from a user point of view". I'm not interested here with simplicity of implementation. Of course, we can disagree about what is simpler for a user. Again, I'd point to Epoch users... > > There is more locality, not less. Not in the sense that the minibuffer > > is always closer to the particular buffer text you're editing/reading >=20 > That's locality for me (or at least, for my visual cortex). But you're not necessarily acting on or interacting with a single buffer or frame, in general. That's another difference I didn't mention. I use the minibuffer more, but I also use it to act on multiple buffers and frames during the same minibuffer "session" (the command calling for minibuffer input, completion in particular). When using the minibuffer, even when my eye is not on the minibuffer and not on *Completions*, it can easily move among multiple = frames/buffers. In this context, the most central, static, or "local" location during the interaction is the minibuffer - it is the center of the action. I'm not saying that anyone needs to use a standalone minibuffer.=20 I'm saying that someone who does do that has a single place to look for command input/output. You said: > In my tests of the minibuffer-only frame (MOF from now on), I like to > have it near the main, or only, frame. Wait until you are interacting with multiple frames, and there is NO "main, or only, frame". Then we can talk again about "locality". ;-) > > Height, but not width. When I said "long" I meant "wide". >=20 > Ah, interesting. Yes, I can see the appeal of that. Cheers - and thanks again for working on this. It will be a welcome addition to Emacs.