From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: "Font-lock is limited to text matching" is a myth Date: Tue, 11 Aug 2009 11:06:55 -0400 Message-ID: <31BA527B-46FC-400C-A2B1-8D4A87293C19@merrillpress.com> References: <7b501d5c0908091634ndfba631vd9db6502db301097@mail.gmail.com> <200908101335.24002.danc@merrillprint.com> <87my67s8mr.fsf@randomsample.de> <1249942011.29022.15.camel@projectile.siege-engine.com> <1249955428.29022.186.camel@projectile.siege-engine.com> <9c768dc60908102347v57bdf38ara9fe2179f68c07e4@mail.gmail.com> <42D4C5C5-E702-4E30-AB95-A016280F20C7@merrillpress.com> <87r5vi2ym7.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250003248 22285 80.91.229.12 (11 Aug 2009 15:07:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 15:07:28 +0000 (UTC) Cc: emacs-devel@gnu.org, David Engster , Daniel Colascione , Lennart Borgman , Deniz Dogan , Stefan Monnier , Steve Yegge , Leo , Miles Bader To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 17:07:19 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 1MaswX-00066N-98 for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 17:07:17 +0200 Original-Received: from localhost ([127.0.0.1]:40187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaswV-0008Ff-1r for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 11:07:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaswQ-0008ES-Cw for emacs-devel@gnu.org; Tue, 11 Aug 2009 11:07:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaswL-0008C0-48 for emacs-devel@gnu.org; Tue, 11 Aug 2009 11:07:09 -0400 Original-Received: from [199.232.76.173] (port=44667 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaswL-0008Bv-1s for emacs-devel@gnu.org; Tue, 11 Aug 2009 11:07:05 -0400 Original-Received: from vpn.merrillpress.com ([64.61.107.78]:46353) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MaswI-0002CV-8U; Tue, 11 Aug 2009 11:07:02 -0400 Original-Received: from cpe-67-246-181-235.buffalo.res.rr.com ([67.246.181.235] helo=[192.168.1.103]) by mars.merrillpress.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1MaswD-0003TN-49; Tue, 11 Aug 2009 11:06:57 -0400 In-Reply-To: <87r5vi2ym7.fsf@stupidchicken.com> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:114061 Archived-At: On Aug 11, 2009, at 10:50 AM, Chong Yidong wrote: > Daniel Colascione writes: > >>> There is a relatively simple alternative that might appease Daniel: >>> I could have js2-mode simply not do any highlighting by default, >>> except for errors and warnings. We'd use whatever highlighting is >>> provided by espresso-mode, and users would be able to choose between >>> espresso-highlighting and js2-mode highlighting. With the former, >>> they'd get "instantaneous" font-locking, albeit not as rich as what >>> js2-mode can provide. >> >> That's an interesting idea, but my concerns are not limited to js2- >> mode's highlighting. > > You don't properly elaborate what these additional concerns are. I thought I discussed them well enough in the remainder of the message, but I'll summarize them here: - full parsers belong in the CEDET infrastructure where they can be accessed via a common API - if this API is not rich enough, it ought to be extended - normal major modes shouldn't rely on rigid grammars because that makes them brittle. Anything that needs such a grammar should be an optional and preferably generic minor-mode (I still think it'd be worthwhile to include the JS2 parser in CEDET, which supports parsers not necessarily generated with wisent or bison. It seems robust in its problem domain.) > I don't use either mode, but from reading the discussion it seems to > me > that the optimal solution is to use espresso mode's code for font-lock > and indentation, and js2-mode's code for the commands that need to be > better aware of semantic information (show/hide elements, error > reporting, marking defuns, etc.) That could work, but keep in mind that espresso already has a fairly robust and substantial parsing system that doesn't rely on a full grammar, and that can still reliably mark functions and generate multilevel imenu structures. In terms of featureset, I don't see the differences between (espresso +CEDET+some-sort-of-flymake-lint) and (js2) to be very large, though what differences there are should certainly be dealt with in whatever ends up being the default for Javascript. >> There is *already* a separate and optional full parsing framework >> called CEDET that is powerful, generic, and not tied to a major-mode >> in particular. The right approach is for a given major-mode to >> understand enough of a given language for fontification and >> indentation while leaving more substantial parsing and indexing to >> CEDET (which the user can disable). I recognize that js2's parser may >> work well in its problem domain --- couldn't it just be added to >> CEDET? > > I don't think this is a necessary condition. We can freely move the > code around the Emacs tree once it's already in there; what's more > important is to have something working. We already have not one, but two working solutions. And granted, I'm not a core developer, but from where I'm sitting it seems code is seldom moved around once committed.