From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Mon, 29 Apr 2013 07:10:28 -0700 Message-ID: <281755A4CB9C4DF9A5D2700E4FF26900@us.oracle.com> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org><517257A0.4080607@gmx.at> <8338ul1rmb.fsf@gnu.org><517275A0.1040702@gmx.at> <83wqrxzbc7.fsf@gnu.org><51729A6A.7090404@gmx.at> <83mwstyxre.fsf@gnu.org><5172D1D6.8030200@gmx.at> <83bo99ys79.fsf@gnu.org><5173B0B2.9070607@gmx.at><51750438.5060106@gmx.at><8C0357F6-5720-42E5-90EB-B83416F0344E@swipnet.se><51762F4D.7070101@gmx.at> <8361zdxll8.fsf@gnu.org><51777DF3.5030206@gmx.at> <83fvyfx3c1.fsf@gnu.org><5178DB50.20404@gmx.at> <834neuvas1.fsf@gnu.org> <517A2FCE.30006@gmx.at> <97FD826D96FF4DAA91192817D475A0B3@us.oracle.com> <517B776B.2080007@gmx.at> <517D1370.5070603@gmx.at> <7843BFD1369F48989C7E86E60FFA0C0A@us.oracle.com> <517E225E.9010906@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367244710 4185 80.91.229.3 (29 Apr 2013 14:11:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 14:11:50 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 29 16:11:52 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1UWoo3-0001fS-Us for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 16:11:52 +0200 Original-Received: from localhost ([::1]:50972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWoo3-0007Ql-GX for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 10:11:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWony-0007QU-ET for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 10:11:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWonw-0005LH-Kj for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 10:11:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWonw-0005LA-Gf for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 10:11:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UWooD-0007Kv-KF for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 10:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2013 14:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14233 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14233-submit@debbugs.gnu.org id=B14233.136724466828000 (code B ref 14233); Mon, 29 Apr 2013 14:12:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 29 Apr 2013 14:11:08 +0000 Original-Received: from localhost ([127.0.0.1]:50385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWonL-0007HU-9i for submit@debbugs.gnu.org; Mon, 29 Apr 2013 10:11:08 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:33829) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWonI-0007HK-NV for 14233@debbugs.gnu.org; Mon, 29 Apr 2013 10:11:06 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3TEAiYS019748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Apr 2013 14:10:45 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3TEAhgM021297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2013 14:10:44 GMT Original-Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3TEAhcH018506; Mon, 29 Apr 2013 14:10:43 GMT Original-Received: from dradamslap1 (/10.159.75.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Apr 2013 07:10:42 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <517E225E.9010906@gmx.at> Thread-Index: Ac5ErJ9rI5VrAK6hS/S50ULfDlHQ7wAMvWnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:73822 Archived-At: > > Either way, you still have to take into account any > > interdependence among parameters. > > As someone who used this for the first time I'd be surely surprised if > interchanging the order of two alist elements would have any such > consequences. But maybe `modify-frame-parameters' isn't intended for > less experienced users. You would have the same surprise with separate calls to parameter-setting functions: the order matters. Someone who is not aware that a few frame parameters are not independent of each other will be in for a surprise no matter how s?he sets them, if not paying attention to the order of setting. If you think the doc of `modify-frame-parameters' is not sufficiently clear wrt its alist argument (and the same likely applies to other functions or variables, such as `default-frame-alist'), then please add to the doc to make this clearer. Do we even make explicit in the doc which parameters depend on which other parameters? That would be the place to start wrt this problem, not some specific function that sets parameters. > > 1. `set-frame-font' apparently has this side effect, which > > is not appropriate here: > > > > Also, if FRAME is non-nil, > > alter the user's Customization settings as though the > > font-related attributes of the `default' face had been "set in > > this session", so that the font is applied to future frames. > > > > (It should say FRAMES, not FRAME, BTW.) > > > > Why does `set-frame-font' not allow you to change the font > > for a given frame (besides the selected frame), without also > > changing face `default' for future frames? > > Maybe because they would tell you to select the frame first and then > call it with FRAME nil. They who? Sorry, I don't understand. Why does `set-frame-font' not let you act on a given frame (any frame), without also changing face `default' for future frames? That makes no sense to me. Maybe the logic behind that coupling could be made more explicit in the doc? Or maybe that "enhancement" should be reverted? > IMO `modify-frame-parameters' should keep the frame size and > everything else unchanged when changing the font. IMO, it should not. Such an incompatible change will break all of the code I mentioned, for one thing. Why do you suppose that there is an optional parameter KEEP-SIZE for `set-frame-font'? And why do you suppose it is optional (i.e., the default behavior does NOT keep the same size)? And now you propose to, in effect, impose KEEP-SIZE behavior everywhere, and not even provide a no-keep-size optional behavior (i.e., traditional Emacs behavior)? > Changing the appearance of scrollbars, fringes and sizes or the > appearance of future frames should be done on top of that, You are mixing a lot of things in there. Why should `modify-frame-parameters', applied to a single frame, affect future frames at all? That mistake was already introduced into `set-frame-font' (in Emacs 22, I believe). Such future-changing has no business being coupled into the behavior of the basic function for changing a frame's parameters. > for example, by `set-frame-font' albeit in a > more transparent fashion than currently. > > > 2. `modify-frame-parameters' is the basic, general, > > workhorse function for frames. It lets you set any number > > of frame parameters in any order. Yes, I would very much > > like it to continue working in the same, straightforward > > manner, including for parameter `font'. > > When setting one frame parameter can implicitly change another one, I > wouldn't consider that as "straightforward". The non-independence of some frame parameters is a general condition - not specific to `modify-frame-parameters' at all. > But since I never tried to customize my emacs in this area > I trust you. Maybe someone who both uses frame parameters > and knows how they should work can eventually fix > the problems in this area then. And I trust you and your knowledge of windows and frames, which is certainly far beyond mine. It's possible for your knowledge and my particular experience to work together. I know that because it has happened before. You have fixed badly broken frame behavior several times now, working with info about my particular experience. I thank you again for all that patient and careful work. One thing that seems unfortunate to me is the coupling of (a) changing a parameter value for a single frame with (b) changing the default value of that parameter for future frames. IIUC, that is what `set-frame-font' does now, and it seems wrong to me. Are there other parameter-setting functions that also act like that?