AucTeX extension for TikZ

Question

Is there an AucTeX extension which supports the TikZ syntax and that one of the tkz-collection as well?

In particular I want thinks like:

• syntax highlighting
• proper indentation
• that TeX-insert-macro knows the TikZ (tkz)-commands and options (perhaps it would be better to have a new emacs macro like tikz-insert-macro, since TikZ commands don't have a leading backslash)

Answer 1

UPDATE, 11/10/11: I've posted the code at https://github.com/blerner/auc-tikz -- the most recent version is auc-tikz-struct.el (the other files are older experimental versions). I haven't had time to update the code in a while, so if people want to tinker with the code, have at it! It's still rough, but it should sorta work if you'd like to try it out.

Original answer

Per @egreg's request, a comment-turned-answer, and some elaboration on what's tricky about this prospect: I tried writing an AUCTeX TikZ highlighting plugin to address the first bullet point in your question, though I haven't had much time since my comment to work on it. The challenge in writing a syntax-highlighting mode (aka "font-lock" mode or "fontifying") for any part of emacs is that emacs uses regular expressions to match text. TikZ's grammar ... is not regular. In particular, the key=value portions are recursive, since you might have key={key=value,key=value}, as in

\tikzset{foo/.style={draw,circle,etc...},
         bar/.style={blue,etc...}}

While elisp's regular expressions do let you have backreferences (and therefore aren't true regular expressions), font-lock doesn't let you refer to the recursively matched subgroups, so you can't get the font-lock behavior you need. I've tried several possible approaches:

• So I started (ab)using a more powerful approach, with Toby Cubitt's auto-overlays package (also the author of the cleveref package). An overlay, in the parlance of this package, is similar to marking up a stretch of text with <span> in HTML, so you can hook styles onto it. I don't fully understand how auto-overlays does its magic, but it allows you to dynamically create overlays based on matcher functions, and it will take care of deleting them when the text no longer matches. At least in theory it would, if I were using it properly :) After emailing the author, he recommended that I avoid this approach because emacs' performance suffers with too many overlays.

• There is a very contorted way to trigger an arbitrary function during font-locking, which can then be used to manually assign the 'font properties to stretches of text. The trick is to use what's called an "anchored match", which lets you define some functions that get called in lieu of the default font-highlighting. But this leads to infinite loops for me, because font-lock is very brittle with multi-line matches.

• The approach that seems to be working is to hijack AUCTeX's hijacking of the font-lock mechanism, and after AUCTeX finishes, double-back and check whether there's a tikzpicture environment and if so, manually assign font-lock highlighting to it. There's still a subtle bug in that emacs re-highlights only chunks of the buffer at a time, so my code can correctly highlight the TikZ code but the colors won't be shown until the page is fully refreshed.

The upshot is I have a new package in the works, called auc-tikz.el, that builds some highlighting functions that properly match the grammar of the key=value part of TikZ, including the recursive parts, and a hard-coded recognition of the \tikzset command as a trigger to create an auto-overlay. It looks like this, in my current color scheme:

/Key/paths are recognized separately from the final /.command (as in iface/.style), so that you can see which settings are simple names (draw,fill=blue!20) and which are somewhat meta (iface/.style). Braces are purple when they delimit a TikZ option group (iface/.style={...}), but are light blue when they're part of a value (mark=at position...{...}). Comments are mostly supported, though they may still have some unintuitive behavior. Unknown commands are red, from the first parsing error up through the next uncommented semicolon.

The \node, \path and \draw (and any other) commands are not parsed properly, particularly not all the locations [options] can be interspersed in such commands. All the various coordinate forms are not parsed properly; I currently have (coord), ++(coord) and (coord)+(coord) support. Other forms, like ($(coord)!calc!(coord)$), are not yet supported. (They kinda sorta work, because the parser just looks for a balanced paren group; if you left out a closing $, it would mistakenly highlight as correct...)

"All" that remains to do is recognize the generic TikZ \macro ... ; syntax, and get the highlighting to refresh properly. And support nested environments, like pgfonlayer and scope and such. And speed the code up considerably; it's slow to parse even a smallish tikzpicture.