Syntax Highlighting Patterns

From Niki

Jump to: navigation, search

NEdit provides sophisticated regex-based highlighting. You can install extra highlighting modes for your favourite language, or you can write your own. Creating a simple highlighting mode might be easier than you think.

For finished patterns sets to download, see the FTP site: ftp://ftp.nedit.org/pub/NEdit/contrib/highlighting/ and the PatternSets Niki page.

This page is a quick-start quide to creating highlighting patterns. It is not a replacement for reading the NEdit help though; there you will find all the details of what the different settings do.

Contents

Getting started

There are two main ways to create a new pattern:

Create a pattern from scratch

If you are starting a pattern set from scratch you can do everything from the NEdit GUI. Go to the "Language Modes" dialog under Preferences->Default Settings.

"New" will already be selected in the language list. Fill in the name field to fit your language and press "Apply". Your new language mode now exists, although it doesn't do anything sensible.

You will see many other fields on the Language mode dialog. You don't have to modify any of them, but you will probably want to. See the NEdit help for dtails.

If you want these settings to be mostly the same as those in an existing language mode, you could create the pattern by selecting the original pattern in the list, pressing "copy" and then renaming the new entry, rather than renaming the "New" entry. However, this will not copy the actual highligting rules. To do that see the next section:

Copy a pattern set

The easiest way to start probably is to take an existing language mode that is similar to your mode. The problem is that a copy of a language mode in the Language Modes dialog doesn't copy the patterns. So, you have to take the patterns file for this mode (you can find it at nedit.org, for the time being only via FTP: ftp://ftp.nedit.org/pub/NEdit/contrib/highlighting/), rename it, and then edit only the language name that appears after nedit.highlightPatterns: and after nedit.languageModes:. Then save the file. Then make a backup copy of your nedit configuration. After this, you can use the -import switch to import your new pattern set.

After this, you should have a new language mode, which you can edit through Preferences->Default Settings. Select 'Language Modes' to alter the general settings of the language mode, and use 'Syntax Highlighting->Recognition Patterns' to modify the patterns themselves.

Editing patterns

Highlighting patterns should be edited using the NEdit GUI, not by manipulating pattern files directly. Use the "Syntax Highlighting Patterns" dialog, which is located under Preferences->Default Settings->Syntax Highlighting->Recognition patterns.

Here you can specify rules for assigning named rendering styles to text. The actual look of these named styles can be modified in the "Text Drawing Styles" dialog, available via the "Add/Modify Style" button or the Preferences menu.

Design strategies

There are a couple of main ways of identifying a particular piece of text to highlight.

Explicit matching

The first and simplest method is to match the text itself either literally (for example keywords), or using a combination of literal markers and wildcards (for example comments). Most pattern sets employ only this technique, and it is enough for many tasks. Some people also object to more complex schemes.

Implicit matching

The other is to use the context a piece of text appears in to identify its role. This is how for example the default Java pattern can separate a class name from a variable name, even if the actual string is one you have just conceived yourself and the pattern cannot possibly know about.

The advantages are:

  • You can highlight large classes of elements that are too big or unpredictable to match using a predefined list.
  • You can (sometimes) use this to match all legal syntax, and thus use a failure to match for detecting and flagging many syntax errors.

Disadvantages are:

  • Difficult to get right. Not recommended before you have both some experience with nedit highligthing and a very good overview of all the syntax in the subject language.
  • Cannot separate e.g. a predefined function from a legally named one that doesn't exist (unless you use both strategies of course)
  • The rules can interfere with each other in very complex ways
  • You can get very inefficient patterns if you don't know how to optimise them well. The NEdit help contains some tips, but I guess we should add ShOptimisingTips as well.
  • The actual syntax of the language may limit how far you can go in this respect. For example the general consensus now is that with the current highlighting engine, it would not be practical to do the same level of implicit matching for C as the Java and Perl patterns do, among other things due to the dual use of the '*' sign in C. That's not to say we can't be proven wrong by some bright hacker one day...

Performance

Sluggish highlighting is annoying, and often unnecessary. Several things affect the speed; here are some tips:

  • Defer as much as possible to pass2. These patterns are only applied to the visible text in the window.
  • Avoid increasing the context distance if possible
  • When making start/end patterns, exploiting the error pattern feature can help by making sure dead ends are terminated early.

Pitfalls

  • Make sure your patterns can't match beyond your context distance. A classic error is to allow any number of newlines; this is always a mistake.
Personal tools