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: compilation-forget-errors still used by tex-mode.el Date: 02 Apr 2004 21:28:08 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040331135707.514e5cbe.occitan@esperanto.org> <877jwzwu6t.fsf-monnier+emacs@iro.umontreal.ca> <20040401203403.3042d9d8.occitan@esperanto.org> , Markus Rost , emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 02 20:35:28 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B9TVo-0002sb-00 for ; Fri, 02 Apr 2004 20:35:28 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B9TVn-0002Ag-00 for ; Fri, 02 Apr 2004 20:35:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B9TUS-0005st-Jr for emacs-devel@quimby.gnus.org; Fri, 02 Apr 2004 13:34:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B9TQM-00035f-Tj for emacs-devel@gnu.org; Fri, 02 Apr 2004 13:29:50 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B9TPQ-0001ej-GY for emacs-devel@gnu.org; Fri, 02 Apr 2004 13:29:24 -0500 Original-Received: from [195.41.46.236] (helo=pfepb.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B9TPH-0001QY-LL; Fri, 02 Apr 2004 13:28:43 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepb.post.tele.dk (Postfix) with SMTP id 14CBB5EE06A; Fri, 2 Apr 2004 20:28:29 +0200 (CEST) Original-To: Stefan Monnier In-Reply-To: Original-Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21205 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21205 Stefan Monnier writes: > > The overlay-arrow variables are global (although some modes use them > > as buffer-local, but redisplay isn't really prepared for that). > > If the redisplay only ever supports one arrow per buffer, then it would > make more sense to use a single hard-coded variable and make sure that > buffer-local values are handled correctly. But for some uses (like gdb), the overlay arrow isn't tied to a single buffer. Making it buffer local would mean we would have to keep track of where we put that arrow by other means, so we can remove it when moving to a different buffer. Supporting buffer local overlay arrows works for the most part, but the handling of overlay arrows used to rely on global state variables; with my latest changes, those global state variables are now implemented as properties on each overlay arrow variable, so you can safely have more than one arrow. IIRC, the limitation of one overlay arrow in each buffer could easily be lifted... Well, I can look into that. > > It seems that the current interface is overly general w.r.t > the implementation. Can something be too general -- if it is also simple... -- Kim F. Storm http://www.cua.dk