From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: fringe buffer-boundary bitmaps Date: Tue, 21 Feb 2006 13:12:10 +0200 Message-ID: <20060221111210.GA73942@flame.pc> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1140558097 8376 80.91.229.2 (21 Feb 2006 21:41:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2006 21:41:37 +0000 (UTC) Cc: miles@gnu.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 21 22:41:34 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FBfG7-0005Ve-DW for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2006 22:41:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FBfFm-0008Og-CC for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2006 16:41:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FBVfs-00009X-Nh for emacs-devel@gnu.org; Tue, 21 Feb 2006 06:27:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FBVSI-0007YA-BJ for emacs-devel@gnu.org; Tue, 21 Feb 2006 06:13:22 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FBVSA-0007Xe-MP for emacs-devel@gnu.org; Tue, 21 Feb 2006 06:13:12 -0500 Original-Received: from [62.1.205.36] (helo=igloo.linux.gr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FBVYI-0002CK-Mb; Tue, 21 Feb 2006 06:19:31 -0500 Original-Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.5/8.13.5/Debian-3) with ESMTP id k1LBCXq2019293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Feb 2006 13:12:37 +0200 Original-Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id k1LBCCeI079671; Tue, 21 Feb 2006 13:12:12 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id k1LBCAMW079670; Tue, 21 Feb 2006 13:12:10 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-To: "Kim F. Storm" Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.364, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.83, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50862 Archived-At: On 2006-02-20 23:38, "Kim F. Storm" wrote: >"Richard M. Stallman" writes: >> I understand that, but I don't see why we need two different ways to >> modify them -- you can redefine the standard bitmap directly, so I >> don't see why do we need an extra level of indirection here (which has >> to be done at the C level to an already quite complex piece of code). >> >> Currently, what we have are standard bitmaps for "bob-left", >> "bob-right", "eob-left", "eob-right" etc... >> >> But, rather than following the existing pattern of naming them after >> their purpose (like "continuation-line", "left-truncation" etc), I >> have named them after their visual appearence, e.g. "top-left-angle", >> "top-right-angle", "bottom-left-angle", etc... >> >> That is a bug IMO, so I agree with Miles that those names should be >> changed to match their purpose rather their appearence. >> >> I would not say we "need" the extra level--that word is too >> strong--but I think it would be cleaner. >> >> It would be cleaner to name each bitmap after what it looks like, such >> as top-left-angle, then specify by name one of these bitmaps to use >> for a given purpose, such as beginning-of-buffer. >> >> It's like defining a function with your own choice of name and then >> putting that name in a hook or variable with a standard fixed name, >> instead of redefining a function with a fixed name. > > I have finally found some time to work on this item in FOR-RELEASE. > > I have installed some changes to implement it, along with changes to > the lispref and NEWS. New buffer-local variables are > fringe-indicator-alist and fringe-cursor-alist. > > Note that fringe.el is now pre-loaded, so I might have broken > something related to the way fringe-mode is handled, or the > involved code can be simplified. Revision 1.26 of fringe.el in CVS doesn't complete a bootstrap here: Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./rfn-eshadow.el Wrote /home/keramida/svn/emacs/trunk/emacs/lisp/rfn-eshadow.elc Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./rot13.el Wrote /home/keramida/svn/emacs/trunk/emacs/lisp/rot13.elc Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./ruler-mode.el In toplevel form: ruler-mode.el:115:1:Error: Symbol's value as variable is void: fringe-bitmaps *** Error code 1 Stop in /home/keramida/svn/emacs/trunk/emacs/lisp. *** Error code 1 Stop in /home/keramida/svn/emacs/trunk/emacs. *** Error code 1 Stop in /home/keramida/svn/emacs/trunk/emacs. It looks like ruler-mode.el needs to change a bit after fringe.el,1.26