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 21:26:39 +0200 Message-ID: <5172EBEF.7030301@swipnet.se> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366486045 27610 80.91.229.3 (20 Apr 2013 19:27:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 19:27:25 +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 21:27:29 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 1UTdRY-0006J8-Io for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 21:27:28 +0200 Original-Received: from localhost ([::1]:49316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdRX-0002gH-Sw for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 15:27:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdRT-0002g7-LE for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:27:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTdRR-00012Y-Dg for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:27:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdRR-00012S-84 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:27:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTdVx-0005QG-Qn for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:32: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 19:32: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.136648628620786 (code B ref 14233); Sat, 20 Apr 2013 19:32:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 19:31:26 +0000 Original-Received: from localhost ([127.0.0.1]:33926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTdVO-0005PC-37 for submit@debbugs.gnu.org; Sat, 20 Apr 2013 15:31:26 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:36134) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTdVL-0005P3-4B for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 15:31:24 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 5D4679F23 for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 21:26:39 +0200 (CEST) Original-Received: (qmail 13738 invoked by uid 89); 20 Apr 2013 19:25:49 -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 19:25:49 -0000 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id D72B87FA058; Sat, 20 Apr 2013 21:26:38 +0200 (CEST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 In-Reply-To: <83sj2lz6nm.fsf@gnu.org> 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:73529 Archived-At: Hello. 2013-04-20 15:13, Eli Zaretskii skrev: >> Date: Sat, 20 Apr 2013 14:56:47 +0200 >> From: Jan Dj=E4rv >> CC: Eli Zaretskii , esabof@gmail.com, >> 14233@debbugs.gnu.org >> >> I don't understand why we want to resize in pixels instead of >> characters. > > See the beginning of this bug report, and the TODO item. > > In a nutshell, we resize in units of canonical character size that > mean nothing to the windowing system and the rest of the machine. The > downside of that is that some specifications of the dimensions produce > surprising results, and for no good reason. > >> But if you insist on resizing with pixels instead of characters, you h= ave turn >> WM hints off for NS and X. > > Could you describe in short the role of those hints for Emacs display? > I don't believe we have this documented anywhere. WM hints tell the window manager the width increment and height increment= that=20 the Emacs frame wants to be resized in. This means when a user resizes b= y=20 dragging the window border, the window manager only allows resize increme= nts=20 by the specified width/height increments. So there is no half characters= =20 showing. In addition, when resize occurs some, not all, window managers = shows=20 the size while resizing. When width/height increments have been set, the= WM=20 shows the size in these units, which for Emacs translates to rows and col= umns. This does not mean that the toolbar, menubar, scrollbar, fringe etc. has = to be=20 in a multiple of these increments. In addition to the increments, you al= so=20 specify a base width/height in pixels. That base width/height is the non= -text=20 portions width/height. So at any time the WM maintains the invariant: width =3D base width + n x width increment height =3D base height + m x height increment n, m are integers. You can also specify a minimum size, but that is not relevant to this iss= ue. Note that for fullscreen, the WM does not keep this invariant, nor does t= iling=20 window managers. For other types of resize (i.e. interactive with the mo= use)=20 I'd like to keep the WM size hints, because it is more userfriendly. If we want to make windows display partial lines that is OK, and even=20 preferrable for the fullscreen/tiling case, but we should not disregard W= M=20 size hints for the other case. > >> You should thoroughly test this change on X with a couple of >> different window manager before checking it in. Resizing is a bit >> of a mess on X because the intreactions with the window manager, and >> the strange ways Emacs deals with GUI elements. > > Those "strange ways" are partly explained by the restrictions Martin > is trying to lift, AFAIK. Not really, it has more to do with how Emacs adds toolbars and menubars (= after=20 the frame is created). > >> But I'd prefer if the text part is resizable only in terms of lines/co= lumns. > > Why? Is there any other reason beyond WM hints? Usability. For example, all terminal emulators does this. > >> An exception to this is tiling window managers and fullscreen behaviou= r. > > 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=20 tried to explain above. Jan D.