From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Customize fringe Date: 10 May 2002 10:32:08 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <877kmd7bf5.fsf@tc-1-100.kawasaki.gol.ne.jp> <87helh5f96.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020994569 19859 127.0.0.1 (10 May 2002 01:36:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 10 May 2002 01:36:09 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 175zKK-0005A7-00 for ; Fri, 10 May 2002 03:36:08 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 175zTC-0002zE-00 for ; Fri, 10 May 2002 03:45:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 175zKM-0004kW-00; Thu, 09 May 2002 21:36:10 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 175zHl-0004Xb-00; Thu, 09 May 2002 21:33:29 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g4A1XQV03258; Fri, 10 May 2002 10:33:26 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g4A1XPL01434; Fri, 10 May 2002 10:33:25 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g4A1WAu09278; Fri, 10 May 2002 10:32:50 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g4A1W9K19913; Fri, 10 May 2002 10:32:09 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id D0B523722; Fri, 10 May 2002 10:32:08 +0900 (JST) Original-To: emacs-devel@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: Original-Lines: 68 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3795 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3795 Simon Josefsson writes: > > My point was that, unlike menus or toolbars, people will _usually_ want to > > do something besides turning fringes entirely on or off (presuming they > > want to do anything at all), and that as a result, having `fringe-mode' + > > adjustments is the wrong user-interface to this functionality. > > Ok. I based the design from what I wanted out of it. If other people > want to do more fine tuned things, I guess it is easy to add. Let me be more explicit: We _shouldn't_ adopt `fringe-mode' and then `add' to it -- we should just call it something else. The basic name of a feature has a strong influence on how people think of it, even if it's possible to change the details on the side. In this case the name `fringe-mode' suggests (by example, from many other emacs commands) that the `basic functionality' is to have fringes either (1) on or (2) off. If people see this, and are annoyed by the default fringes, they're going to thing `oh, that's how I deal with those !@#$# fringes,' invoke it, and (95% of the time) leave it at that, ending up with no fringes -- and that's undesirable, since other configurations also save space without incurring the rather high penalty in usability that no fringes does. Here's a suggestion for what I think is a better interface: Call it `reduced-fringe-mode', and have it switch between full fringes and, say, right-fringe-only. People who _really_ want to have no fringes at all can customize an associated configuration variable and choose that possiblity as the `reduced' state, and it will still make sense. It could also allow a C-u prefix to select an alternative configuration, or prompt for the configuration, or whatever. > > it's common for people to want to simply turn scrollbars on or off, but > > the scrollbar location is merely a detail. > > I disagree -- I rather disable the scrollbar than to have on the left. > The location is not a detail. That's what I said -- `people to want to simply turn scrollbars on or off.' Here `detail' implies a secondary characteristic, of less importantance that the main `boolean' behavior (and obviously for you, of _zero_ importance). > Compare with scroll-bar-mode and menu-bar-mode, is it really that > different? Yes, because simply eliminating fringes is more harmful than removing the scroll-bar or menu-bar (which have good alternatives), so we want to gently encourage people to do something less drastic -- and I think people would generally be happy with a `reduced' option. I suspect that the main thing that makes people dislike fringes is that a whole column for each side seems like a lot of wasted space, especially for the left side (where it's much more obvious than the right-side because all the text abuts it). > I want on/off, you suggested half/half and left only and right only. > Are there more? I don't think it really matters for this purpose; if any are found, they can easily be added later. I think enhancing the display code so that it tries to use alternative bitmaps for `reduced' fringes would make them much more useful -- e.g. a 4/4 split or 2/6 split might be perfect if they had bitmaps tuned for them. -Miles -- 97% of everything is grunge