Pygments tut sich schwer, Objective-C-Code zu highlighten. Ich hatte irgendwann einmal aufgeschnappt, dass libclang* zum Syntaxhighlighting benutzt werden kann, ja Xcode4 das auch genau so macht. Da mir eine Lösung unter OS/X völlig ausreicht, hatte ich gerade die verrückte Idee, ich könnte das ja mal versuchen. Doch mein Verlangen, das in C zu programmieren, ist eher gering. Daher dachte ich an Python... vielleicht bin ich auch gerade einfach nur frustriert, weil das alles nicht so reibungslos funktioniert, wie ich gehofft hatte.
* die clang** zugrunde liegende Bibliothek für das Parsen und Analysieren von C(++) und Objective-C(++) Code
** der C(++) und Objective-C(++)-Compiler von LLVM***
*** die low level virtual machine
Stefan
PS: Bevor jemand sagt, man könnte ja Pygments verbessern: Das halte ich für ähnlich kompliziert. Einen Fehler hatte ich schon gefunden und fixt. Fehlende Unicode-Escapes und das __block-Schlüsselwort hatte ich auch schon ergänzt. Doch prinzipbedingt kann ein auf regulären Ausdrücken basierender Lexer nicht zählen und wenn man Casts bzw. Typdeklarationen mit Blöcken (z.B. (int (^)(int a)) ) oder einfach nur message sends korrekt parsen will, muss man für jede Klammer Pygments Stacking-Mechanismus nutzen, was den Lexer sehr aufwendig macht -- oder es wie der DelphiLexer macht, komplett "from scratch" machen. Ach, und mir fällt gerade auf, wo ich noch mal auf die regulären Ausdrücke schaue, dass der RE für Character-Konstanten auch nicht korrekt ist und auch ihm das \u fehlt. Den Datentyp unichr kennt Pygments auch noch nicht.
PPS: Ich vermute, github nutzt ebenfalls Pygments. In .h-Dateien. Könnte Pygments nicht mal sagen, dass .h immer für Objective-C steht, damit @interface und usw. nicht immer als Fehler dargestellt werden?
Python-Bindings für libclang?
Ich sehe gerade das Pygments eine Methode `analyse_text` aufruft, um zu entscheiden, welchen Lexer er/sie/es nun anwenden soll. Das könnte man doch nutzen!? Wenn ich in einer *.h-Datei ein `@interface` oder `@protocol` finde, ist es ObjectiveCLexer, ansonsten CLexer, das wäre doch einfach... Schade, dass das Projekt nicht auf github lebt, sonst hätte ich schnell einen fork+pull request gemachtsma hat geschrieben:PPS: Ich vermute, github nutzt ebenfalls Pygments. In .h-Dateien. Könnte Pygments nicht mal sagen, dass .h immer für Objective-C steht, damit @interface und usw. nicht immer als Fehler dargestellt werden?
Stefan
Klingt interessant. Hatte auch schonmal über sowas nachgedacht. Ich habe mir libclang aber noch nicht genauer angeguckt, aber python-Bindings existieren ja dafür (sogar über ctypes).
Die Mac-Anhängigkeit ist imo nicht so schlimm, da man a) einen fallback zum alten Lexer einbauen kann und b) clang sowieso auf andere *NIX portiert wird/wurde.
Woran hapert es denn jetzt gerade konkret?
Die Mac-Anhängigkeit ist imo nicht so schlimm, da man a) einen fallback zum alten Lexer einbauen kann und b) clang sowieso auf andere *NIX portiert wird/wurde.
Woran hapert es denn jetzt gerade konkret?
Ist das so? Wo finde ich die? Ich hatte ein bisschen gegoogelt, aber nur einen ML-Eintrag gefunden wo jemand meinte, sowas wäre ja mal eine gute Idee und das man das ctypes-Modul nicht clang 2.8 übersetzen kann, was aber etwas ganz anderes ist.Darii hat geschrieben:Klingt interessant. Hatte auch schonmal über sowas nachgedacht. Ich habe mir libclang aber noch nicht genauer angeguckt, aber python-Bindings existieren ja dafür (sogar über ctypes).
Inzwischen habe ich dem ObjectiveCLexer von Pygments eine neue Regel für Blöcke beigebracht, was die meisten verbleibenden Highlighting-Fehler beseitigt hat. Nun habe ich schon so viel Zeit in das Thema versenkt, nun werde ich das auch fertig machen. So wird bei `[self foo:a]` z.B. das `foo:` nur aus Versehen hervorgehoben, weil der Lexer denkt, es wäre eine goto-Sprungmarke. Auch würde ich gerne `self` hervorheben. Und idealerweise auch Projektfremde Datentypen. Textmate enthält eine sehr, sehr lange Liste von Cocoa-Konstanten. Ich bin am Überlegen, ob ich die kopieren soll oder einfach sagen, Namen, die mit `NS` oder `UI` beginnen, werden als Name.Builtin` dargestellt, alle anderen als `Name`. Hm.
Stefan
Ist im offiziellen llvm repository: http://llvm.org/viewvc/llvm-project/cfe ... gs/python/ weiß aber nicht wie komplett die sind. Dann habe ich noch einen Fork davon gefunden https://bitbucket.org/binet/py-clang ka was da jetzt aktueller/besser der istsma hat geschrieben:Ist das so? Wo finde ich die? Ich hatte ein bisschen gegoogelt, aber nur einen ML-Eintrag gefunden wo jemand meinte, sowas wäre ja mal eine gute Idee und das man das ctypes-Modul nicht clang 2.8 übersetzen kann, was aber etwas ganz anderes ist.Darii hat geschrieben:Klingt interessant. Hatte auch schonmal über sowas nachgedacht. Ich habe mir libclang aber noch nicht genauer angeguckt, aber python-Bindings existieren ja dafür (sogar über ctypes).