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 12:25:00 +0300 Message-ID: <8338ul1rmb.fsf@gnu.org> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org> <517257A0.4080607@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1366449928 30142 80.91.229.3 (20 Apr 2013 09:25:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 09:25: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 11:25:32 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 1UTU30-0004Rh-EQ for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 11:25:30 +0200 Original-Received: from localhost ([::1]:57089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTU2z-0002pu-Ue for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 05:25:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTU2w-0002pp-6a for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:25:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTU2v-0000Nh-0q for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:25:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTU2u-0000Nd-Tx for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:25:24 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTU7O-0006oG-PD for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:30:03 -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 09:30: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.136645019626120 (code B ref 14233); Sat, 20 Apr 2013 09:30:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 09:29:56 +0000 Original-Received: from localhost ([127.0.0.1]:33074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTU7H-0006nE-Ky for submit@debbugs.gnu.org; Sat, 20 Apr 2013 05:29:56 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34848) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTU7D-0006my-Uu for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 05:29:53 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MLJ00200RFX5200@a-mtaout21.012.net.il> for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 12:25:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLJ002NSRHY1550@a-mtaout21.012.net.il>; Sat, 20 Apr 2013 12:25:11 +0300 (IDT) In-reply-to: <517257A0.4080607@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:73511 Archived-At: > Date: Sat, 20 Apr 2013 10:53:52 +0200 > From: martin rudalics > CC: Glenn Morris , esabof@gmail.com, 14233@debbugs.gnu.org > > >> ** Remove the limitation that window and frame widths and heights can > >> be only full columns/lines. > > > > Right. And I don't think the wording of the problem in both cases is > > accurate enough. There is no such limitation, except in functions > > that actually resize the frame/window. The display engine doesn't > > require integral number of character cells. > > > > So, if someone wants to bite the bullet, the way to go is: > > > > . introduce interfaces to specify frame/window size in pixels > > I'm mostly done with the low-level parts of the implementation. Thanks. > - An option `frame-resize-pixelwise' which, when non-nil, passes resize > requests from the window manager pixelwise to the frame and window > resizing routines. > > - An option `window-resize-pixelwise' which, when non-nil, makes some > window resize functions (like `adjust-window-trailing-edge' or > `fit-window-to-buffer') operate pixelwise. > > - Functions like `window-resize', `split-window' or `set-frame-size' > take an optional argument PIXELWISE which means to interpret their > size/delta/width/height argument pixelwise. Sounds reasonable to me. It might be a good idea to release this as-is, and wait for comments and complaints by those who will use them. > - The window resize routines work pixelwise although when resizing I > still try to preserve full lines/columns first and give the remainder > to one window only. That is, if I have three windows and 90 pixels > height to distribute, by default I assign 32, 32 and 26 pixels instead > of 30 pixels to each. If you prefer a different solution tell me - I > have no strong opinion here. I think what's important is to have a way of resizing a specific window to a specific pixel-size. What happens to other windows as result is less important. > - We currently include a frame's fringe widths and scroll bar widths in > the frame's pixel width but not in the frame's text width. This is > very inconvenient on graphic systems and leads to all sorts of subtle > bugs like bug#14222. Do we really care about this distinction or > could we simply say that specifying a frame's width specifies also the > width of that frame's root window (minus the internal border width)? The fact that the fringes and the scroll bar are excluded from the dimensions of the text area sounds correct to me. Otherwise, it would be confusing to have non-text portions included in the text area dimensions, and could lead to subtle bugs due to this mental dissonance. What is the relation of these frame dimensions to the frame's root window, though? Can we handle the problem on that level, i.e. when computing window dimensions from frame dimensions? > - IIUC we currently do not allow to specify the sizes of display margins > pixelwise. Are we interested in lifting this restriction? We would > have to invent suitable terms for these. Display margins are very rarely used. I don't recommend enhancing them without an explicit request and a use case that really requires that. > - We currently round fringe widths (in compute_fringe_widths) and scroll > bar widths (in x_set_scroll_bar_width) to columns. Is this still > desirable or shall this be lifted too? Should probably be lifted, but it doesn't have to be part of the initial change that gets committed. > - The heights of the tool and menubar are specified in lines. Do we > intend to change that to pixels? I don't think so: clipping the displayed stuff in these "windows" doesn't make sense, IMO. IOW, a tool bar whose icons are only partially visible is ugly, and I'm not aware of a single application that does that. Likewise with the menu bar (only applicable to a non-toolkit X build, btw). > > . in the implementation of those interfaces, round up the sizes in > > column and line units to the integral numbers, so that the glyph > > matrices are large enough > > I tried to do that. Usually, the display routines are so robust that > hardly anything could ever break them. You should only need to do that where we allocate glyph matrices.