nicht angemeldet
fischlakHallo Felix,
in meinem aktuellen Projekt habe ich gerade mal etwa 1/3 der Strecke zurückgelegt. Das taugt nicht für eine Demo.
Eigentlich ist die Nummer mit Folding, Peek und übermäßiger Inline-Lokalisierung nur ein Versuch, die Unzulänglichkeit moderner Code-Editoren zu kompensieren.
Viel besser wäre eine geeignete Projektdatei. Weil wir hier in der Ecke Javascript sind, möchte ich mal als Beispiel einen groben Umriss für solch eine JS-Projektdatei geben.
Ich bin Deinem Wunsch entsprochen und hab mir mal die Mühe gemacht und ein Beispiel erstellt. Die Projektdatei könnte wie Hypertext strukturiert sein. Das Beispiel zeigt einen funktionierenden Prototypen einer eigenen Meta‑Sprache, die den Zweck haben soll, den Bedarf nach solchen Tricks wie Folding und Peek gar nicht erst aufkommen zu lassen. Nehmen wir für unseren minimalen Prototypen folgende JS-Funktion:
function foo(x, y){
return x + y;
}
Ein Browser, mit geeignetem Parser, könnte den Quelltext als DOM anzeigen, z. B.:
<function> als collapsible Block
<params> als Liste
<compute> als Baum
<operator> als Symbol
Das wäre sogar visuell besser als jeder Editor heute.
Beispiel‑Darstellung (konzeptionell):
Function foo
├── Params
│ ├── x
│ └── y
└── Return
└── Compute
├── left: x
├── operator: +
└── right: y
Wenn Du das jetzt ausprobieren möchtest, dann lege bitte 3 Dateien an:
- Minimal, aber realistisch:
example.htjs
<function name="foo">
<params>
<param>x</param>
<param>y</param>
</params>
<body>
<return>
<compute>
<left>x</left>
<operator>+</operator>
<right>y</right>
</compute>
</return>
</body>
</function>
Letzteres ist natürlich kein gültiges HTML, sondern eine semantische Beschreibung einer Funktion mit XML-Bordmitteln.
- Ein Mini‑Parser HTJS -> JavaScript. Folgend der Code für einen kleinen Parser in JavaScript, der:
-
die Datei einliest
-
die XML‑Struktur parst
-
daraus echten JavaScript‑Code generiert:
htjs-parser.js
export function parseHTJS(htjsString) {
const parser = new DOMParser();
const xml = parser.parseFromString(htjsString, "text/xml");
const fn = xml.querySelector("function");
const name = fn.getAttribute("name");
const params = [...fn.querySelectorAll("params > param")]
.map(p => p.textContent.trim())
.join(", ");
const compute = fn.querySelector("compute");
const left = compute.querySelector("left").textContent.trim();
const op = compute.querySelector("operator").textContent.trim();
const right = compute.querySelector("right").textContent.trim();
return `
window.foo = function ${name}(${params}) {
return ${left} ${op} ${right};
}
`.trim();
}
Letzteres ist ein echter Transpiler – nur sehr klein.
- Demo: HTJS für den Browser:
demo.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<script type="module">
import { parseHTJS } from './htjs-parser.js';
const htjs = await fetch('./example.htjs').then(r => r.text());
const jsCode = parseHTJS(htjs);
console.log("Generierter JS-Code:");
console.log(jsCode);
// Dynamisch ausführen
eval(jsCode);
console.log("foo(3, 4) =", foo(3, 4));
</script>
</body>
</html>
Wenn du die Dateien anlegst und die demo.html im Browser öffnest, passiert:
-
Die HTJS‑Datei wird geladen
-
Der Parser erzeugt echten JavaScript‑Code
-
Der Code wird evaluiert
-
Die Funktion foo existiert und funktioniert
Dann siehst Du im Bereich Entwicklertools in der Konsole das Ergebnis.
Natürlich siehst Du im Browserfenster selbst keinen Code, weil der Browser keinen Parser für die verwendeten Tags hat. Soll ja nur eine Minimal-Demo sein, die das grundsätzliche Konzept auf der Ebene eines Konzept-Prototyps veranschaulicht.
WENN Browser sowas KÖNNTEN, dann würden sie den Javascript-Code genauso anzeigen, wie es aktuelle Code-Editoren tun. Inkl. CSS für Syntax-Highlighting.
Und dann müsste es eine Browser-Funktionalität "Bearbeiten" geben und der Browser im Bearbeitungsmodus natürlich lokale Schreibrechte haben. So wird der Browser zum Editor... :-)
Und DANN könnte man natürlich Features einbauen, wie:
-
STRG + Klick auf eine Funktions-Referenz = Funktion samt Inhalt klappt in einem Inline-Frame zur Sichtung und Bearbeitung auf (wie Peek). Das ist exakt AST‑Navigation, semantische Referenzauflösung, Inline‑Expansion.
-
STRG + Klick funktioniert bei ALLEN Referenzen. Das ist sogar noch einfacher:
<call ref="foo"> -> springe zu <function name="foo">
<var ref="x"> -> springe zur Deklaration
<import ref="module"> -> öffne Modul
Das ist Hypertext, nicht "Code".
-
Platzierung der Funktions-Definition ist egal – ob am Anfang oder am Ende... Platzierung der Definition egal, denn: Hypertext ist nicht linear! Nur Textdateien sind linear. Mit Hypertext ist man bereits jenseits von Textdateien.
-
STRG + Klick auch Datei-übergreifend wirksam. Das ist "Cross‑File AST" und "Cross‑Module Hyperlinks", also semantische Navigation.
Das wäre eine neue Art, Code zu repräsentieren. Browser könnten das sofort, wenn sie HTJS verstünden. Diese Idee ist eigentlich ziemlich mächtig, weil sie das Grundproblem löst, das ich seit Postings beschreibe: Textdateien sind ein schlechtes Format für Code.
Vielleicht verstehst Du jetzt, was ich meine...
Jetzt mach ich mich aber wieder an die Konfiguration meines neuen LTS ran, sonst wird das nie fertig.
Gruß, fischlak
Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...
Rolf B
Julius
Gunnar Bittersmann
MudGuard