From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Tue, 30 Apr 2013 19:08:00 +0200 Message-ID: <517FFA70.1040107@gmx.at> References: <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> <2FCB61519F9546A3BD7C1D9A35B93241@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367341776 9571 80.91.229.3 (30 Apr 2013 17:09:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 17:09:36 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 30 19:09:35 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 1UXE2v-0004bM-3S for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 19:08:53 +0200 Original-Received: from localhost ([::1]:43092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXE2u-00086T-He for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 13:08:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXE2m-00081U-2p for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 13:08:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXE2g-0006TZ-LE for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 13:08:44 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXE2g-0006TU-G8 for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 13:08:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UXE34-0007ss-Ep for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 13:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Apr 2013 17:09: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.136734172030239 (code B ref 14233); Tue, 30 Apr 2013 17:09:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 30 Apr 2013 17:08:40 +0000 Original-Received: from localhost ([127.0.0.1]:52585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXE2h-0007rf-Ob for submit@debbugs.gnu.org; Tue, 30 Apr 2013 13:08:40 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:55698) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UXE2e-0007rV-Cn for 14233@debbugs.gnu.org; Tue, 30 Apr 2013 13:08:38 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MGUSk-1UJyTi3Wqm-00DFQi for <14233@debbugs.gnu.org>; Tue, 30 Apr 2013 19:08:10 +0200 Original-Received: (qmail invoked by alias); 30 Apr 2013 17:08:10 -0000 Original-Received: from 62-47-42-240.adsl.highway.telekom.at (EHLO [62.47.42.240]) [62.47.42.240] by mail.gmx.net (mp028) with SMTP; 30 Apr 2013 19:08:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18D7LxiIdgDkLm27RECKC+J+VD+gboqnZ3I+3YW/Y UvLkKnrSZvdnBV In-Reply-To: <2FCB61519F9546A3BD7C1D9A35B93241@us.oracle.com> X-Y-GMX-Trusted: 0 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:73852 Archived-At: >> 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.) I don't see what KEEP-SIZE has to do with this. >> > 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. Honestly, I don't understand the customization stuff you mention there. >> Do you see a changed default face at least when you call that function? Yes. That is, when I invoke `menu-set-font' (which calls `set-frame-font') I see that the default face changed. > 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. When I change my font via `menu-set-font' to "-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1" I get as (face-font 'default) that value and when I do C-x 5 2 I get a new frame with precisely that font. >> 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). Using `menu-set-font' I can produce with emacs 24.3 (frame-parameter nil 'font) ; => "-outline-Lucida Console-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1" (window-fringes) ; => (10 10 nil) (frame-parameter nil 'font) ; => "-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1" (window-fringes) ; => (13 13 nil) Whether this actually results in a visible change is a stochastic phenomena whose behavior I can't describe yet. Maybe I never will be able to do so. But eventually the size of at least one fringe changes. > 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. Maybe some rounding effect? Also, as I mentioned, fringe changes get sometimes miraculously delayed. >> 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 wouldn't be that sure. You might have to play around some time with very large sizes. There's all sorts of rounding effects when adjusting these parameters. > 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). I could experiment further but it's too annoying because my frame always gets larger than my screen. > My concerns, which I'm sure you understand, are these: > > a. `modify-frame-parameters' should not be changed so that it affects future > behavior. My concern is that it should be changed. > 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. I'd prefer the frame + external objects to keep the same number of pixels. > 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. OK > 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. But not for `modify-frame-parameters'. And that's the problem. When you change the frame size you have to contact your window manager, wait till it gets back to you, and then you have to fit all your objects into the space alloted by the window manager. Now, obviously you have to do all these things also when you just resize the frame. But in that case you didn't change the font. Or if you did, you did it without intending to change the frame size with it. An action like changing both frame size and font in some coordinated sense is per se complicated and I'd rather do it only when not changing anything else. And that's why I don't want this to be handled by `modify-frame-parameters' where one can change any other parameter as well. There should be one special function to change font and frame size in a coordinated manner and when people call that function, for example, for zooming, they should not set other frame parameters at the same time. And if they do, they might be on their own. > 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. But you probably agree that we should not change the pixel size of a maximized frame. In any case, my concern is to make frame parameter handling via `modify-frame-parameters' predictable, in some sense at least. Currently, I'm completely lost in a jungle of things that get processed in some incomprehensible fashion. > 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. Are you sure? What if toolbars have accompanying text? > Changing the frame `font' size zooms only the text. Not here. > 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'. I don't care about the functions for achieving some specific effect. I care about the basic functionality of `modify-frame-parameters'. > 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. Mostly so, I hope. martin