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: Sat, 20 Apr 2013 15:38:50 +0200 Message-ID: <51729A6A.7090404@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366465608 1889 80.91.229.3 (20 Apr 2013 13:46:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 13:46:48 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 20 15:46:52 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 1UTY7v-0003IZ-Uu for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 15:46:52 +0200 Original-Received: from localhost ([::1]:43962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTY7v-0003BW-KO for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 09:46:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTY7r-0003BE-IK for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 09:46:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTY7q-00025b-HG for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 09:46:47 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTY0g-0007sw-TG for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 09:39:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTY5C-0003AI-5N for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 09:44: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: Sat, 20 Apr 2013 13:44: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.136646542512091 (code B ref 14233); Sat, 20 Apr 2013 13:44:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 13:43:45 +0000 Original-Received: from localhost ([127.0.0.1]:33331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTY4t-00038p-AD for submit@debbugs.gnu.org; Sat, 20 Apr 2013 09:43:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:52067) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTY4m-00038S-NG for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 09:43:38 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MeNF3-1UAcTY3N0R-00QG3l for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 15:38:55 +0200 Original-Received: (qmail invoked by alias); 20 Apr 2013 13:38:55 -0000 Original-Received: from 62-47-49-41.adsl.highway.telekom.at (EHLO [62.47.49.41]) [62.47.49.41] by mail.gmx.net (mp027) with SMTP; 20 Apr 2013 15:38:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+nCjQbWtynTo/BTHqPg+LuCWmAT1gyTGLCi1jQDP CqsTLb4+uOx9jN In-Reply-To: <83wqrxzbc7.fsf@gnu.org> 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:73518 Archived-At: >> There are some subtle issues. Suppose I now have two adjacent windows >> each 200 pixels high. I have to give these windows suitable line >> heights. Giving them both either 12 lines or 13 lines will break >> calculations based on the return values of `window-edges'. > > What will break? It will break tests for adjacency of windows based on checking whether the bottom/right edge of a window equals the top/left edge of another window. > Is it possible to avoid the breakage without > imposing arbitrary restrictions on pixel dimensions of windows? One can check whether pixel-edges are equal. In any case, if we want pixelwise resizing, there can't be any restrictions on window sizes. >> But on Windows the toolbar is included in the frame's text height and >> sometimes even the menubar is. And the display margins, whether outside >> or inside the fringes, are part of the text width. Aren't these mental >> dissonances as well? > > No, because a tool bar is just another window (albeit a special one). Which usually doesn't display text. Also the frame's internal border is drawn in between toolbar and the frame's root window, so the frame's text area is not necessarily contiguous vertically. Dissonant IMHO. > As for display margins, they do display text, don't they? IIUC they could display anything fringes can display - I don't see the basic difference. And, as you say below, they are drawn by default outside the fringes (probably because otherwise continuation glyphs would be too far away) so the frame's text area is not necessarily horizontally contiguous either. Very dissonant IMHO. > It could be that the fringes are included because of the display > margins outside the fringes configuration (which is the default). I'm missing you here. The default is to draw, in this order, a scrollbar which is not part of the text area, a margin which is part of the text area, a fringe which is not, the window proper which is, ... > If > that is the case, then perhaps we should leave this alone, although it > feels wrong. I'd tend to say that we could make life easier for those who want to position two Emacs frames on screen in some accordance (look at the tribulations of `dframe-reposition-frame-emacs', for example). All this "a frame's width is the width of its text area" stuff is only a hindrance in this regard. BTW, I've never been able to understand the manuals and doc-strings in this regard. Consider the doc-string of `set-frame-width': "Specify that the frame FRAME has COLS columns." Or its manual entry: "This function sets the width of FRAME, measured in characters." martin