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 19:32:20 +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 1372786390 9840 80.91.229.3 (2 Jul 2013 17:33:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2013 17:33:10 +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 19:33:12 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 1Uu4Rz-00073u-SI for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 19:33:12 +0200 Original-Received: from localhost ([::1]:43405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu4Rz-0003If-6r for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2013 13:33:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu4Rt-0003IW-Aw for emacs-devel@gnu.org; Tue, 02 Jul 2013 13:33:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu4Rp-0005vQ-HL for emacs-devel@gnu.org; Tue, 02 Jul 2013 13:33:05 -0400 Original-Received: from mail-ie0-x232.google.com ([2607:f8b0:4001:c03::232]:49598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu4Rp-0005vK-7Y for emacs-devel@gnu.org; Tue, 02 Jul 2013 13:33:01 -0400 Original-Received: by mail-ie0-f178.google.com with SMTP id u16so12935680iet.37 for ; Tue, 02 Jul 2013 10:33:00 -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=qzfSAFyoGQRIBWA3AO+qXbGL7B8FP2ktWF7XriEnPpQ=; b=goy7QXyxM/F09s410DdD0nHEdO8BEvq/sAdS4Cq3Bwpxy4OIZg9HsGSenuT/S4H9GP R8TlQ9yDMGMhNt3M07hkANLcOLYjj7NO0mHEQKlaN4sNtxpatMh8Tw2sTMUTfWphdLyw GFmrDuXWKKu2OiICa6GkTEH/GhcA9PF48CR/dXV5ZLSt0Ls6G0YZV4r8WZam7Af57OP/ uQWjLRxYBfFge0gFsRAa1RI2WOPkyYinElLH7OQid4fbY7YFHoBYaYUf0jF9fTYMBlss sMPOkBVUFk1JRP+T5BXKOJz82nM+xVL9dGqUtBRoj0ezI8YN9HXK7rhyrrXEtSPy1rS6 cv5Q== X-Received: by 10.50.122.65 with SMTP id lq1mr22282614igb.11.1372786380559; Tue, 02 Jul 2013 10:33:00 -0700 (PDT) Original-Received: by 10.64.250.7 with HTTP; Tue, 2 Jul 2013 10:32:20 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::232 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:161448 Archived-At: On Tue, Jul 2, 2013 at 5:46 AM, Drew Adams wrote: > 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. I disagree about "typical" here. The alternate use case I'm suggesting is neither convoluted nor artificial. > 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. 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. > 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. 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). > 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. 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 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. 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. > (I realize that not everything will be perfect in the first draft. > I'm just saying that, to me, restoring the font is important.) Yes, agreed. > 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. 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. > 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. "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. > 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. Nothing overlaps with my Windows taskbar, so I don't need to move it anywhere. > 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! That's what I'm trying to do. > 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. Not exactly, though it will likely not work as expected: (progn (dotimes (i 5) (make-frame '((minibuffer . only) (visibility . icon)))) (mapcar (lambda (f) (frame-parameter f 'minibuffer)) (frame-list))) => (only only only only only #) > (visibility . icon) does not affect the test, is just to avoid cluttering my desktop. > 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. 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. > 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. Yes. Currently there's no hook run just before saving the frames and buffers, but I will have to add one. 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). > 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. Also called M-: (insert (format "(setq minibuffer-frame-alist '%S)" (frame-parameters default-minibuffer-frame))) plus deleting the MOF.plus some hand-tweaking. ;-) >> 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. > But, as I mentioned, since a minibuffer frame must be created during > startup That's not really correct. You can do, at any point in time: (let ((f (make-frame '((minibuffer . only) (height . 2) (tool-bar-lines .0) (menu-bar-lines . 0))))) (make-frame `((minibuffer . ,(minibuffer-window f))))) > 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. M-x report-emacs-bug > 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. 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. > 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. My "simple behavior" would be: do not treat the MOF differently than any other frame. :-) > I agree. That's why I said "for a while". There is also a risk of > boring others and going down a rabbit hole. You mean they aren't already there, hidding from us? > 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 That's locality for me (or at least, for my visual cortex). > Height, but not width. When I said "long" I meant "wide". Ah, interesting. Yes, I can see the appeal of that. J