From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Own programming language mode - syntax highlighting Date: Wed, 15 Sep 2010 08:19:32 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87y6b4ufwr.fsf@puma.rapttech.com.au> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291869348 9795 80.91.229.12 (9 Dec 2010 04:35:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 04:35:48 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 09 05:35:42 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQYEI-0005BF-09 for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 05:35:42 +0100 Original-Received: from localhost ([127.0.0.1]:46488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQYEH-000612-7r for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 23:35:41 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.astraweb.com!border2.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:XzzA02uSbXT2GqEUZP2p1aolGCA= Original-Lines: 61 Original-NNTP-Posting-Host: 6a81ad9d.news.astraweb.com Original-X-Trace: DXC=B_VNkFnQfa1YUQJRTa54B1L?0kYOcDh@:i=VFiPm?<[57MW>UB@=5>>5a>Ad6NId31C6PADl\g^26 Original-Xref: usenet.stanford.edu gnu.emacs.help:181313 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:76656 Archived-At: Gary writes: > Following Xah Lee's excellent tutorial, I have been able to get the > basics done - syntax highlighting, indentation, and so on. What I am > missing is a small part of the syntax highlighting related to variables. > > Declarations work fine - for example > int x = 0 > is correctly highlighted. What I can't work out how to do is to > highlight declared variables in the rest of the code, for example when I > later use x such as > x = x+1 > > Does anyone have any ideas? Ideally I'd like to only highlight those > variables I have really declared, not something that just looks like it > *might* be a variable, so I can see immediately if I've made a mistake > in my coding or typing. A lot depends on the language, but in general, you cannot do this reliably unless you have some sort of parsing support. Some have tried doing this with regexp, but unless the language is /very/ simple, the regexp will become too complex. To do it correctly, Emacs needs to understand the code (i.e. parse it) to determine what class a token represents. This means you need a mechanism to specify the grammar and an engine to apply that grammar to the code to parse it. Consider something like the following to see why only basic regexp will not work int a; int b; a = b; b = foo( a + 1 ); c = bar() + b; For emacs to recognise that a, b and c are all variables, it needs to know how they would be parsed. Worse still, to know that c has not been declared as a variable, it needs to know/remember the variables that have been declared and recognise that c has not (or maybe it was in an earlier context i.e. like a global). It is farily evident that regexp are insufficient in this respect. Things become further complicated when your editing code because the buffer is often in a state where it cannot be parsed because statements are incomplete/incorrect. At that point, you then need to make a decision about what to do with the font-locking of the code - leave it incorrectly font-locked, remove existing font-locking or something in-between. To complicate matters further, you also need to consider performance. Depending on the size of the files being edited, continuously parsing the buffer is likely to degrade performance and slow down editing. The CEDET tools and semantic can be used to implement simple parsing of code, but it is fairly complex and you still have the issue of handling incomplete code and deciding what to do with it etc. In general, while it is theoretically possible to do what you want, the amount of work required is often too high to be worth the effort. Tim -- tcross (at) rapttech dot com dot au