From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: something like linum.el ought to be added Date: Fri, 14 Sep 2007 13:20:20 -0400 Message-ID: References: <86hcm4rw70.fsf@macs.hw.ac.uk> <85642imgtp.fsf@lola.goethe.zz> <86k5qtjka0.fsf@macs.hw.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189791183 21671 80.91.229.12 (14 Sep 2007 17:33:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2007 17:33:03 +0000 (UTC) Cc: rms@gnu.org, Markus Triska , emacs-devel@gnu.org To: Joe Wells Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 19:33:00 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IWErN-0004MZ-1J for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2007 19:21:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IWErM-0000le-14 for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2007 13:21:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IWEqA-00007A-E1 for emacs-devel@gnu.org; Fri, 14 Sep 2007 13:20:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IWEq9-00006O-24 for emacs-devel@gnu.org; Fri, 14 Sep 2007 13:20:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IWEq8-00006H-Vg for emacs-devel@gnu.org; Fri, 14 Sep 2007 13:20:25 -0400 Original-Received: from tomts43.bellnexxia.net ([209.226.175.110] helo=tomts43-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IWEq5-0003QU-Fv; Fri, 14 Sep 2007 13:20:21 -0400 Original-Received: from pastel.home ([70.55.141.227]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070914172020.KCVX26794.tomts43-srv.bellnexxia.net@pastel.home>; Fri, 14 Sep 2007 13:20:20 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 34738859D; Fri, 14 Sep 2007 13:20:19 -0400 (EDT) In-Reply-To: <86k5qtjka0.fsf@macs.hw.ac.uk> (Joe Wells's message of "Fri\, 14 Sep 2007 17\:15\:19 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) 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:78900 Archived-At: > Some comments on the idea of relying on fontification-functions: > I think linum.el should work even if the user has font-locking turned > off, so it shouldn't depend on jit-lock.el (unless jit-lock can be > used without turning font-locking on?). Anyway, the whole > font-locking subsystem is also quite hard to understand, so it seems > unwise to me to get linum.el tied up in that complexity. And > font-locking is oriented toward fontifying the entire buffer > eventually while with line numbering you probably only want to keep > active overlays for the displayed region. You may want to take another look at jit-lock-register. Or glasses-mode for that matter (the only other user of jit-lock currently besides font-lock). But yes: jit-lock is oriented towards fontifying the whole buffer, which is not what linum.el wants to do (and actually glasses-mode would probably rather be like linum.el). > And it seems it would be hard for fontification-functions will work > well with linum.el as a separate user from jit-lock.el, because they > would both be competing for control of the same fontified property. > So, for example, if stealth background fontification fontified some > region, it would (I think?) place a non-nil value on the fontified > property of that region, and then when that region was displayed by > scrolling there would be nothing to trigger the line numbering. Yes, that's the problem I hinted at which makes it pretty much impossible to use multiple functions on fontification-functions. So I think it's fine for linum.el to use something else, but I do think it's a good opportunity also to revisit this jit-lock and fontification-functions business to try and come up with a good solution. Maybe a solution is to change jit-lock by having it distinguish between clients that would rather keep everything fontified (full clients) and those that would rather only keep the displayed part fontified (light clients). Then add a jit-lock-clear-unused thingy that would go and flush all the non-displayed data of the light clients and then set fontified to nil (so that jit-lock gets to know when those need to be prepared for display), but also set jit-lock-fontified to t (so that jit-lock knows that this was already fontified w.r.t full clients, so only light clients need to be called). Stefan