From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Customize fringe Date: 12 May 2002 01:44:41 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xk7qa45cm.fsf@kfs2.cua.dk> References: <5xu1pgsxtc.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1021157110 2322 127.0.0.1 (11 May 2002 22:45:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 11 May 2002 22:45:10 +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 176fby-0000bL-00 for ; Sun, 12 May 2002 00:45:10 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 176flk-0004R7-00 for ; Sun, 12 May 2002 00:55:16 +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 176fc1-00040a-00; Sat, 11 May 2002 18:45:13 -0400 Original-Received: from fepa.post.tele.dk ([195.41.46.143]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 176fan-0003jI-00 for ; Sat, 11 May 2002 18:43:57 -0400 Original-Received: from kfs2.cua.dk.cua.dk ([80.62.38.68]) by fepA.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020511224356.FMRD1178.fepA.post.tele.dk@kfs2.cua.dk.cua.dk> for ; Sun, 12 May 2002 00:43:56 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: Original-Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:3845 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3845 Simon Josefsson writes: > storm@cua.dk (Kim F. Storm) writes: > > > Simon Josefsson writes: > > > >> What do you think of this? > > > > I would like you to wait implementing anything like this. > > It is on my TODO list to make fringe configurable > > per buffer/window rather than per frame. > > > > Something like variables left-margin-width / right-margin-width > > and functions set-window-margin / window-margin. > > > > Once that is in place, various modes may fine-tune their > > use of the fringe (e.g. gdb may explicitly enable the left > > fringe for the arrow, and speedbar may turn off both fringes > > by default). > > Hm. Aren't these separate issues? Fine tuning for each mode would > require per buffer fringes. But the overall customization by the user > to disable fringes works if default-frame-alist and all existing > frames are modified. If the fine tuning exist, it can override the > frame wide decision not to have fringes. Can it? Should it? If you think of this as similar to the menu-bar, I don't think we have any major modes which turns on the menu bar if the user has turned it off (and likewise with the scroll-bar). So will it be acceptable to have a non-standard behaviour for fringes where major (or minor) modes override the user's choice? I would prefer to have per-buffer fringes controlled by a per-mode alist -- then you (as a user) will be able to add e.g. fundamental-mode and text-mode to that alist with option "no fringes". That's less intrusive than simply turning off the fringe for all modes. IMO it is a bad idea to remove the left fringe in e.g. C buffers, as it is used by gdb-mode if you debug that C program/module. However, I don't object to adding "Fringe" to the Show/Hide menu -- as long as it is understood that it only controls the default settings for the fringes. I think the options should be: Both/Left/Right/None. > > My main goal is that it should not be very difficult for the user to > just disable fringes everywhere, much like you can disable the toolbar > and menubar everywhere today. Fine tuning is useful for re-enabling > fringes in those modes where the user wants them, but couldn't that be > added to fringe.el later? > Yes. -- Kim F. Storm http://www.cua.dk