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 09:34:56 +0200 Message-ID: <517F7420.7080204@gmx.at> 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> 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 1367307356 15825 80.91.229.3 (30 Apr 2013 07:35:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 07:35:56 +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 09:35:54 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 1UX56P-0003NM-TU for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 09:35:54 +0200 Original-Received: from localhost ([::1]:43327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX56P-0003nN-8x for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2013 03:35:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX56F-0003mU-5S for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 03:35:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UX56D-00071P-3t for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 03:35:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX56D-00071J-0l for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 03:35:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UX56Y-0006un-CB for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2013 03:36: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 07:36: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.136730733726539 (code B ref 14233); Tue, 30 Apr 2013 07:36:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 30 Apr 2013 07:35:37 +0000 Original-Received: from localhost ([127.0.0.1]:51470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UX566-0006tw-Sw for submit@debbugs.gnu.org; Tue, 30 Apr 2013 03:35:35 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:64285) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UX561-0006tm-Vm for 14233@debbugs.gnu.org; Tue, 30 Apr 2013 03:35:32 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWMYG-1TzQLA0ceo-00XZ18 for <14233@debbugs.gnu.org>; Tue, 30 Apr 2013 09:35:06 +0200 Original-Received: (qmail invoked by alias); 30 Apr 2013 07:35:05 -0000 Original-Received: from 62-47-53-155.adsl.highway.telekom.at (EHLO [62.47.53.155]) [62.47.53.155] by mail.gmx.net (mp002) with SMTP; 30 Apr 2013 09:35:05 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1901/MV3GR0FytsjgFf/xL22prpIRWzIm56j4Yqdl n0PV9TCWagxrpV In-Reply-To: <022239E9EC0E41E8A1AF6F4C14FF5A39@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:73845 Archived-At: > 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'. 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. > 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 haven't touched my font related Emacs settings for ages - the effect was that I usually ended up with a completely messed up frame. Do you see a changed default face at least when you call that function? >> 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. 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. 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. > 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. The scrollbar currently doesn't - but it has larger increments IIRC. > 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? >> 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. > 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. > 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. > 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. martin