From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Sat, 20 Apr 2013 22:54:24 +0300 Message-ID: <838v4dyo3z.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1366487724 10568 80.91.229.3 (20 Apr 2013 19:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 19:55:24 +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 Sat Apr 20 21:55:27 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 1UTdsd-0006FF-FF for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 21:55:27 +0200 Original-Received: from localhost ([::1]:52983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdsc-0006m0-VC for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 15:55:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdsY-0006lf-TV for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:55:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTdsX-0002DL-Nh for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:55:22 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTdsX-0002DA-Kc for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 15:55:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTdx4-0006Nw-0z for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 16:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2013 20:00: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.136648796324456 (code B ref 14233); Sat, 20 Apr 2013 20:00:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 19:59:23 +0000 Original-Received: from localhost ([127.0.0.1]:33955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTdwQ-0006MO-Fl for submit@debbugs.gnu.org; Sat, 20 Apr 2013 15:59:22 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:55321) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTdwO-0006MF-9U for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 15:59:21 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MLK00300KLJ8W00@a-mtaout20.012.net.il> for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 22:54:37 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLK0020WKMYMTE0@a-mtaout20.012.net.il>; Sat, 20 Apr 2013 22:54:34 +0300 (IDT) In-reply-to: <5172EBEF.7030301@swipnet.se> X-012-Sender: halo1@inter.net.il 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:73531 Archived-At: > Date: Sat, 20 Apr 2013 21:26:39 +0200 > From: Jan Dj=E4rv > CC: rudalics@gmx.at, esabof@gmail.com, 14233@debbugs.gnu.org >=20 > WM hints tell the window manager the width increment and height inc= rement that=20 > the Emacs frame wants to be resized in. This means when a user res= izes by=20 > dragging the window border, the window manager only allows resize i= ncrements=20 > by the specified width/height increments. So there is no half char= acters=20 > showing. In addition, when resize occurs some, not all, window man= agers shows=20 > the size while resizing. When width/height increments have been se= t, the WM=20 > shows the size in these units, which for Emacs translates to rows a= nd columns. >=20 > 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 also=20 > specify a base width/height in pixels. That base width/height is t= he non-text=20 > portions width/height. Thanks. However, does it really make sense to resize in increments of canonical character size? The user could have changed the face to be something else, and even with the default font the "canonical character"s size is different from many characters of the same font. So we get partial characters even with character-size increments. Hmm... I guess character-size increments of the frame might still make sense at least in some use cases, because from the user POV, not every size change is meaningful. E.g., a user could want to have N extra lines or columns. But OTOH, these goals are perfectly achievable with pixel-unit resizes. So it's not clear to me what would be the benefit of keeping character-size increments. > >> But I'd prefer if the text part is resizable only in terms of li= nes/columns. > > > > Why? Is there any other reason beyond WM hints? >=20 > Usability. For example, all terminal emulators does this. Terminal emulators generally use a single typeface, so this makes mor= e sense there. Also, a terminal emulator must have integer values of LINES and COLUMNS, as text-mode programs expect that. Emacs doesn't have these limitations. > We only need to make Emacs windows be resizable in pixels, not the = frame as I=20 > tried to explain above. That's possible. Martin, do we have any important use cases beyond fullscreen where pixel-unit resize of frames is really necessary?