Um aus dem BMC TPL Code All-Around Plugin ein echtes, professionelles IDE-Tool zu machen, ist die zukünftige Entwicklung in drei klare Phasen unterteilt.
Bevor neue Features implementiert werden, fokussiert sich das Projekt zunächst auf eine saubere, wartbare Architektur.
🛠️ Phase 1: Architektur & Refactoring (Aufräumen)
Die aktuelle Codebasis muss strukturiert werden, um zukünftiges Wachstum ohne "Spaghetti-Code" zu ermöglichen.
[x] Ordnerstruktur etablieren: Zerlegen der Hauptdateien in logische Module (z. B. src/providers/, src/linter/, src/utils/, src/core/).
[x] Linter modularisieren: Die monolithische validateTplDocument-Funktion in eigene, testbare Teilfunktionen splitten (z. B. checkSyntax.ts, checkBlocks.ts, checkAssignments.ts).
[begonnen] Neben dem Linter auch weitere funktionsbereiche (die providers) aufteilen
[ ] Daten-Trennung: Auslagern der statischen Snippets und BMC-Funktionen in eigene Konfigurations- oder Daten-Ordner.
[ ] Kontext-Kategorisierung: Snippets und Hilfsfunktionen nach Gültigkeitsbereich trennen (Allgemein, Pattern, Syncmapping).
🧠 Phase 2: Kontextsensitive Intelligenz (UX-Verbesserung)
Die Autovervollständigung und Hover-Informationen sollen verstehen, wo sich der Nutzer gerade im Code befindet.
[ ] Kontext-Awareness: Die Autovervollständigung bietet nur noch logisch sinnvolle Snippets an (z. B. kein metadata-Vorschlag mitten in einem body-Block, kein tpl_skeleton, wenn bereits eine Modul-Definition existiert).
[ ] Hover-Kategorisierung: Optische Unterscheidung im Tooltip zwischen lokalen (define), extern importierten und nativen BMC-Funktionen (z. B. durch kleine Badges oder Labels im Markdown).
[ ] Smart Semicolons: Snippets für Funktionsaufrufe generieren das abschließende Semikolon automatisch mit, falls der Kontext dies erfordert.
[ ] Dynamische Trigger: Autovervollständigung bei spezifischen Blöcken wie Triggern und Bedingungen optimieren.
🔍 Phase 3: Deep Code Analysis (Smarter Linter)
Erweiterung des Linters von einem reinen Syntax-Checker zu einem intelligenten Code-Reviewer (Refactoring-Hilfen).
[ ] DRY-Erkennung (Don't Repeat Yourself): Ein Algorithmus, der identische oder fast identische Code-Blöcke erkennt und als "Info" markiert (Vorschlag: "Dieser Code wiederholt sich, erwäge eine define-Funktion").
[ ] Log-Konsolidierung: Erkennen von mehreren aufeinanderfolgenden log.*-Zeilen des gleichen Typs mit einem Quick Fix, um diese zu einer Zeile/Liste zusammenzufassen.
[ ] Feinmaschige Syntax-Checks:
[ ] Prüfung auf fehlende Kommas in Listen und Tabellen.
[ ] Erkennung fehlender Keywords wie then nach einem if.
[ ] Validierung von Operator-Kombinationen.