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#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account Date: Mon, 22 Sep 2014 13:24:53 -0700 (PDT) Message-ID: <2b22f309-880c-44e3-a37a-a334b2f18c27@default> References: <541F129D.3000402@gmx.at> <541FE5A4.8030900@gmx.at> <867a1372-84f3-4c30-89df-49cc2cbd06dc@default> <54205FA1.7020106@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411417599 20000 80.91.229.3 (22 Sep 2014 20:26:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2014 20:26:39 +0000 (UTC) Cc: 7822@debbugs.gnu.org, 7822-done@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 22 22:26:31 2014 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 1XWABp-00042G-O2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Sep 2014 22:26:29 +0200 Original-Received: from localhost ([::1]:49034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWABp-0008Mr-3V for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Sep 2014 16:26:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWABc-0008Ku-U6 for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 16:26:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWABT-0005e9-RS for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 16:26:16 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWABT-0005dm-NC for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 16:26:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XWABN-0002ZZ-Nq for bug-gnu-emacs@gnu.org; Mon, 22 Sep 2014 16:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Sep 2014 20:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7822 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7822-submit@debbugs.gnu.org id=B7822.14114175039806 (code B ref 7822); Mon, 22 Sep 2014 20:26:01 +0000 Original-Received: (at 7822) by debbugs.gnu.org; 22 Sep 2014 20:25:03 +0000 Original-Received: from localhost ([127.0.0.1]:49216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWAAP-0002Xj-Ev for submit@debbugs.gnu.org; Mon, 22 Sep 2014 16:25:02 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39448) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XWAAN-0002XW-5L; Mon, 22 Sep 2014 16:24:59 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8MKOvsZ025480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Sep 2014 20:24:58 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8MKOtiT018477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Sep 2014 20:24:55 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MKOsKO018073; Mon, 22 Sep 2014 20:24:54 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:93647 Archived-At: > > The ER is for that and more. It asks that a user be able to > > control "how much" it "takes display artefacts into account". > > But just being able to tell it not to take any into account > > would probably be acceptable. >=20 > Could we have at least some kind of motivating example for why one > might want that kind of control? 1. He who can do more can do less. 2. That is what the function did before the ER. Some users might prefer that longstanding behavior generally. 3. Code might want to handle things differently than the current automatic handling. In particular, it might want to not take into account some display artefacts, or to deal with them differently. It is likely to be harder for code to compensate for automatic, fancy fitting than it would be to add custom fitting behavior to rudimentary-fit behavior. Best would be as the ER suggested: be able to choose just which display artefacts are to be taken into account. 4. Providing also a simple, no-bells-and-whistles behavior lets users roll their own fitting behavior (#3). Providing only a one-size-fits-all-do-everything behavior does not. Keep our options open. 5. What extra cost is there, to provide this flexibility? (See #1.) 6. Finally, that is what the ER explicitly requested (!). It did not ask for only do-it-all behavior. It asked to allow users to be able to obtain that behavior and to do without it - au choix. The request stands, unless it has been realized. Has it? I might have had additional things explicitly in mind when I filed the ER almost 4 years ago, but at least these simple motivations come to mind immediately now. I haven't seen where the code for this is (where is it?). If this was "fixed" in Lisp code then presumably it will be possible for users to tease apart the various parts, in order to, in the end, put together whatever behavior they need. But if this was "fixed" in C code then there is all the more need for explicit provision for users to turn parts of it off.