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#6933: 24.0.50; fringe-mode value of `half' is broken Date: Sat, 18 Sep 2010 11:49:04 +0200 Message-ID: <83iq23z8j3.fsf@gnu.org> References: <97A7C2F12C894D59986BE445D664437A@us.oracle.com> <83r5hjktvz.fsf@gnu.org> <87hbi59x2w.fsf@stupidchicken.com> <83vd64ysw3.fsf@gnu.org> <6CD1E6A595C84B3FA8C2AFE4EAC376BE@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1284804658 15862 80.91.229.12 (18 Sep 2010 10:10:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2010 10:10:58 +0000 (UTC) Cc: 6933-done@debbugs.gnu.org, cyd@stupidchicken.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 18 12:10:56 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 1OwuNk-0003PX-85 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Sep 2010 12:10:56 +0200 Original-Received: from localhost ([127.0.0.1]:35359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwuNj-0007VA-Cg for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Sep 2010 06:10:55 -0400 Original-Received: from [140.186.70.92] (port=37848 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwuNZ-0007Uy-K7 for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 06:10:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OwuNY-0006L0-6a for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 06:10:45 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54939) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwuNY-0006Ks-1S for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 06:10:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Owu0c-0006dU-Ap for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2010 05:47:02 -0400 Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Sep 2010 09:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 6933 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 6933@debbugs.gnu.org, eliz@gnu.org Original-Received: via spool by 6933-done@debbugs.gnu.org id=D6933.128480320325500 (code D ref 6933); Sat, 18 Sep 2010 09:47:02 +0000 Original-Received: (at 6933-done) by debbugs.gnu.org; 18 Sep 2010 09:46:43 +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 1Owu0J-0006dF-Dp for submit@debbugs.gnu.org; Sat, 18 Sep 2010 05:46:43 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Owu0I-0006dA-Ap for 6933-done@debbugs.gnu.org; Sat, 18 Sep 2010 05:46:43 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L8X00B00SIB4F00@a-mtaout20.012.net.il> for 6933-done@debbugs.gnu.org; Sat, 18 Sep 2010 11:49:00 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.210.149]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L8X00ARPSLMTO60@a-mtaout20.012.net.il>; Sat, 18 Sep 2010 11:48:59 +0200 (IST) In-reply-to: <6CD1E6A595C84B3FA8C2AFE4EAC376BE@us.oracle.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 18 Sep 2010 05:47: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:40284 Archived-At: > From: "Drew Adams" > Cc: <6933-done@debbugs.gnu.org> > Date: Fri, 17 Sep 2010 15:25:59 -0700 > > > I changed fringe.el to use (4 . 4). So this bug should be fixed now > > (revno 101464). > > 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. > The doc string for the function `fringe-mode' mentions the rounding, but the doc > string for the option (customization) does not mention it. I added to the doc string of the defcustom a note about rounding. > `default' probably should be renamed. It is not just a default: `half' > presumably takes its meaning from the meaning of `default'. I suggested "full", > "whole", or "maximal", but perhaps something even better can be found. The > clearest doc about the fringe is the Elisp manual, and that refers to this as > the "standard" width. That is better than `default'. I don't see a good reason for renaming the symbolic values. Doing so will surely cause back-compatibility issues, 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. > 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. The fact that some of the documentation describes the current implementation is not necessarily a good reason to remove future extensibility. > 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.