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 13:01:52 +0200 Message-ID: <517275A0.1040702@gmx.at> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org> <517257A0.4080607@gmx.at> <8338ul1rmb.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 1366455749 14108 80.91.229.3 (20 Apr 2013 11:02:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 11:02:29 +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 13:02:33 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 1UTVYq-0006yP-JR for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 13:02:28 +0200 Original-Received: from localhost ([::1]:44834 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTVYq-0000To-8t for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 07:02:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTVYl-0000Th-VB for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 07:02:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTVYk-0006fa-Um for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 07:02:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTVYk-0006fW-RF for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 07:02:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTVdF-0002H4-PP for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 07:07:01 -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 11:07: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.13664560018706 (code B ref 14233); Sat, 20 Apr 2013 11:07:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 11:06:41 +0000 Original-Received: from localhost ([127.0.0.1]:33158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTVcv-0002GN-1C for submit@debbugs.gnu.org; Sat, 20 Apr 2013 07:06:41 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:49889) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTVcs-0002GF-Il for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 07:06:39 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lnmkr-1V1SKf1qed-00hz3t for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 13:01:58 +0200 Original-Received: (qmail invoked by alias); 20 Apr 2013 11:01:58 -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 (mp019) with SMTP; 20 Apr 2013 13:01:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19lgYYfPT5lvQgb9JUpDdyFRKormL2/MSK7Mt9GpE DgmXtPltHo3fKI In-Reply-To: <8338ul1rmb.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:73513 Archived-At: > 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. 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'. So I have to give one of these windows 12 lines and the other 13 lines although their pixel heights are exactly the same. > 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. 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? > Display margins are very rarely used. I don't recommend enhancing > them without an explicit request and a use case that really requires > that. OK >> - 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. OK >> - 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. I had in mind the case where toolbar elements and borders asked for some arbitrary pixel height. IIUC we currently do some rounding there to fit them into screen line multiples. Such rounding would not be needed any more. It goes without saying that clipping the toolbar doesn't make sense. Note in this context that on Windows the toolbar is allowed to occupy the entire frame, obscuring everything else, something we are usually trying to avoid like the plague. > 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. Hopefully. There are some wrinkles with display areas not getting cleared appropriately but these existed already with non-pixelwise resizing. martin