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: Tue, 30 Apr 2013 08:47:18 -0700 Message-ID: <2FCB61519F9546A3BD7C1D9A35B93241@us.oracle.com> References: <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> <022239E9EC0E41E8A1AF6F4C14FF5A39@us.oracle.com> <517F7420.7080204! @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 1367336872 18299 80.91.229.3 (30 Apr 2013 15:47:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 15:47:52 +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 Tue Apr 30 17:47: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 1UXCmS-0002Fa-H2 for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 17:47:48 +0200 Original-Received: from localhost ([::1]:48133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXCmS-0007ZD-5a for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 11:47:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXCmN-0007Yt-3q for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 11:47:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXCmJ-0003MN-IG for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 11:47:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXCmJ-0003M4-FB for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 11:47:39 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UXCmg-0004mY-8S for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 11:48: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: Tue, 30 Apr 2013 15:48: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.136733688118375 (code B ref 14233); Tue, 30 Apr 2013 15:48:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 30 Apr 2013 15:48:01 +0000 Original-Received: from localhost ([127.0.0.1]:52453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXCme-0004mH-6h for submit@debbugs.gnu.org; Tue, 30 Apr 2013 11:48:01 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51178) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXCma-0004m8-HK for 14233@debbugs.gnu.org; Tue, 30 Apr 2013 11:47:58 -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 r3UFlTYe002142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Apr 2013 15:47:30 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 r3UFlSUW017969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2013 15:47:29 GMT Original-Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3UFlSh5017946; Tue, 30 Apr 2013 15:47:28 GMT Original-Received: from dradamslap1 (/10.159.236.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Apr 2013 08:47:27 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac5FdT0qbs8r47XcR/q1qO+ohGkViwAOaCCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <517F7420.7080204@gmx.at> 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:73847 Archived-At: > > Emacs 24.1 added this, AFAICT. It added optional 3rd arg > > FRAMES for `set-frame-font'. > > I see. It's probably for the sake of `menu-set-font' which calls it > with t as third argument. And `set-frame-font' has > (frame-list (cond ((null frames) > (list this-frame)) > ((eq frames t) > (frame-list)) > (t frames))) > so any non-t value will not affect other existing frames. But any > non-nil FRAMES value will "alter the user's Custom setting of the > `default' face, but only for font-related attributes" whatever that > means. Maybe it should do that iff FRAMES equals t. Maybe. Or maybe KEEP-SIZE is not really needed? (Dunno.) > > 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? > > If you gave me a recipe for what to try. I did, starting from emacs -Q. Please see my msg of 2013-04-28: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14233#272. Let me know if something in that recipe is not clear. > Do you see a changed default face at least when you call that function? Please see what I wrote. I detailed what Emacs tells me about face `default', which seems to depend on the current frame and something else. AFAICT, it does not work as advertised, at least on MS Windows. > I can only repeat that I won't change the behavior of > `modify-frame-parameters' wrt the font parameter if you don't want it. Thank you. > But this means that the interaction of `modify-frame-parameters' with > window managers will remain as it is now. I won't change its behavior > wrt fringes or scrollbars only. I can't speak to that. I'm not sure what changes wrt fringe/scrollbars you had in mind. > > 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. > > Here on MS Windows the Emacs 24.3 fringe zooms along with the text. Really? Here it does not, and never has, ever since fringe has existed (Emacs 21). I change only the `font' parameter, substituting a different number for the height/size in the font string. The fringe remains the same width. I can shrink or enlarge the font (and hence the frame) more and more, but the fringe width stays the same. > The scrollbar currently doesn't - but it has larger increments IIRC. I believe I was told that this is a toolkit thing (or something like that). The scrollbar changed size when you changed the font size prior to Emacs 21. Since 21 it has not changed size along with the font. I just now retested all of this (scroll bars, fringe), from emacs -Q, in Emacs 20, 21, and 24. Changing only frame parameter `font', and only wrt the height/size, has the effect I just described, in MS Windows XP (SP3). > > 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. > > Do I understand correctly that `modify-frame-parameters' never affects > future frames? I believe that is correct. It affects only its targeted frame. > >> 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. > > Why do you say such a thing? Apart from the current buffer I wouldn't > even know what is inherited. I guess I misunderstood your proposal, sorry. > > 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. > > If "the proposal" stands for my earlier suggestion to use > `set-frame-font' instead of `modify-frame-parameters', then I > obviously withdraw that suggestion provided we cannot turn off > the impact on future frames. Great. Let's not argue about what might have been proposed or misunderstood as having been proposed. What is important is what the behavior is and will/should be. My concerns, which I'm sure you understand, are these: a. `modify-frame-parameters' should not be changed so that it affects future behavior. b. Changing the `font' parameter of a frame should also shrink/enlarge the frame, as it does today. That is, shrink/enlarge in terms of screen size (pixels), but not in terms of number of lines/cols. IOW, the frame size should keep the same number of lines/cols. Wrt (b): 1. Keeping the same number of lines/cols when the `font' size changes does not mean that the frame must be an integral number of lines/cols, AFAIK. I too want frames to be sizable in terms of pixels. All I am saying for (b) is that the lines/cols should remain the same when changing the `font' size, as is the case now. Numbers of additional pixels can be different. 2. If someone needs/wants to be able to change the `font' parameter without changing the frame size, I am not against providing such an option somehow. That was apparently what was done for `set-frame-font' by adding the new optional parameter KEEP-SIZE. So presumably this want/need has already been satisfied. > > 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. > > This would mean we have two bugs already. > > > My concern is to keep `modify-frame-parameters' doing the > > right thing wrt parameter `font'. > > And my concern was to change the conception on what the right > thing wrt parameter `font' is. My impression is that perhaps in the desire to allow better sizing of frames pixelwise you would abandon the fact that resizing the `font' resizes the frame accordingly so that the number of displayed lines/cols remains the same. I don't think that should be necessary. I understand that pixels not directly related to text display might need to be different for different `font' (hence frame) sizes. But I think we should be able to keep the same lines/cols displayed. Now, when embedded images are involved, for example, since they are not related to the `font' size, they will not shrink/enlarge along with the `font' and frame. So in that case the lines/cols would not be the same. Likewise for tool bars etc., as is already the case today. Changing the frame `font' size zooms only the text. Other forms of zooming would need to be combined with that to also shrink/enlarge non-text things. But wrt text display it is important (to me anyway) that the frame try to show the same text display, regardless of its size: same lines/cols, which means also same overall text appearance. If someone wants to zoom the text of a buffer without also shrinking the frame, s?he can use `text-scale-adjust'. > > 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. > > That "odd behavior" is the standard here with applications > like Firefox, Thunderbird, ... The fact that Emacs is special > doesn't give me a valid reason to call the rest of the world odd. OK, yes, let me say that both behaviors should be possible. Some people, sometimes, will want the frame to stay the same size when they shrink/enlarge its text. Other people, other times, will want the frame to shrink/enlarge along with the text. I am generally in the latter camp, because I save screen real estate when I shrink frames (including to thumbnail size). I use many frames, often visible at the same time. Someone who uses frames the way one might use tabs in a web browser, i.e., showing only one frame at a time, will prefer a different behavior, no doubt. We should be able to accommodate both use cases. If you looked at my screen now, you would see several frames at different font sizes and thus different frame sizes. Some are even just thumbnails - almost like icons. I dynamically enlarge particular frames that I want to focus more on, while others are shrunk to different degrees so I can still see their text clearly but they do not take up as much space. I do not claim that my use of Emacs frames is a common one, but I do know that there are some others who use it. BTW, I will note that even when I enlarge text size in a web browser I often also (manually) increase the browser size so that the text lines fit better. Likewise, when I decrease the text size I often narrow the browser window, so the lines are shorter. There is a reason that newspapers (which are wide) divide the text into columns, even when there is only one article on the page: long lines are harder to read. Line length is typically determined by browser width, and for the same reason that newspapers shorten lines by creating columns, it can make sense for a user to resize the browser window when s?he changes the text size. Do many users bother to resize their browser when they resize text? Dunno, probably not. But I do, quite often. (Many readers probably never resize browser text. And many browser pages are in fact divided into columns. And many other browser pages prevent you from resizing the text at all.) The point here is that with a web browser you have to perform two separate operations: resize the text and then resize the window to best fit the new text size. In Emacs, zooming the frame font is the same as zooming the frame: they move together in a coordinated way, so that what you see remains pretty much the same: same lines/cols, same line width (in terms of number of chars). Best will be to let users (a) have this convenient, coordinated behavior or (b) optionally choose, for a *given frame* or *generally*, the typical web-browser behavior of keeping the frame size fixed when zooming. Being able to calculate the pixel size needed to display a given buffer portion, which I hope will also be provided by this bug fix, is something I've been hoping for for a long time. But it is independent, I think, of trying to let a frame keep the same number of displayed lines/cols when shrunk/enlarged. Similarly, not constraining a frame size to char multiples (this bug report's subject) is, I think, pretty much independent of whether a frame tries to keep the same lines/cols displayed when zoomed. Yes, exact fitting of a frame to a particular pixel size will often forego maintaining the same number of displayed lines/cols - of course. That is something different from zooming.