Among many other things, this allows lexing of manpage source documents.
The lexer is macro-package agnostic, though. Troff is also used as a typesetting package.

This lexer goes further than most Troff lexers by actually trying to parse its syntax instead of only applying heuristics. Unfortunately, the language is strictly speaking unparseable even with intimate knowledge of the syntax of all of its requests as its parsing behavior often depends on runtime state (and we all know that the halting problem is undecidable). Any Troff lexer is therefore necessarily a compromise.
This implementation tries hard to guarantee at least the following:

• Reliably detect the beginning of requests and commands (macro calls) within known restrictions. This works even after flow control commands.
• Highlight all of the escape sequences supported by Groff. However, currently it is not taken into account, that backslash often has to be escaped (\\) in string assignments and macro definitions. I am not sure if we can reliably predict where to resolve these indirections. (What does the bash lexer do in this case, anyway?)
• Fold macro definitions, ignore blocks and flow control blocks (between \{ and \}).

Currently there are the following restrictions:

• Escapes are not interpreted everywhere e.g. as part of command names.
• For the same reasons, changing control characters via .cc or .c2 will
  not affect lexing - subsequent requests will not be styled correctly.
  Luckily this feature is rarely used.
• Line feeds cannot be escaped everywhere - this would require a state machine for all parsing.
  However, the C lexer apparently has the same restriction.
• It is impossible to predict which macro argument is a numeric expression or where the number is actually treated as text. Currently, they are highlighted in conditional expression (like after .if) and after all presumed macro calls, ie. if the command is not a known request from the keywordlist.
• Also, escapes with levels of indirection (eg. \\$1) cannot currently
  be highlighted, as it is impossible to predict the context in which an
  expansion will be used. Perhaps we should add an exception at least for \\$n as they are practically never used without escaping the backslash?
• Indirect blocks (.ami, .ami1, .dei and .dei1) cannot be folded.
• No effort is done to highlight any of the preprocessors (tbl, pic, grap...). This could theoretically be done, but I have already spent 10 times more time on this lexer than I initially planned.

SciTECO already added support for this lexer..

Here's a proper SciTE properties file for supporting the Lexer.
It was only tested with SciTE 5.13, but I don't think that much has changed in the properties syntax. I can also send it to the Scintilla mailing list once this gets merged, unless @nyamatongwe just takes it from here.