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 20:46:07 -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 1372736787 26407 80.91.229.3 (2 Jul 2013 03:46:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2013 03:46:27 +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 05:46: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 1UtrXu-00005x-65 for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 05:46:26 +0200 Original-Received: from localhost ([::1]:55172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtrXt-0001j4-M8 for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2013 23:46:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtrXo-0001iw-BO for emacs-devel@gnu.org; Mon, 01 Jul 2013 23:46:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtrXm-0000RV-0O for emacs-devel@gnu.org; Mon, 01 Jul 2013 23:46:20 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtrXl-0000RI-NK for emacs-devel@gnu.org; Mon, 01 Jul 2013 23:46:17 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r623dp0x003384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 03:39:52 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r623k9T8023519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 03:46:09 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r623k8A9023505; Tue, 2 Jul 2013 03:46:08 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: 156.151.31.81 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:161437 Archived-At: > > Typically, a user with a standalone minibuffer will (must?) set it up w= hen ^^^^^^^^^^^^^^^^^^^^^ ^^ > > Emacs starts, from the command line or the init file. If s?he then mov= es > > 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 woul= d ^^^^^^^^^^ > > assume that the same startup code would be used to configure the frame ^^^ > > anew the same way. >=20 > 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? 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 described, i.e., the uses I described as being, I think, typical. And in the fact that it uses `minibuffer-frame-alist', which supersedes `default-frame-alist'. IOW, almost the same answer for why we even have a `minibuffer-frame-alist' user option. > > 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. >=20 > 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... 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 user might well move here and there and resize, I don't see that kind of thing happening typically for a minibuffer frame. I'm not saying that what I think will be the typical case is the only possible case. I think I mentioned that a few times. I can't really speak much to such cases. My experience is with the case I'm assuming will be typical for someone using a standalone minibuffer. Others are free to correct me if they feel otherwise. > 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? No, that would be independent of the considerations I put forth for the minibuffer frame. I see desktops used lots of different ways.=20 A simple and common way will be to simply remember and restore the last state of Emacs, including the sizes, positions, colors, fonts (yes, fonts!), etc. of its frames. 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. Since I mentioned fonts - 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. For me, restoring a frame's font is also required for restoring thumbnail frames. They are, to simplify, tiny frames made tiny by shrinking their fonts. Of course, it is not just font size that matters, but other aspects of the font as well. I change various fields (including size info) of an XLFD font name, and would expect that to be restored by 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.) > 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. See above. Yes, that will a common use case, perhaps the most common. Nothing I've said gets in the way of that use case, if you assume that people will (a) not be dynamically changing a minibuffer frame and (b) will not care to save any dynamic changes they might happen to make to it. (I'm not talking about changes to it that they might make through customization etc., but simply moving or resizing etc.) > 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. 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. > 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. Let me be clear. I have no problem with you doing what you suggest: make a standalone minibuffer behave like others in terms of remembering its state. 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. 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. I would have no problem if Desktop handled the minibuffer frame similarly - modulo certain considerations (below). I will go further: if Desktop handles that right then it lets users not worry about setting things up using Lisp code. They can simply drag the frame to where they want it and give it the size they want, and that will be remembered (provided they start up with Desktop) each time. Formidable! But the devil will be in the details wrt "works well", probably. My setup code creates a new minibuffer frame according to user customizations. If the desktop code can be used in such a way that it does not interfere with that then there will be no problem. 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 at most one such frame. 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. 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. If you offer only (a) then that would be limiting for the user who really does want any last-session changes to the minibuffer frame to be reflected in the new 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. >=20 > That's more or less what I'm trying right now. That is (b), above. A user should have the choice. In fact, now that I mention that - 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. Conceivable, at least. I don't use frames that way, but some people might (I too can hypothesize ;-). In my case, I use "special-display" to handle frames that I want to have particular properties. And since that is set up anew each session, and since the properties are anyway frame parameters, I'm pretty sure that Desktop will not be a problem for me here. Nevertheless, yes, it would be good to have a general feature of classifying particular frames off-limits for Desktop, i.e., frames that it either would not record or (probably better) simply would not restore. The latter would probably be better because we could provide a runtime way to override this prohibition on Desktop, i.e., to let a user allow Desktop to restore a particular frame classified generally as off-limits. There are lots of possibilities. I'd say handle the simple case(s) first. And in my view, leaving the minibuffer frame alone is the simple (common) case. IOW, if you have a minibuffer frame then I think you probably want it in the same place each time. Again, someone will correct me if they think otherwise. And again, if you can make it work well and be flexible then it would be an advantage to be able to directly manipulate the frame into the size and position that one wants to keep. Desktop could perhaps help there, but I would rather see such direct-manipulation translated into customization. IOW, once you get something like a minibuffer frame the way you generally want it, you want to be able to say Basta! Hands off from now on, until I change my mind. > > 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.) >=20 > Yes, agreed. Creating a second minibuffer-only frame would be a bug. It wouldn't be possible, AFAIK. What would happen is (likely) what we saw: only one of the frames would get the `only' value of parameter `minibuffer'. But I think we are really saying the same thing here, describing it differently. We don't want two frames trying or pretending to each be the minibuffer frame, even if only one can ever really be such. > > 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". >=20 > 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. Yes. > And I was talking about kill-emacs / run emacs. Meme combat - from my point of view. Not the same use case, but I feel the same about both cases. > A new minibuffer-only frame is created. But, as I mentioned, since a minibuffer frame must be created during startup, it will be created (anyway) by the user's startup code. 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. Or maybe s?he will now have to worry about having conditional code that checks whether desktop (which might have run first) has already created a standalone minibuffer, and then skip doing that in the user startup code. IOW, either Desktop or the user will need to worry about avoiding an attempt to create a second minibuffer frame. I would rather it be Desktop, a priori. See above for possible extensions to allow users to let Desktop restore (i.e., create or modify) a minibuffer frame. 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. > > 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. >=20 > OK, though public discussion helps to integrate other people's > opinions. I agree. That's why I said "for a while". There is also a risk of boring others and going down a rabbit hole. My suggestion was to get through the vague discussion part using simple recipes instead, then report back and get more input/discussion. But I'm OK with either way, as I've shown by this message. ;-) > Surely you're not the only one using multi-frame setups and > minibuffer-only frames :-) I would hope not. But I would unfortunately be willing to bet that among those reading emacs-devel we are not a multitude. ;-) > > 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. >=20 > Of course, that's always been the goal. Let's not forget that we're > talking about unfinished code and evolving designs here. Not to worry. ;-) > > Great. Good to hear that at least the simple solution works. > > (That should be enough for my own use.) >=20 > 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). +1 to that. > > 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 comman= ds > > and messages is always the same. >=20 > 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. 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, but in the sense that the focus stays the same for command I/O. I probably spend a lot more time in the minibuffer than most. But what I do there involves interactions with other frames - in particular a standalone *Completions* frame. If the minibuffer and *Completions* buffer were jumping all around from frame to frame it would be very distracting. But as you noted, everyone is different. After I tried Epoch (with its standalone minibuffer) a couple of decades ago, I never went back, even though it was a hassle to wrestle GNU Emacs into doing something similar. > > 2. Long, long minibuffer - full-screen width. > > And in my case, expands to any number of lines. (I use the minibuff= er > > for lots of stuff, including sometimes large sexps.) >=20 > 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. Height, but not width. When I said "long" I meant "wide". Being part of an ordinary frame, your minibuffer cannot be screen-wide, unless the frame is too. I decouple the width I need for (a) a given frame, which is typically the width of its text, which is typically of a fixed line length (different for different kinds of buffers, of course) from (b) the width of my minibuffer. There is no logical relation between the width (I still want to say "length", when talking about line length) of (a) minibuffer input and echo area output and (b) ordinary buffer text. Just as I want to fit most frames to their (typically single) buffer text, so I want to have a minibuffer that is not limited to the width of any other buffer's text or window. Why should it be? > > 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. >=20 > Goes to show why both of us use the Extensible, Customizable Text Editor. Si.