From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Sat, 20 Apr 2013 11:11:37 +0200 Message-ID: <071A708E-3A98-4D11-A15F-7AB92D5200DD@swipnet.se> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org> <517257A0.4080607@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366449150 23350 80.91.229.3 (20 Apr 2013 09:12:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 09:12:30 +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:12:34 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 1UTTqS-0006GM-HU for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 11:12:32 +0200 Original-Received: from localhost ([::1]:56756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTqS-0001lp-3V for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 05:12:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTqN-0001lg-5k for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:12:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTTqJ-0004bl-TH for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:12:27 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTqJ-0004bh-QT for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:12:23 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTTuo-00069z-91 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 05:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2013 09:17: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.136644938123622 (code B ref 14233); Sat, 20 Apr 2013 09:17:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 09:16:21 +0000 Original-Received: from localhost ([127.0.0.1]:33060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTTu9-00068x-6L for submit@debbugs.gnu.org; Sat, 20 Apr 2013 05:16:21 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:54624) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTTu5-00068m-Bj for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 05:16:19 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 7B961C4C5 for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 11:11:35 +0200 (CEST) Original-Received: (qmail 25955 invoked by uid 89); 20 Apr 2013 09:10:45 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 20 Apr 2013 09:10:45 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id C7FD57FA058; Sat, 20 Apr 2013 11:11:34 +0200 (CEST) In-Reply-To: <517257A0.4080607@gmx.at> X-Mailer: Apple Mail (2.1503) 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:73510 Archived-At: Hello. 20 apr 2013 kl. 10:53 skrev martin rudalics : > >> ** 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 >=20 > I'm mostly done with the low-level parts of the implementation. What > might be lacking is a better interface specification. So far I have: >=20 > - An option `frame-resize-pixelwise' which, when non-nil, passes = resize > requests from the window manager pixelwise to the frame and window > resizing routines. >=20 > - 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. >=20 > - 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. >=20 How does these interact with WM size hints? Are you turning them off = when resizing pixelwise? > Some issues still deserve discussion: >=20 > - 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. >=20 > - 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)? Are you proposing that the width of the scroll bar and the fringe be = included in the text width? You need to explain this better. >=20 > - 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. >=20 > - 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? >=20 > - The heights of the tool and menubar are specified in lines. Do we > intend to change that to pixels? This is dependent on the port. For the Gtk+ port, toolbar and menubar = height has no restriction to be in lines. A value > 0 means "on". The = actual height is not the height of a line, but whatever height the = toolkit chooses. Jan D. >=20 > > . 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 >=20 > I tried to do that. Usually, the display routines are so robust that > hardly anything could ever break them. >=20 > martin >=20 >=20