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: Wed, 3 Jul 2013 10:01:08 -0700 (PDT) Message-ID: <8d0b9141-22a7-482e-922b-1c2dc109f01b@default> References: <51C5AA68.4000204@alice.it> <4E4C522D-DBCC-4133-A764-82C9CCE81E2D@swipnet.se> <8913208E-7FE2-41F5-AC93-000108413C47@swipnet.se> <51D126A4.50402@gmx.at> <55419fed-b69d-4d07-81b2-b5b70f113929@default> <51D3EE8D.3040306@gmx.at> <9d1b8879-0484-4a66-867f-becc4a9dabea@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 1372870883 4904 80.91.229.3 (3 Jul 2013 17:01:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2013 17:01:23 +0000 (UTC) Cc: martin rudalics , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 19:01:23 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 1UuQQk-0001vJ-SM for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 19:01:23 +0200 Original-Received: from localhost ([::1]:36578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuQQk-00050w-IM for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2013 13:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuQQe-0004vG-I1 for emacs-devel@gnu.org; Wed, 03 Jul 2013 13:01:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuQQd-0007oJ-7S for emacs-devel@gnu.org; Wed, 03 Jul 2013 13:01:16 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuQQc-0007o5-R0 for emacs-devel@gnu.org; Wed, 03 Jul 2013 13:01:15 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r63GsoJL031210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jul 2013 16:54:50 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 r63H19I5013287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 17:01:10 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r63H19G6015300; Wed, 3 Jul 2013 17:01:09 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: 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:161487 Archived-At: > If the font parameter were saved, recreating the frame would use it. Good. > I'm QUITE afraid you will now say that in some cases you want the font > saved (you already said as much), Yes, of course. > but in other cases you would the frames to be "transparent" to the > font, so restoring them woul inherit the current default font of > the running Emacs. No, except for user-specified exceptions. A notable exception is a standalone minibuffer frame. I want at least the possibility to tell Desktop not to restore (and even not to save) such a frame; IOW, hands-off. And I am still of the opinion that folks using a standalone minibuffer frame will typically not want additional minibuffers (I'd guess 99.999% of the time, but I could be wrong of course). So I think it would make sense for this particular exception to be the default case. To cite Epoch again, there were two possibilities only: (1) use a standalone minibuffer frame, in which case there were no other minibuffers, or (2) have a minibuffer in each frame. (#1 was the default, and I never saw anyone choose #2. In Epoch there was no chimera possibility such as exists in GNU Emacs. Perhaps it is good that GNU Emacs allows for such a possibility, but IMHO it should not be encouraged - or even allowed for when designing something like Desktop frame support. I just do not see a use case for mixing a standalone minibuffer frame and other frames that have their own minibuffers. No one has spoken up to the contrary, and I doubt you ever will find someone who makes use of that odd possibility. To be clear: Yes, Desktop should save and restore the `font' parameter in general. Yes, users should be able to specify certain frames or types of frames that they do not want saved or that they do not want restored. Yes, users should be able to specify particular frame parameters that they do not want saved or that they do not want restored in general. Yes, users should be able to specify particular frame parameters that they do not want saved (or...restored) for particular frames or particular types of frames. IOW, some of the design questions that you are raising should in fact be user-specifiable preferences, if that is at all possible. Desktop should provide the knobs for users to easily adjust Desktop to get different behaviors. One size will not fit all. That does not mean, of course, that Desktop cannot or should not have a simple-to-understand default behavior. Whether you can provide all of that flexibility at the outset I don't know, but it should be a goal, IMO. And I'm guessing that it makes sense to consider this from the outset, to avoid painting into a corner. But I'm not familiar with your implementation/design and I can't really say anything specific about this. Just a general heads-up, something to keep in mind. > > I hope that changing the font size will continue to resize the > > frame and associated building blocks. >=20 > Yes. The font value of a frame parameter cannot preclude you doing > (set-default-font "DejaVus Sans Mono-15" nil t) and changing every > frame in sight. >=20 > > I make heavy use of this feature (a frame's font driving size in > > general). It would break most of what I use everyday if this feature > > were to be "fixed" away. >=20 > For features, all input is welcome. For bugs, I would prefer if you > could wait untill you stumble upon it ;-) 100% agreed. (I don't think I've spoken about any bugs.)