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: Wed, 3 Jul 2013 11:03:00 +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> <54cfe77b-f378-4402-b185-21372177ed60@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1372842233 27813 80.91.229.3 (3 Jul 2013 09:03:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2013 09:03:53 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 11: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 1UuIyf-0004HU-Dr for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 11:03:53 +0200 Original-Received: from localhost ([::1]:41642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuIye-0002R0-Ty for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 05:03:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuIya-0002OH-21 for emacs-devel@gnu.org; Wed, 03 Jul 2013 05:03:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuIyU-0006dJ-Gg for emacs-devel@gnu.org; Wed, 03 Jul 2013 05:03:47 -0400 Original-Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]:47072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuIyU-0006d5-AH for emacs-devel@gnu.org; Wed, 03 Jul 2013 05:03:42 -0400 Original-Received: by mail-ie0-f173.google.com with SMTP id k13so15095601iea.32 for ; Wed, 03 Jul 2013 02:03:41 -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=Mc8vaPj7D0xD5833tybsr7GE6embYSJARoveOA/17c0=; b=QDDvp4r8HtR3SbBkMXDPmK9jYQwCAg8X2198OQnp36v452WYzvVnIhv1k0QakKE96Z OrpMOuL656CyFtsU/bleG5NDwrbgt33YOhspzFiJ6u4gjALdpxYtC6i4/79Chxinm6eU u4UK6H4tVkT12wqFGVgOq1qQWuffxUs78JESivX8lyLDnN9C6L0pgM8FnUob+lUtO4OR uexd5F7tgveiteZLJDFvSNfBOzgwhtTiRCGKdEsQ3mOu/ISt6Y2YoistnEE1gLNmaQlz Do1vCZxv8Zbtyoto46XjSxPl1boU8leVNKazXb2goSDZn7eSJ/BzXmsZZJcNi8vKCtGw /R3g== X-Received: by 10.42.32.132 with SMTP id e4mr1456419icd.118.1372842221729; Wed, 03 Jul 2013 02:03:41 -0700 (PDT) Original-Received: by 10.64.250.7 with HTTP; Wed, 3 Jul 2013 02:03:00 -0700 (PDT) In-Reply-To: <54cfe77b-f378-4402-b185-21372177ed60@default> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22d 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:161456 Archived-At: On Tue, Jul 2, 2013 at 9:40 PM, Drew Adams wrote: > 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. Please, don't take my comment as more than it was, just that I thought that my use case is equally common. Wasn't accusing you of anything. :-) > 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. Sure. > 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. I agree that ways of specifying more generic behavior would be good. > 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. For the "across the screen" bit you can of course use (fullscreen . fullwidth), though I see an interesting bug where the frame does not really goes fullwidth until selected. But for positioning it at the bottom, (top - N) is only a crude tool that requires some code. > Yes, GNU Emacs has taken over the landscape, > but that was not because of Epoch's standalone minibuffer. FWIW. I'm sure of that ;-) > Sounds good. That was my guess, that this is just something that you > cannot implement immediately, for whatever reasons. Because it breaks restoring after the roundtrip GUI -> tty -> GUI. But it is something I must fix, like the warning messages in that same roundtrip about invalid colors. > Sounds like trying to make a virtue of the necessity of a particular > implementation. No, I'm not. Just that I can see many things that could be customizable (via defcustom, I mean) but I don't think all should be; only the common ones. At the end, which ones do get their own customization option and which ones do not is not mine (alone) to decide, it's a community thing (and of course, anyone can add further options afterwards even if they didn't strike me as necessary). > 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. In general, I agree. As for the devil in the details: there are things that make sense to delete on saving (like unwanted windows). And in some cases, the code is cleaner if you delete on saving. desktop--restore-frames is already more complex than desktop--save-frames, and I don't think that trend will change. Something to decide feature by feature. > Or accomplish the same end some other way. Worth thinking about. Yes, of course. Perhaps killing some windows/buffers will be a common enough operation that some defcustom should be added, for example. In fact, the example I gave is tricky, because I don't want to delete IELM windows while I'm working (for example, if I do M-x desktop-save during a session). So perhaps that's one of these cases where deleting on restoring is more effective and simple. > Hopefully accomplish the same end another way. This is something users > should be able to do easily. I'm not sure what the UI would be for that. > 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. Yes, you can delete the initial frame, just try this: (let* ((s (selected-frame)) (f (make-frame '((minibuffer . only) (height . 2) (tool-bar-lines .0) (menu-bar-lines . 0))))) (make-frame `((minibuffer . ,(minibuffer-window f)))) (delete-frame s)) > 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. Oh, I think the minibuffer should give the same behavior, but I have not trouble believing you that it doesn't. Lots of tricky details. > 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. As said above, it's not that I think that, it's that the number of possible customizations is unbounded, while the number of defcustoms we can sensibly add is bounded and relatively small, so we have to pick our battles. > Or decide it's not worth it and not use Desktop to restore frames. That's a possibility I cannot avoid in any way. > I hope, at least, that users will be able to use Desktop without the > frame/window restoration. (setq desktop-restore-frames nil) Or, if I we decide to turn it into a pseudo-minor mode, like desktop-save-mode, (desktop-restore-frames -1). > And I hope they will be able to restore > windows & frames without necessarily restoring all the other stuff > that Desktop can handle. As discussed previously, that's a worthwhile goal, but not one I'm pursuing right now. > But you're not necessarily acting on or interacting with a single buffer > or frame, in general. *In general*, yes, I do. If not a single buffer, at least a single window, two at most, more than 99% of the time. And definitely a single frame. > I'm not saying that anyone needs to use a standalone minibuffer. > I'm saying that someone who does do that has a single place to look > for command input/output. Yes, of course. At this point, I'm just explaining why do I think that it isn't a good setup *for me*. > Wait until you are interacting with multiple frames, and there is NO > "main, or only, frame". Then we can talk again about "locality". ;-) My brain is wired to look at nearby places, not always at the same place. Again, that's why recentering scrolling doesn't work for me. I could put my eyes in the center line of the window and enjoy the recentering, but I do not. I really do not. J