From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Sat, 20 Apr 2013 19:25:57 +0300 Message-ID: <83mwstyxre.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1366475188 24996 80.91.229.3 (20 Apr 2013 16:26:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 16:26:28 +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 Sat Apr 20 18:26:31 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 1UTacN-0005kH-Bt for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 18:26:27 +0200 Original-Received: from localhost ([::1]:50727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTacM-0003Ul-Tc for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 12:26:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTacJ-0003UU-D1 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:26:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTacI-0006BW-BD for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:26:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTacI-0006Al-7V for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:26:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTagn-0004Xu-RN for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2013 16:31: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.136647545417456 (code B ref 14233); Sat, 20 Apr 2013 16:31:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 16:30:54 +0000 Original-Received: from localhost ([127.0.0.1]:33711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTagf-0004XR-De for submit@debbugs.gnu.org; Sat, 20 Apr 2013 12:30:53 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:35945) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTagb-0004XF-SR for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 12:30:51 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MLK00300AUPYO00@a-mtaout21.012.net.il> for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 19:26:07 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLK003W2AZJY920@a-mtaout21.012.net.il>; Sat, 20 Apr 2013 19:26:07 +0300 (IDT) In-reply-to: <51729A6A.7090404@gmx.at> X-012-Sender: halo1@inter.net.il 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:73522 Archived-At: > Date: Sat, 20 Apr 2013 15:38:50 +0200 > From: martin rudalics > CC: rgm@gnu.org, esabof@gmail.com, 14233@debbugs.gnu.org > > >> 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. Yes, I think that's a better solution for that. > >> 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. Windows in Emacs can display images as well, and that's exactly what the tool bar window does, see redisplay_tool_bar. It displays text with display properties that specify images. > Also the frame's internal border is drawn in between toolbar and the > frame's root window At least on MS-Windows, I see no border. Or perhaps I don't know what to look for. > > As for display margins, they do display text, don't they? > > IIUC they could display anything fringes can display No. Fringes can only display bitmaps. The cannot display text or images that we support in the text area or on margins. > > 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. I'm trying to think why the fringes were included. It is possible that the reasons were practical rather then anything else. Like the desire to have the text area contiguous. > All this "a frame's width is the width of its text area" stuff is > only a hindrance in this regard. I was not arguing in favor of it. If you want to change that, I'm not going to object. > 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." What's wrong with those?