From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: E Sabof Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Sat, 20 Apr 2013 21:47:30 +0100 Message-ID: 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: multipart/alternative; boundary=047d7bdc15acba5ff704dad0f15c X-Trace: ger.gmane.org 1366490908 6527 80.91.229.3 (20 Apr 2013 20:48:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 20:48:28 +0000 (UTC) Cc: 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 Sat Apr 20 22:48:31 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 1UTehy-0005O9-7h for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 22:48:30 +0200 Original-Received: from localhost ([::1]:60679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTehx-0005xo-UC for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 16:48:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTeht-0005xe-Bb for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 16:48:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTehp-00025b-U3 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 16:48:25 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTehp-00025S-PY for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 16:48:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTemM-0008Eq-HC for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 16:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: E Sabof Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2013 20:53: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.136649113731576 (code B ref 14233); Sat, 20 Apr 2013 20:53:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 20:52:17 +0000 Original-Received: from localhost ([127.0.0.1]:34005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTelc-0008DE-RS for submit@debbugs.gnu.org; Sat, 20 Apr 2013 16:52:17 -0400 Original-Received: from mail-qe0-f51.google.com ([209.85.128.51]:55674) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTelY-0008D5-H4 for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 16:52:13 -0400 Original-Received: by mail-qe0-f51.google.com with SMTP id 1so3407158qec.38 for <14233@debbugs.gnu.org>; Sat, 20 Apr 2013 13:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GLJai8w0+3h/yhtfYRybSHUzj6NKY1MV1CNJCIcTnE8=; b=SeN80hN5YXxgWNMeWsBHvRn+3rKC+rAZ1Asl/YPRQnNp14TqPX4fk7an8nOBI/c1/0 8mMFN5RxoA2RYmkGKUfP7i0Xg8BPza5kDnUGbfiGa0Ii27uNOp+cpaSiSnexxRxcmvYC 6DUYwhPUz0aALjddwIZ4zDSIdMVk36Ojt5mPeeqF+u2eAVMZyDjz/3bK9m769niIP80x clHdEYQutRsxW8gl7OdvxqZ4YRs0+2lzbtdC4gTV/Z1GiL6TVq9kJIFUGs9xY78H5wjv fuAxXKTlg8h3H41dhRT+R61Xkt9Lfes0spHq5bUV8UlXQT9JNGoEVXSJIhzJuHZylXnP iTbQ== X-Received: by 10.49.62.3 with SMTP id u3mr13124409qer.25.1366490850417; Sat, 20 Apr 2013 13:47:30 -0700 (PDT) Original-Received: by 10.49.2.164 with HTTP; Sat, 20 Apr 2013 13:47:30 -0700 (PDT) In-Reply-To: <5172EBEF.7030301@swipnet.se> 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:73532 Archived-At: --047d7bdc15acba5ff704dad0f15c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Apr 20, 2013 at 8:26 PM, Jan Dj=E4rv wrote: > 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 >>> have 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 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. 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. > > 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 i= s > the non-text 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 > issue. > > Note that for fullscreen, the WM does not keep this invariant, nor does > tiling window managers. 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. > > 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 W= M > size hints for the other case. I admit not having partial lines has an appeal, at least to me. At the same time I don't enjoy window hinting. For columns, the remaining bit could be distributed between margins (if present), and the rightmost edges. The remaining vertical space could be added below the echo-area/mini-buffer, and would inherit it's fringes and it's background. The distribution option is not acceptable here, as this would suggest that an empty line follows. This shouldn't make a any difference implementation-time-wise, assuming the maximized window, and tiling cases are taken into account. The downside is that clunky window re-sizing remains. Which I prefer over half-characters, but I suspect some wouldn't. Evgeni --047d7bdc15acba5ff704dad0f15c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Apr 20, 2013 at 8:26 PM, Jan Dj=E4rv <= jan.h.d@swipnet.se<= /a>> wrote:
Hello.

2013-04-20 15:13, Eli Zaretskii skrev:

Date: Sat, 20 Apr 2013 14:56:47 +0200
From: Jan Dj=E4rv <jan.h.d@swipnet.se>
CC: Eli Zaretskii <eli= z@gnu.org>, es= abof@gmail.com,
=A0 14233@debbug= s.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. =A0The 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 have t= urn
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 t= hat the Emacs frame wants to be resized in. =A0This means when a user resiz= es by dragging the window border, the window manager only allows resize inc= rements by the specified width/height increments. =A0So there is no half ch= aracters showing. =A0In addition, when resize occurs some, not all, window = managers shows the size while resizing. =A0When width/height increments hav= e been set, the WM shows the size in these units, which for Emacs translate= s to rows and columns.

This does not mean that the toolbar, menubar, scrollbar, fringe etc. has to= be in a multiple of these increments. =A0In addition to the increments, yo= u also specify a base width/height in pixels. =A0That base width/height is = the non-text portions width/height.

So at any time the WM maintains the invariant:
=A0 =A0width =3D base width + n x width increment
=A0 =A0height =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= .

Note that for fullscreen, the WM does not keep this invariant, nor does til= ing window managers. =A0For other types of resize (i.e. interactive with th= e mouse) I'd like to keep the WM size hints, because it is more userfri= endly.

If we want to make windows display partial lines that is OK, and even prefe= rrable for the fullscreen/tiling case, but we should not disregard WM size = hints for the other case.

I admit not= having partial lines has an appeal, at least to me. At the same time I don= 't enjoy window hinting.=A0

For columns, the remaining bit could be dis= tributed between margins (if present), and the rightmost edges.

The remaining vertical space could be added below= the echo-area/mini-buffer, and would inherit it's fringes and it's= background. The distribution option is not acceptable here, as this would = suggest that an empty line follows.
=A0
This shouldn't make a any difference implement= ation-time-wise, assuming the maximized window, and tiling cases are taken = into account.

The downside is that clu= nky window re-sizing remains. Which I prefer over half-characters, but I su= spect some wouldn't.

Evgeni

--047d7bdc15acba5ff704dad0f15c--