Beschreibung: https://nixos.org/nix/manual/#ch -expression-language
In https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/misc/ctags/wrapped.nix gibt es einige sehr grundlegende Konfigurationen:
--langdef=NIX
--langmap=NIX:.nix
--regex-NIX=/([^ \t*]*)[ \t]*=/\1/f/
Ich habe dies (hoffentlich) lokal etwas verbessert:
--regex-NIX=/([^ \t*]*)[ \t]*=.*:/\1/f/
Aber es ist immer noch zu einfach und würde wahrscheinlich einen separaten Parser benötigen.
Ich bin selbst neu bei Nix / NixOS und habe daher nicht viel Wissen
über diese Sprache selbst.
Nix selbst analysiert die Sprache - es verwendet Standard-Parsing- und Lexing-Tools https://github.com/NixOS/nix/tree/master/src/libexpr (wahrscheinlich am nützlichsten im Zusammenhang mit diesem Problem). Dann kenne ich einige Dinge in haskell https://github.com/peti/language-nix , und es gibt Syntax-Textmarker für verschiedene Editoren (oder das Hervorheben von Bibliotheken).
Als Erstversion ist eine Implementierung mit regulären Ausdrücken in Ordnung. es ist immer besser als nichts.
Obwohl ich die Verzeichnisstrukturen überdenken muss, ist optlib die erstklassige Möglichkeit, einen Parser zu implementieren.
Sie können später einen C-basierten Parser schreiben. Der wichtige Punkt ist die "Arten" -Kompatibilität zwischen Regex
basierter Parser und C-basierter Parser. Wenn die Kompatibilität der Arten erhalten bleibt, kümmert sich niemand um die Art der Implementierung.
Wenn die Nix-Implementierung jedoch einen echten Parser hat, warum verwenden Sie ihn nicht? Mein xmcd ist für dich.
Siehe data / optlib / cofee.ctags und libexec / drivers / coffeetags.
Hallo, wie ist der Status dieses Problems?
Eine Pull-Anfrage ist willkommen.
Hilfreichster Kommentar
Hallo, wie ist der Status dieses Problems?