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: Sun, 21 Apr 2013 11:26:48 +0200 Message-ID: <5173B0D8.4010408@gmx.at> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org> <517257A0.4080607@gmx.at> <071A708E-3A98-4D11-A15F-7AB92D5200DD@swipnet.se> <51727563.70905@gmx.at> <5172908F.7090206@swipnet.se> <83sj2lz6nm.fsf@gnu.org> <5172EBEF.7030301@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366536446 22293 80.91.229.3 (21 Apr 2013 09:27:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 09:27:26 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 21 11:27:30 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 1UTqYR-0003dT-PO for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Apr 2013 11:27:28 +0200 Original-Received: from localhost ([::1]:33583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTqYR-0000qy-Cm for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Apr 2013 05:27:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTqYL-0000nm-EA for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 05:27:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTqYI-0007Uf-Gw for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 05:27:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTqYI-0007Ub-E8 for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 05:27:18 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTqcs-0008Pw-DH for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 05:32: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: Sun, 21 Apr 2013 09:32: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.136653670332305 (code B ref 14233); Sun, 21 Apr 2013 09:32:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 21 Apr 2013 09:31:43 +0000 Original-Received: from localhost ([127.0.0.1]:34672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTqcZ-0008Oz-2J for submit@debbugs.gnu.org; Sun, 21 Apr 2013 05:31:43 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:63878) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTqcW-0008On-Kv for 14233@debbugs.gnu.org; Sun, 21 Apr 2013 05:31:41 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MckDn-1UC2gA1j2P-00Hv3T for <14233@debbugs.gnu.org>; Sun, 21 Apr 2013 11:26:55 +0200 Original-Received: (qmail invoked by alias); 21 Apr 2013 09:26:55 -0000 Original-Received: from 62-47-58-157.adsl.highway.telekom.at (EHLO [62.47.58.157]) [62.47.58.157] by mail.gmx.net (mp002) with SMTP; 21 Apr 2013 11:26:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+WTA8aivmWEC46a0BDxmx24nCeVu3WVzxi+xDLOu gyS+LZCYciIDLs In-Reply-To: <5172EBEF.7030301@swipnet.se> 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:73546 Archived-At: > WM hints tell the window manager the width increment and height > increment that the Emacs frame wants to be resized in. This means when > a user resizes by dragging the window border, the window manager only > allows resize increments by the specified width/height increments. At least for the window manager of Windos XP this is not true. > So > there is no half characters showing. In addition, when resize occurs > some, not all, window managers shows the size while resizing. When > width/height increments have been set, the WM shows the size in these > units, which for Emacs translates to rows and columns. Again with Windows XP resizing an Emacs frame shows the new sizes pixelwise. Only when releasing the mouse button the frame snaps back to its previous size unless I made it beyond the character size barrier. But in this case it's just Emacs not honoring the WM's request. > This does not mean that the toolbar, menubar, scrollbar, fringe etc. has > to be in a multiple of these increments. In addition to the increments, > you also specify a base width/height in pixels. That base width/height > is the non-text portions width/height. Can you explain what the base width/height is? Something like a minimum size? > So at any time the WM maintains the invariant: > width = base width + n x width increment > height = base height + m x height increment > > n, m are integers. > > You can also specify a minimum size, but that is not relevant to this > issue. A minimum size for what? > Note that for fullscreen, the WM does not keep this invariant, nor does > tiling window managers. What about maximized frames? > For other types of resize (i.e. interactive > with the mouse) I'd like to keep the WM size hints, because it is more > userfriendly. From the Emacs POV this is easy: I could accept `frame-resize-pixelwise' being a list that enumerates all WM operations that should be interpreted pixelwise and have t stand for "all are pixelwise" and nil for "none are". The problem is that IIUC a maximize frame request should be interpreted pixelwise but comes in just as a plain resize request. What are your experiences in this regard? How does ns do that? > If we want to make windows display partial lines that is OK, and even > preferrable for the fullscreen/tiling case, but we should not disregard > WM size hints for the other case. I agree with you. But we should make them customizable. >>> But I'd prefer if the text part is resizable only in terms of >>> lines/columns. >> >> Why? Is there any other reason beyond WM hints? > > Usability. For example, all terminal emulators does this. OK. But this should not impede us from providing an adequate graphical implementation. >>> An exception to this is tiling window managers and fullscreen behaviour. >> >> If we cannot resize in pixels, we cannot make those exceptions, can >> we? > > We only need to make Emacs windows be resizable in pixels, not the frame > as I tried to explain above. Tiling, fullscreen and maximization requests are all incarnations of pixelwise resizing of frames. How else would you call them? martin