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)
  • 1
    So you want TikZ syntax highlighting? I don't think this exists, though I'm sure it would be possible to create such a thing...
    – Seamus
    Jun 4, 2011 at 10:29
  • 2
    I would like to add the issue of proper indentation of TikZ code when using AUCTeX. Is is also poor at the moment.
    – Dror
    Jun 4, 2011 at 10:30
  • @Dror automatic indentation is hard. It's not such an issue to indent things yourself. Emacs is quite smart about getting things indented correctly (with TAB) once you set the top on right. That is, set the right indentation for line x, TAB on line x+1 and it should tab it to the same level, unless it thinks it should be indented more...
    – Seamus
    Jun 4, 2011 at 11:00
  • @Seamus: You can getting everything badly mixed up in case you try to C-c C-q C-s for example. Then all the TikZ parts are badly indented...
    – Dror
    Jun 4, 2011 at 20:19
  • 4
    @JosephWright, for kicks, I tried writing such an extension the past few days. I'm not an expert elisper, so it's slowish going, but I've managed to write a highlighter for the key=value portions of tikz. It recognizes {}/()/[]-balanced groups, too. Hooking that up to the rest of tikz "just" involves recognizing \<macro> <stuff>; and highlighting all the balanced groups within stuff. Unfortunately, my highlighter is not regexp-based, so it doesn't play nicely with the rest of auctex's use of font-lock. But it's a start...
    – Ben Lerner
    Aug 19, 2011 at 17:00

1 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


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.

  • 6
    Very promising indeed!
    – egreg
    Oct 2, 2011 at 14:56
  • 1
    Thanks! The biggest conceptual hurdle I have, besides properly updating the overlays, is how to recognize parts of TikZ grammar while not getting snarled up by parts I don't parse. E.g., I don't know of a definitive grammar for all the coordinate forms: (coord), (coord)+(offset), (coord)++(offset) and so on -- and if I miss any, my parser gets stuck in an ill-defined state... Do any TikZ gurus/authors know of such a comprehensive TikZ grammar? Or a schema that guides how new syntax is introduced to stay "TikZ-y"?
    – Ben Lerner
    Oct 2, 2011 at 15:15
  • 1
    @BenLerner, are there any updates on the status of auc-tikz.el? I'd love to have access to (even an incomplete version of) the library.
    – Aaron
    Nov 6, 2011 at 22:42
  • 2
    It might make sense to post this on the AUCTeX mailing list.
    – N.N.
    Dec 30, 2011 at 14:02
  • 1
    It would be great to have it! Hope to learn Elisp ASAP
    – Spike
    Mar 3, 2012 at 7:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .