From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Sat, 20 Apr 2013 09:22:05 -0700 Message-ID: <15A11044A1774F1DB7F4D5E0FA8DC143@us.oracle.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366475007 23340 80.91.229.3 (20 Apr 2013 16:23:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 16:23:27 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: "'Jan =?UTF-8?Q?Dj=C3=A4rv'?=" , "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 20 18:23: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 1UTaZT-0003r7-4G for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 18:23:27 +0200 Original-Received: from localhost ([::1]:50486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTaZS-0002oj-O9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2013 12:23:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTaZO-0002lW-UG for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:23:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTaZN-00052b-Sn for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:23:22 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTaZN-00052O-Q7 for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:23:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UTadt-0004Q3-Hz for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2013 12:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2013 16:28: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.136647522716858 (code B ref 14233); Sat, 20 Apr 2013 16:28:01 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 20 Apr 2013 16:27:07 +0000 Original-Received: from localhost ([127.0.0.1]:33704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTad0-0004Nm-7s for submit@debbugs.gnu.org; Sat, 20 Apr 2013 12:27:06 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51082) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UTacx-0004Nc-G4 for 14233@debbugs.gnu.org; Sat, 20 Apr 2013 12:27:04 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r3KGMKjU028484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Apr 2013 16:22:21 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3KGMF6v019768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Apr 2013 16:22:17 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r3KGMEk6016946; Sat, 20 Apr 2013 16:22:14 GMT Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Apr 2013 09:22:14 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5172908F.7090206@swipnet.se> Thread-Index: Ac49xp+NAADazw+STUig041Kt7q1QgAGPXEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:73521 Archived-At: > I'd rather see that text is text. Fringe and scrollbars > should not be included, nor should margins or borders. > Non-text portions should be able to have any width/height > in pixels. This includes the native toolbar. > > But I'd prefer if the text part is resizable only in terms of > lines/columns. An exception to this is tiling window managers > and fullscreen behaviour. There are other exceptions too, besides tiling WMs and fullscreen. The "text" area can include images, boxed text (which can increase the apparent char height/width), fonts of different sizes in the same line, and various other display artifacts/properties. IOW, "Text" and the text area are not just about lines and columns anymore, at least when it comes to resizing a window or frame to fit it. Users should be able to calculate the needed "text" area to display a given buffer portion well (i.e. to fit it). It is good to keep each area of a frame and window separate in terms of its treatment (toolbar, menu-bar, fringe, text area, etc.). Users (and higher-level predefined functions) can then combine them as needed when calculating the desired size etc. IOW, let programmers deal with each such area individually when they need to. If possible, do not give them just an overall knob to turn and force them to rely upon Emacs to juggle all of the parts well and make a good compromise automatically under the covers. For a given application it _could_ make sense to privilege the display of the first or last text line's height fully and sacrifice a couple pixels from the full height of a toolbar or a fringe or whatever. Emacs can provide good overall compromises, but it is still good to give users control over the combining for the cases where they need it. Perhaps (dunno) even give users functions/parameters to let them explicitly pad chosen display areas with "extra" pixels and trim pixels from other display areas. IOW, the kinds of thing that you might be doing automatically to make things work right. That would not be the first thing they would do, but it might still be useful to be able to do. Dunno. ---- FWIW, I have not followed this thread well, but I will probably be interested in the outcome. Another meta-comment would be that this project is bound to be difficult, perhaps long, and involve some compromises. Let's try to attack it progressively, in stages. A goal should remain that we not break what works now (the line/column sizing etc.) as we advance. (Preaching to the choir, no doubt.) Thanks for working on this.