From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "spamfilteraccount@gmail.com" Newsgroups: gmane.emacs.help Subject: Re: State-machine based syntax highlighting Date: 8 Dec 2006 13:14:42 -0800 Organization: http://groups.google.com Message-ID: <1165612482.201274.57760@j44g2000cwa.googlegroups.com> References: <1165472049.496117.320630@79g2000cws.googlegroups.com> <1165488825.132862.189340@79g2000cws.googlegroups.com> <1165492567.864982.59980@79g2000cws.googlegroups.com> <1165495364.560960.271250@f1g2000cwa.googlegroups.com> <1165501630.172348.157180@j72g2000cwa.googlegroups.com> <1165502373.932709.15860@79g2000cws.googlegroups.com> <1165510932.276718.251220@73g2000cwn.googlegroups.com> <1165516558.657188.21610@j44g2000cwa.googlegroups.com> <1165517838.526624.171950@f1g2000cwa.googlegroups.com> <1165563183.140436.326110@16g2000cwy.googlegroups.com> <87psaukdu1.fsf@lion.rapttech.com.au> <1165567010.036350.185800@n67g2000cwd.googlegroups.com> <1165594639.164156.286660@f1g2000cwa.googlegroups.com> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: sea.gmane.org 1165614035 25427 80.91.229.10 (8 Dec 2006 21:40:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Dec 2006 21:40:35 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Dec 08 22:40:34 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GsnSJ-00014U-5E for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Dec 2006 22:40:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GsnSI-00030A-Mv for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Dec 2006 16:40:30 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!j44g2000cwa.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 36 Original-NNTP-Posting-Host: 81.182.18.192 Original-X-Trace: posting.google.com 1165612539 30915 127.0.0.1 (8 Dec 2006 21:15:39 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Fri, 8 Dec 2006 21:15:39 +0000 (UTC) In-Reply-To: <1165594639.164156.286660@f1g2000cwa.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.01 (Windows NT 5.0; U; en),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: j44g2000cwa.googlegroups.com; posting-host=81.182.18.192; posting-account=b98TkQ0AAAD7PsllN8gfWGRoPOPWdnv4 Original-Xref: shelby.stanford.edu gnu.emacs.help:143759 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:39362 Archived-At: Robert Thorpe wrote: > > Doing this with normal parsing technology is difficult. If the editor > just feeds every file into the external parser then back into the > editor then this will be a lot of work. Yes, this is a problematic part. I was thinking about feeding only code snippets to the external parser, but even determining what snippet should be fed from the current source code would need some kind of parsing, so using external parsers might not be feasible after all. > Compiler parsers and font-locking/navigating code have different > intentions. Compiler parsers must be fast when handling a whole file, > and they must generate accurate error messages. Font-locking code must > be fast when starting at any arbitrary part of the code, and it must > tolerate incomplete information and errors. Of course, and I wasn't thinking of using the existing compiler as is, rather utilizing somehow the existing infrastructure in the compiler if it's accessible to implement partial parsing. But given the problems discussed above it may not be the way to go. If parsing needs to be implemented in the editor and every editor must have it's own implementation then at least the concepts could be shared. I mean there should be a wiki or something about discussing issues of partial parsing for a particular language (java, c++, etc.), instead of everyone reinventing the wheel differently. For example, one could check the current implementation in Eclipse of java code completion and parsing, before embarking to implement the same thing again and the same goes for other open source editors supporting other languages.