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: "Font-lock is limited to text matching" is a myth Date: Mon, 10 Aug 2009 23:33:33 -0400 Message-ID: References: <7b501d5c0908091634ndfba631vd9db6502db301097@mail.gmail.com> <200908101335.24002.danc@merrillprint.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249961640 865 80.91.229.12 (11 Aug 2009 03:34:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 03:34:00 +0000 (UTC) Cc: Daniel Colascione , Daniel Colascione , Deniz Dogan , emacs-devel@gnu.org, Leo , Miles Bader To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 05:33:52 2009 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 1Mai7T-0004yK-5G for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 05:33:51 +0200 Original-Received: from localhost ([127.0.0.1]:34139 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mai7R-0007Wt-Cv for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2009 23:33:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mai7K-0007Wo-UJ for emacs-devel@gnu.org; Mon, 10 Aug 2009 23:33:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mai7G-0007Uq-AM for emacs-devel@gnu.org; Mon, 10 Aug 2009 23:33:42 -0400 Original-Received: from [199.232.76.173] (port=52774 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mai7G-0007Uh-29 for emacs-devel@gnu.org; Mon, 10 Aug 2009 23:33:38 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:3431 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mai7D-0006KQ-K7; Mon, 10 Aug 2009 23:33:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAMODgEpMCoTf/2dsb2JhbACBUs8bgjiBYQWHOA X-IronPort-AV: E=Sophos;i="4.43,357,1246852800"; d="scan'208";a="43275678" Original-Received: from 76-10-132-223.dsl.teksavvy.com (HELO pastel.home) ([76.10.132.223]) by ironport2-out.teksavvy.com with ESMTP; 10 Aug 2009 23:33:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1A8938370; Mon, 10 Aug 2009 23:33:33 -0400 (EDT) In-Reply-To: (Lennart Borgman's message of "Mon, 10 Aug 2009 20:55:28 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:114021 Archived-At: > I think Daniel suggested that it is a frame-work that can be used for > book-keeping of how far parsing has gone (the state must be kept > elsewhere) and parsing while Emacs is idle. Don't you think it can be > used for that? As it stands, it's not really adapted to it. I mean, it's OK and there's worse, but it's not great. It's designed mostly to keep track of what has been highlighted (without paying too much attention to potential dependencies between chunks), and it is designed to rehighlight the parts that change and that are displayed. For parsing, we generally assume sequential dependencies (e.g. can't parse the end of the buffer before parsing the beginning), so font-lock's tracking is not very well adapted. And parsing may need to be applied to chunks of text that has not yet and will never be displayed. Basically font-lock-syntactic-keywords is the part of font-lock that was "designed" to handle the parsing side (together with syntax-table), but it deserves to be improved significantly and it should be moved out of font-lock since it provides services that are useful/needed by many other packages, and in buffers where font-lock might not even be desired. Stefan