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 13:41:31 -0700 Message-ID: <022239E9EC0E41E8A1AF6F4C14FF5A39@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> <281755A4CB9C4DF9A5D2700E4FF26900@us.oracle.com> <517EA462.50000@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 1367268173 19314 80.91.229.3 (29 Apr 2013 20:42:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 20:42:53 +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 22:42:50 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 1UWuuQ-0003LP-6R for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 22:42:50 +0200 Original-Received: from localhost ([::1]:58020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWuuP-0005Ru-Nb for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 16:42:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWuuL-0005Rd-Ke for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 16:42:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWuuJ-0002gX-W3 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 16:42:45 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWuuJ-0002gK-SV for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 16:42:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UWuuc-0005sS-Lh for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 16:43:02 -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 20:43:02 +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.136726812322458 (code B ref 14233); Mon, 29 Apr 2013 20:43:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 29 Apr 2013 20:42:03 +0000 Original-Received: from localhost ([127.0.0.1]:50828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWute-0005q2-Ck for submit@debbugs.gnu.org; Mon, 29 Apr 2013 16:42:03 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:39432) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWuta-0005pg-3h for 14233@debbugs.gnu.org; Mon, 29 Apr 2013 16:41:59 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3TKfYQ9024447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Apr 2013 20:41:35 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3TKfXh8029229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2013 20:41:33 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3TKfWQg029218; Mon, 29 Apr 2013 20:41:32 GMT Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Apr 2013 13:41:32 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <517EA462.50000@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac5E/x6JTeI1WGtuS1+WS1cONNLiRQAFp/Ug X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:73835 Archived-At: > > Maybe the logic behind that coupling could be made more > > explicit in the doc? Or maybe that "enhancement" should > > be reverted? > > Did you find out when that enhancement was made? I think we're talking about this behavior: 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. Emacs 24.1 added this, AFAICT. It added optional 3rd arg FRAMES for `set-frame-font'. But see my earlier msg where I mention that I do not in fact see the future-changing behavior that is advertised for new frames. Do you see it? (Wrt the optional 2nd arg KEEP-SIZE, it was Emacs 22 that added that.) > > Why do you suppose that there is an optional parameter > > KEEP-SIZE for `set-frame-font'? > > ... because on 2003-04-09 Ehud Karni added it ... > > > And why do you suppose it is optional (i.e., the default > > behavior does NOT keep the same size)? > > ... because that's how it behaved on the first day. > > > 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)? > > I did so and still think it's the correct answer in an > environment that has to cater for fullscreen and maximized > frames as well as for tiling window managers. I don't think > that zooming the font size in any of these modes should > change the frame size. Use `set-frame-font' with non-nil KEEP-SIZE if you do not want the frame to zoom along with its text and you want to change how much text is visible in the same frame. That's what KEEP-SIZE is for. > >> 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. > > Not me. When you change the font size these are the things Emacs > changes along with it. The scrollbars and the fringe are not changed when the frame font size is changed. Not on MS Windows, at least. Prior to Emacs 22, the scrollbars (but not fringe) were zoomed along with the text. The big thing that doesn't belong mixed in with the others is changing the appearance of future frames. Changing a frame parameter in one frame should not affect future frames. > > Why should `modify-frame-parameters', applied to a single > > frame, affect future frames at all? > > Maybe because when it creates a new frame Emacs has it inherit > certain things from the selected one? Certain things are inherited from the selected frame. But you want to change which things are inherited. And now you bring in "the selected one". In the proposal, IIUC, ALL future frames would have their font size changed, not just those frames created when the altered frame happens to be selected. > > 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. > > As I said above, that function was probably supposed to set > the default value. In any case, I'm confident/afraid that > people had good reasons for applying such a change. I consider it a mistake. But I'm not trying to fix/change `set-frame-font' here. And as I said, I do NOT even SEE the (misguided) future-changing behavior that its doc claims for it. My concern is to keep `modify-frame-parameters' doing the right thing wrt parameter `font'. If someone wants to get the affect you prefer then s?he can use `set-frame-font' with non-nil KEEP-SIZE (but I think that function might need to be "fixed" so that actually works). There is no good reason to change `modify-frame-parameters' so that such odd behavior (not even the default for `set-frame-font') becomes the new norm. > ... my knowledge of frames is slightly above zero .... I have more experience with my particular use of frames. You are far more knowledgable about the frame-affecting code, I'm sure. > > 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? > > I have no idea. I don't think there are. > And I never managed to understand the interactions of > initial, default, and actual parameters of frames. ;-)