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: Sun, 21 Apr 2013 19:21:28 +0200 Message-ID: <9CE9273D-8550-478F-8CB9-0C0D693C0BB8@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> <5172EBEF.7030301@swipnet.se> <5173B0D8.4010408@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366564942 13329 80.91.229.3 (21 Apr 2013 17:22:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2013 17:22:22 +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 Sun Apr 21 19:22:26 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 1UTxy6-0003IR-1u for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Apr 2013 19:22:26 +0200 Original-Received: from localhost ([::1]:38324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxy5-0006ZF-HA for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Apr 2013 13:22:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxy0-0006Xm-Hz for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 13:22:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTxxw-00034L-Gf for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 13:22:20 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTxxw-000342-BQ for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 13:22:16 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTy2X-00067X-W4 for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2013 13:27: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: Sun, 21 Apr 2013 17:27: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.136656518323431 (code B ref 14233); Sun, 21 Apr 2013 17:27:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 21 Apr 2013 17:26:23 +0000 Original-Received: from localhost ([127.0.0.1]:35638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTy1u-00065q-Rz for submit@debbugs.gnu.org; Sun, 21 Apr 2013 13:26:23 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:41445) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTy1p-00065M-8q for 14233@debbugs.gnu.org; Sun, 21 Apr 2013 13:26:21 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 7F4669FD9 for <14233@debbugs.gnu.org>; Sun, 21 Apr 2013 19:21:29 +0200 (CEST) Original-Received: (qmail 7678 invoked by uid 89); 21 Apr 2013 17:20:37 -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; 21 Apr 2013 17:20:37 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id CFE517FA058; Sun, 21 Apr 2013 19:21:28 +0200 (CEST) In-Reply-To: <5173B0D8.4010408@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:73559 Archived-At: Hello. 21 apr 2013 kl. 11:26 skrev martin rudalics : > > 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. >=20 > At least for the window manager of Windos XP this is not true. That is why testing this on anything but X11 gives the wrong impression = on how things work. >=20 > > 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. >=20 > 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. >=20 > > 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. >=20 > Can you explain what the base width/height is? Something like a = minimum > size? Sort of a minimu size if we would have zero columns and lines. >=20 > > 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 > > issue. >=20 > A minimum size for what? A minimum size for the frame. We do say that the minimum frame is one = line and one column, but it could be anthing. We could say that the = minimum size is 5 rows and 14 coulmns, or whatever we choose. The WM = will then not shrink the window below this. >=20 > > Note that for fullscreen, the WM does not keep this invariant, nor = does > > tiling window managers. >=20 > What about maximized frames? Not for that either. >=20 > > 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. >=20 > =46rom 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? >=20 For NS a maximized and fullscreen requests comes in as separate = requests, for X they are normal resize request. The problem is that you think from the W32 point of view where (if I = interepret you correctly), Emacs applies size hints after the resize = request has been delivered. This is not so for NS and X. Any size in a resize request is accepted. = If it follows WM size hints, great, if it don't, who cares?. The frame = size is set to the size in the request anyway. So for NS and X, fullscreen, maximized and such is no problem. A minor = glitch in NS is that we calculate the maximized sizes ourself, and these = are rounded to character sizes. If windows could handle pixel sizes, we = could easily fix this. > > 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. >=20 > I agree with you. But we should make them customizable. >=20 > >>> 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. >=20 > OK. But this should not impede us from providing an adequate = graphical > implementation. >=20 > >>> 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. >=20 > Tiling, fullscreen and maximization requests are all incarnations of > pixelwise resizing of frames. How else would you call them? But there is no restriction on NS and X11 frames to resize by pixel = (i.e. not character multiples). We do that already. The bug reports we = get usually concern when we don't adhere to WM size hints, like = fullscreen. Then there are wasted pixels, becaue windows can't resize = pixelwise. That is where the restriction is. Jan D.