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 10:53:52 +0200 Message-ID: <517257A0.4080607@gmx.at> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.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 1366448073 14800 80.91.229.3 (20 Apr 2013 08:54:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 08:54:33 +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 10:54:37 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 1UTTYz-0005Ji-Er for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 10:54:29 +0200 Original-Received: from localhost ([::1]:56305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTYz-0000Qg-1g for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 04:54:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTYv-0000Qb-EI for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 04:54:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTTYu-00072l-G9 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 04:54:25 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTTYu-00072h-CV for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 04:54:24 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTTdO-0005R3-AB for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 04:59: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 08:59: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.136644832520870 (code B ref 14233); Sat, 20 Apr 2013 08:59:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 08:58:45 +0000 Original-Received: from localhost ([127.0.0.1]:33049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTTd6-0005QY-HR for submit@debbugs.gnu.org; Sat, 20 Apr 2013 04:58:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:58925) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTTd2-0005QN-Fo for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 04:58:41 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MYIQh-1TytsP2gvB-00VBNs for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 10:54:00 +0200 Original-Received: (qmail invoked by alias); 20 Apr 2013 08:54:00 -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 (mp033) with SMTP; 20 Apr 2013 10:54:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19DNkMFp4FDAiOtMxOeJ52r74vfFf0F8irryG8Id+ T4J2Tzeekc1cqt In-Reply-To: <83bo991z00.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:73509 Archived-At: >> ** 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. What might be lacking is a better interface specification. So far I have: - 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. Some issues still deserve discussion: - 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. - 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)? - 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. - 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? - The heights of the tool and menubar are specified in lines. Do we intend to change that to pixels? > . 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. martin