Hallo Felix, obwohl ich mich schon frage, ob der Nutzen eines Editors, der Quellcode als "HTML + CSS + JS" darstellt, den Realisationsaufwand wert ist. Syntax-Highlighting hat jeder Editor heute. "Signature Help" ebenfalls. Und auch Auto-Vervollständigung. Und Peek ist auch bereits Realität – ein DOM‑basierter Editor könnte das zwar viel flexibler lösen als ein Texteditor, aber das ändert nichts an der Tatsache, dass solche Features bereits umgesetzt sind. Genauso Folding. Und die Vorteile von LSP nicht zu vergessen. Vielleicht war ich da doch etwas zu enthusiastisch und hab Kosten/Nutzen nicht objektiv abgewogen. Wenn das Ziel ein massentauglicher Editor wäre, dann wäre das Kosten-Nutzen-Verhältnis vermutlich negativ, da VS Code/VSCodium, Kate u.s.w. "gut genug" sind. Wenn das Ziel aber eine neue Art des Programmierens oder ein spezialisiertes Tool für visuelle Code-Analyse ist, könnte der Nutzen den Aufwand rechtfertigen – vor allem als akademisches oder experimentelles Projekt. Aber amortisieren würde sich solch ein Projekt wohl eher nicht. Man könnte den Aufwand minimieren und nur einen Read-only-Viewer bauen. Also ein Tool, das bestehenden Code als interaktiven Hypertext darstellt, ohne dass man darin schreiben muss. Aber welchen praktischen Vorteil soll das haben? Ein reiner Viewer wäre wohl dann eher Selbstzweck und "nettes Gimmick". Die technische Umsetzung von Transcompiling wäre dann wohl einfacher realisierbar. Aber wer braucht das schon? Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, obwohl ich mich schon frage, ob der Nutzen eines Editors, der Quellcode als "HTML + CSS + JS" darstellt, den Realisationsaufwand wert ist. Syntax-Highlighting hat jeder Editor heute. "Signature Help" ebenfalls. Und auch Auto-Vervollständigung. Und Peek ist auch bereits Realität – ein DOM‑basierter Editor könnte das zwar viel flexibler lösen als ein Texteditor, aber das ändert nichts an der Tatsache, dass solche Features bereits umgesetzt ist. Genauso Folding. Und die Vorteile von LSP nicht zu vergessen. Vielleicht war ich da doch etwas zu enthusiastisch und hab Kosten/Nutzen nicht objektiv abgewogen. Wenn das Ziel ein massentauglicher Editor wäre, dann wäre das Kosten-Nutzen-Verhältnis vermutlich negativ, da VS Code/VSCodium, Kate u.s.w. "gut genug" sind. Wenn das Ziel aber eine neue Art des Programmierens oder ein spezialisiertes Tool für visuelle Code-Analyse ist, könnte der Nutzen den Aufwand rechtfertigen – vor allem als akademisches oder experimentelles Projekt. Aber amortisieren würde sich solch ein Projekt wohl eher nicht. Man könnte den Aufwand minimieren und nur einen Read-only-Viewer bauen. Also ein Tool, das bestehenden Code als interaktiven Hypertext darstellt, ohne dass man darin schreiben muss. Aber welchen praktischen Vorteil soll das haben? Ein reiner Viewer wäre wohl dann eher Selbstzweck und "nettes Gimmick". Die technische Umsetzung von Transcompiling wäre dann wohl einfacher realisierbar. Aber wer braucht das schon? Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, obwohl ich mich schon frage, ob der Nutzen eines Editors, der Quellcode als "HTML + CSS + JS" darstellt, den Realisationsaufwand wert ist. Syntax-Highlighting hat jeder Editor heute. "Signature Help" ebenfalls. Und auch Auto-Vervollständigung. Und Peek ist auch bereits Realität – ein DOM‑basierter Editor könnte das zwar viel flexibler lösen als ein Texteditor, aber das ändert nichts an der Tatsache, dass solche Features bereits umgesetzt ist. Genauso Folding. Und die Vorteile von LSP nicht zu vergessen. Vielleicht war ich da doch etwas zu enthusiastisch und hab Kosten/Nutzen nicht objektiv abgewogen. Wenn das Ziel ein massentauglicher Editor wäre, dann wäre das Kosten-Nutzen-Verhältnis vermutlich negativ, da VS Code/VSCodium, Kate u.s.w. "gut genug" sind. Wenn das Ziel aber eine neue Art des Programmierens oder ein spezialisiertes Tool für visuelle Code-Analyse ist, könnte der Nutzen den Aufwand rechtfertigen – vor allem als akademisches oder experimentelles Projekt. Aber amortisieren würde sich solch ein Projekt wohl eher nicht. Man könnte den Aufwand minimieren und nur einen Read-only-Viewer bauen. Also ein Tool, das bestehenden Code als interaktiven Hypertext darstellt, ohne dass man darin schreiben muss. Aber welchen praktischen Vorteil soll das haben? Ein reiner Viewer wäre wohl dann eher Selbstzweck und "nettes Gimmick". Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, obwohl ich mich schon frage, ob der Nutzen eines Editors, der Quellcode als "HTML + CSS + JS" darstellt, den Realisationsaufwand wert ist. Syntax-Highlighting hat jeder Editor heute. "Signature Help" ebenfalls. Und auch Auto-Vervollständigung. Und Peek ist auch bereits Realität – ein DOM‑basierter Editor könnte das zwar viel flexibler lösen als ein Texteditor, aber das ändert nichts an der Tatsache, dass solche Features bereits umgesetzt ist. Genauso Folding. Und die Vorteile von LSP nicht zu vergessen. Vielleicht war ich da doch etwas zu enthusiastisch und hab Kosten/Nutzen nicht objektiv abgewogen. Wenn das Ziel ein massentauglicher Editor wäre, dann wäre das Kosten-Nutzen-Verhältnis vermutlich negativ, da VS Code/VSCodium, Kate u.s.w. "gut genug" sind. Wenn das Ziel aber eine neue Art des Programmierens oder ein spezialisiertes Tool für visuelle Code-Analyse ist, könnte der Nutzen den Aufwand rechtfertigen – vor allem als akademisches oder experimentelles Projekt. Aber amortisieren würde sich solch ein Projekt wohl eher nicht. Man könnte den Aufwand minimieren und nur einen Read-only-Viewer bauen. Also ein Tool, das bestehenden Code als interaktiven Hypertext darstellt, ohne dass man darin schreiben muss. Aber welchen praktischen Vorteil soll das haben? Das wäre wohl dann eher Selbstzweck. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, obwohl ich mich schon frage, ob der Nutzen eines Editors, der Quellcode als "HTML + CSS + JS" darstellt, den Realisationsaufwand wert ist. Syntax-Highlighting hat jeder Editor heute. "Signature Help" ebenfalls. Und auch Auto-Vervollständigung. Und Peek ist auch bereits Realität – ein DOM‑basierter Editor könnte das zwar viel flexibler lösen als ein Texteditor, aber das ändert nichts an der Tatsache, dass solche Features bereits umgesetzt ist. Genauso Folding. Und die Vorteile von LSP nicht zu vergessen. Vielleicht war ich da doch etwas zu enthusiastisch und hab Kosten/Nutzen nicht objektiv abgewogen. Wenn das Ziel ein massentauglicher Editor wäre, dann wäre das Kosten-Nutzen-Verhältnis vermutlich negativ, da VS Code/VSCodium, Kate u.s.w. "gut genug" sind. Wenn das Ziel aber eine neue Art des Programmierens oder ein spezialisiertes Tool für visuelle Code-Analyse ist, könnte der Nutzen den Aufwand rechtfertigen – vor allem als akademisches oder experimentelles Projekt. Aber amortisieren würde sich solch ein Projekt wohl eher nicht. Man könnte den Aufwand minimieren und nur einen Read-only-Viewer bauen. Also ein Tool, das bestehenden Code als interaktiven Hypertext darstellt, ohne dass man darin schreiben muss. Aber welchen Vorteil soll das haben? Das wäre wohl dann eher Selbstzweck. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...