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: Mon, 29 Apr 2013 18:48:34 +0200 Message-ID: <517EA462.50000@gmx.at> 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> 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 1367254530 23564 80.91.229.3 (29 Apr 2013 16:55:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 16:55:30 +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 Mon Apr 29 18:55:27 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 1UWrMH-0006gi-Rl for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 18:55:22 +0200 Original-Received: from localhost ([::1]:46166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWrMH-0005HZ-Hp for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2013 12:55:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWrM1-0004u6-P7 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 12:55:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWrLz-0002Bd-MT for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 12:55:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWrGp-0000Q2-Uo for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 12:49:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UWrH8-0002fP-0v for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2013 12:50: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: Mon, 29 Apr 2013 16:50: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.136725414810007 (code B ref 14233); Mon, 29 Apr 2013 16:50:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 29 Apr 2013 16:49:08 +0000 Original-Received: from localhost ([127.0.0.1]:50610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWrGF-0002bG-NJ for submit@debbugs.gnu.org; Mon, 29 Apr 2013 12:49:08 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:64329) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UWrGB-0002av-RF for 14233@debbugs.gnu.org; Mon, 29 Apr 2013 12:49:06 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MHdb8-1UTYvv1WZQ-003JqX for <14233@debbugs.gnu.org>; Mon, 29 Apr 2013 18:48:43 +0200 Original-Received: (qmail invoked by alias); 29 Apr 2013 16:48:43 -0000 Original-Received: from 62-47-63-143.adsl.highway.telekom.at (EHLO [62.47.63.143]) [62.47.63.143] by mail.gmx.net (mp019) with SMTP; 29 Apr 2013 18:48:43 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+LrmVshvuLDspAPe9iL4GRAmXABVSBSqLPXNoj8D gzBxVhTVV5KBqU In-Reply-To: <281755A4CB9C4DF9A5D2700E4FF26900@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:73828 Archived-At: > You would have the same surprise with separate calls to parameter-setting > functions: the order matters. Only if I do not redraw the frame in between. > 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. That someone might be a person who wants to do two things at the same time in her Emacs: Use a specific font size and a specific frame size. > 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. I'm afraid that nobody will do that. Some of these dependencies are platform specific, other are encrusted since the early days of Emacs. Moreover alist elements get reversed, processed out of order, ... >> 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. "They" are those who programmed it that way. IIUC `set-frame-font' was called `set-default-font' before and maybe didn't even pay attention to frames at that time. > 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? >> 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. I understand that meanwhile. > 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. >> 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. > 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? > 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. > The non-independence of some frame parameters is a general condition - not > specific to `modify-frame-parameters' at all. Yes. But I would remove such interdependence wherever possible. > And I trust you and your knowledge of windows and frames, ... my knowledge of frames is slightly above zero .... > 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? I have no idea. And I never managed to understand the interactions of initial, default, and actual parameters of frames. martin