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#7065: 24.0.50; fringe values broken, doc incorrect Date: Sat, 18 Sep 2010 07:50:27 -0700 Message-ID: <5F83D5F69FD64DD8AE91395EAFCAD613@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284822670 16188 80.91.229.12 (18 Sep 2010 15:11:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2010 15:11:10 +0000 (UTC) To: 7065@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 18 17:11:01 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Owz43-0002Zk-Up for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Sep 2010 17:10:56 +0200 Original-Received: from localhost ([127.0.0.1]:59647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Owz43-0003qw-0D for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Sep 2010 11:10:55 -0400 Original-Received: from [140.186.70.92] (port=34349 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Owz3v-0003q8-BG for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 11:10:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Owz3s-0002cU-Va for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 11:10:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49075) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Owz3s-0002cO-Sv for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 11:10:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Owyhu-0000wK-6o; Sat, 18 Sep 2010 10:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Sep 2010 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 7065 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: Original-Received: via spool by submit@debbugs.gnu.org id=B.12848212573603 (code B ref -1); Sat, 18 Sep 2010 14:48:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 18 Sep 2010 14:47:37 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwyhV-0000w4-GN for submit@debbugs.gnu.org; Sat, 18 Sep 2010 10:47:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwyhU-0000vz-2g for submit@debbugs.gnu.org; Sat, 18 Sep 2010 10:47:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Owyjn-0007Wr-VZ for submit@debbugs.gnu.org; Sat, 18 Sep 2010 10:50:01 -0400 Original-Received: from lists.gnu.org ([199.232.76.165]:39380) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Owyjn-0007Wn-Sg for submit@debbugs.gnu.org; Sat, 18 Sep 2010 10:49:59 -0400 Original-Received: from [140.186.70.92] (port=60475 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Owyjm-00056E-Bd for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 10:49:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Owyjl-0007WN-7C for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 10:49:58 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:25347) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Owyjl-0007WB-2A for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 10:49:57 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8IEns7X000490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 18 Sep 2010 14:49:56 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8IBdK77009274 for ; Sat, 18 Sep 2010 14:49:54 GMT Original-Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 609755611284821379; Sat, 18 Sep 2010 07:49:39 -0700 Original-Received: from dradamslap1 (/10.159.218.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Sep 2010 07:49:39 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActXQNTj/1ZWrzOqRi278EAAqQItug== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 18 Sep 2010 10:48:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:40290 Archived-At: In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-09-06 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' >From bug #6933: > > Can we settle this? > > Feel free to submit a separate bug report. I'm not going to do > anything about this at this time, for the reasons stated above. So here's the new bug report. See #6933 for more context and history. > > What about the confusing name `default' and the doc? > > The original bug report was only about the effect of `half'. > Documentation is an unrelated issue. See my second mail for bug #6933, which clarifies things. I specifically mention problems with the doc and with `default'. > I don't see a good reason for renaming the symbolic values. They don't do what they say. `half' is not necessarily half of `default', even when one disregards rounding. `default' itself is a misleading name. The ELisp manual calls it "standard", but even that is not great. Apparently it is the full width needed to display all fringe bitmaps. If we kept a symbolic value for this it should be something like `full'. > Doing so will surely cause back-compatibility issues, It is used only in interactive interfaces. > so IMO we need a really good reason for such a change. > > > "standard fringe width, which is the width needed to > > display the fringe bitmaps" > > > > That suggests that it is a function of the fringe bitmaps, > > not a constant width. > > They are constant for the time being, but may change in the future, > e.g. if we lift the current restriction of the display engine that > limits window width to an integral multiple of the canonical character > size. We don't name things based on such maybe-one-day-everything-will-be-different imaginings. These names have long (years) been giving the wrong impression. > > But as I say, if `default' and `half' are, in their effect, > > just hard-coded numeric widths, then let's get rid of those > > value-menu and `interactive' spec choices. There is no need for a > > value of nil unless it actually does let the > > fringe be different in different contexts (e.g. bitmap size). > > I don't think it's right to fix the choices on specific numbers. > Symbolic values allow us to change the underlying implementation in > the future without hurting compatibility. See above. The choices that users have should reflect the actual behavior, not some imagined future behavior. The only real behaviors possible today and forever into the past are fixed numeric values for left, right, or both. The UI should reflect that faithfully. It should not be a UI for some imagined alternative or future world. > The fact that some of the documentation describes the current > implementation is not necessarily a good reason to remove future > extensibility. The doc and UI should reflect the product's behavior, not some alternative behavior some developer might be dreaming of. That's a no-brainer.