Tach an alle Linuxer,
Der folgende Artikel ist nicht Linux spezifisch aber eventuell
interessant für alle Coder.
Meine Anmerkungen zum untenstehenden Kommentar von Dirk bezog sich auf eine vorige Version dieses Artikels. Die jetzige Verssion ist die Langfassung.
Es geht um das Feature der Codefaltung und dessen effiziente Nutzung in
Codeeditoren. Fast alle aktuellen Quelltexteditoren bieten dieses
Ausstattungsmerkmal. Damit lassen sich ganze Codesequenzen im Quellcode ein
und ausklappen. Sinn ist das man nicht seitenweise in seinem Code scrollen
muss um diesen an einer ganz bestimmten Stelle zu editieren. Alle aktuell
nicht benötigten Codesequenzen werden einfach eingeklappt, und nur das
interessierende zum editieren ausgeklappt.
Realisiert wird dies durch eine zusätzliche Leiste am linken Rand des Quellcodeeditor neben der Zeilennummerierung außerhalb des eigentlichen Textbereiches beispielsweise mit anfassbaren Pfeilen.
So die Theorie. Basieren tut diese Technologie auf die automatische
Erkennung einer zusammenhängenden Codesequenz. Grundlage dafür ist das
Quellcode in Intervallen organisiert ist. Der Beginn eines Intervall wird
durch ein bestimmtes syntaktisch elementares Zeichen oder einer Sequenz
eingeleitet und am Ende durch deren komplementäres Element ausgeleitet.
Beispiel wäre hierzu die geschweifte Anweisungsblockklammer in der
C-Programmierung zur Einrahmung eines Sets an Anweisungen. Öffnende und
zugehörende schließende Klammer werden im Quelltext von der Codefaltung
identifiziert und der Code dazwischen ist dann wahlweise ein- oder ausklappbar.
Ich benötige dieses Feature aktuell in Zusammenhang mit der HTML- und
JavaScript Programmierung. Theoretisch bieten sich diese Sprachen
besonders gut fuer die Codefaltung an, da in ihnen das Prinzip der
Intervallgültigkeit durch die öffnenden und schließenden Tags auf die
Spitze getrieben ist.
Haken ist aber hierbei das die Faltung natürlich nur nach Quelltextsyntaktischen und nicht nach semantischen Kriterien funktionieren kann. Ein auf und zuklappbares Quelltextintervall muss nicht automatisch auch eine eigene inhaltlich funktionale Einheit bilden.
Eines der wenigen Gegenbeispiele sei im Folgenden erläutert. Wir lassen ein p – Absatz Tag“ mit Hilfe der Codefaltung ein- und ausklappen. In einem HTML- Formatierten klassischen Sachtext dient das P-Tag eigentlich nur der Formatierungsanweisung für die Absatzbildung in der Frontend Darstellung auf dem Bildschirm. Da Absätze aber auch eine thematisch zusammenhängende Informationseinheit bilden, haben wir in diesem speziellen Fall die Situation dass die technologische Codefaltung mit der der semantischen korrespondiert.
Möchte man aber beispielsweise einen Variablendeklarationsbereich innerhalb
einer JavaScript Sequenz spezifisch ein oder ausklappen, würde die
Codefaltung aber nur den kompletten JavaScript Bereich anhand der gesamten
öffnenden und schließenden Tag-Sequenz <script>…</script>
identifizieren und alles ein oder ausklappen. Denn im Sinne der
Quelltextsyntax stellt der Variablendeklarationsbereich erst eimal keine
eigene Entität dar.
Ich habe es mir mittlerweile angewöhnt semantisch eine Einheit bildenden
HTML – Codes mit einer horizontalen Linie und einer mittig angeordneten
Hinweismitteilung zum Beginn und einer 2. am Ende einzurahmen und damit vom
anderen Code abzugrenzen. Diese Linie baue ich einfach mit Bindestrichen
auf. Da sie Syntaktisch natürlich in keiner Weise eine Wirkung haben darf
ist sie Teil einer HTML – Kommentar Sequenz.
In der Art:
<!– ——- Anfang : Codesequenz XY ——– –>
Bla, Bla, Bla
…
…
<!– ——- Ende : Codesequenz XY——– –>
Leider lässt sich eine so selbstdefinierte semantische Klammerung nicht in
das Codefaltungsfeature einbinden da die Codefaltung Kommentarsequenzen
generell ignorieren. Dachte ich zumindestens weil mir die Faltung im Editor sublime text zunächst nicht gelang. Dazu aber später mehr.
Allerdings könnte ich sie im oben gezeigten Beispiel der Faltung von
Absätzen dazu nutzen Kapitelüberschriften und deren Abschluss zu
generieren Die Kapitelgrenzen werden vor und nach dem jeweiligen p-Tag
gesetzt und sind damit selbst nicht Element der Codefaltung. Bleiben wenn
man so will immer ausgeklappt. Sind alle Absätze eingeklappt, seh ich vom
Sachtext nichts mehr, könnte aber anhand der als Kommentarsequenz
gestalteten Kapitelüberschrift sofort den Absatz identifizieren dem ich
noch eine Anmerkung hinzufuegen moechte und diesen über die Codefaltung
aufklappen.
Eine faltfähige Codesequenz ist im HTML – Kontext fast immer auch eine nach außen hin wirkende HTML-Formatierungs Sequenz. D.h man kann nicht einfach HTML-Tags in den Quelltext einbauen die nur der spezifischen Faltung des Codes dienen sollen. Sie würden
immer auch auf das Layout des Bildschirm Frontends durchschlagen.
Mit nach meiner bisherigen Erkenntnis einer Ausnahme dem JavaScript
Intervall einrahmenden <script > < /script > – Tag.
Dieser Tag ist aber auch gar kein HTML-Tag im eigentlichen Sinne sondern leitet einen kompletten Kontextwechsel in einem Quelltext ein.
Man bräuchte also Quelltextstatements die nur in der Codefaltung wirken.
Codeelemente die nur innerhalb eines Quelltextes in einem eigenen Kontext
wirken, nennt man in einem anderen Zusammenhang typischer Weise
Praeprozessor Statements.
Im oben erläuterten Beispiel der separaten Einfassung des Variablendeklaration Abschnittes, für die Codefaltung könnte man also statt einen kompletten JavaScript intervall einrahmenden Script – Tag den Variablendeklarationsbereich mit dem >script < – Tag spezifisch einrahmen.
D.h. obwohl der JavaScript – Bereich eigentlich über den Variablendeklarationsbereich weiterwirken soll wird
er vor Beginn des Variablendeklaration Bereiches abgeschaltet und gleich
wieder eingeschaltet. Das gleiche am Ende des Variablenbereiches. Wir haben
damit die separate Anfassbarkeit des Variablendeklaration Bereiches erreicht.
Das aber ist eine unglückliche Vorgehensweise den <script > -Tag dazu Zweck zu entfremden eigentlich zusammengehörige Kontexte künstlich zu fragmentieren nur um damit die spezifische Zugriffsfähigkeit durch die Codefaltung zu erhalten und bedeutet dann natürlich auch das nur Code auf JavaScript Ebene semantisch separiert und kontextuell zusammengefasst werden kann.
Wollen wir JavaScript übergreifend Quelltext semantisch zusammnefassen bräuchten wir also eine Art HTML-Fake Tag
das nur fuer die Codefaltung da ist, im HTML-Sinne aber keine
Formatierungsbedeutung hat. Die ist aber im Sinne des HTML Hypertextparadigmas ist ein Widerspruch in Sich.
Hier wäre also ein eigenständiges Tag für die Faltung wünschenswert. Aber muss es überhaupt ein Tag sein. Die Codefaltung ist ein Feature das universell und unabhängig der gerade im Editor bearbeiteten Programmiersprache arbeitet. Sie funktioniert weil alle Programmiersprachen Syntaxelemente aufweisen die eine Klammerung von Kontexten ermöglichen. Diese Synaxstrukturen werden von der Codefaltung adaptiv erkannt und für die Faltung berücksichtigt.
Das führt zu der Frage welche Möglichkeiten es überhaupt gibt einen zusammengehörigen Kontext in einem Quelltext mit Mitteln der Notation zu klammern. Der Begriff Klammerung sagt es ja eigentlich schon. Zunächst eben alle Arten von klammernden Einzelzeichen also geschweifte, runde, eckige Klammern. Eine weitere wäre die Klammerung nicht durch Einzelzeichen sondern zusammengehörigen öffnenden und schließenden Zeichensequenzen. Ein erstes Beispiel ist hier die Blockkommentar Klammer /* */ in etlichen Programmiersprachen. In diese Kategorie gehören auch die öffnenden und schließenden HTML-Tags die ja oben schon ausführlich erläutert wurden.
Eine weitere blieb mir allerdings bisher verborgen, und wird im folgenden erläutert.
Ein aktuelles Experiment im Codeeditor sublime hat ergeben das HTML –
Kommentarsequenzen eventuell doch fuer die Codefaltung geeignet sind. Ich
habe festgestellt das die Codefaltung auch bei ihnen Funktioniert wenn die
korrespondierenden Zeilen am Beginn und am Ende eines Codeblocks die
gleiche horizontale Einrücktiefe aufweisen.
Das könnte Hinweise auf die tiefer gehende Arbeitsweise des
Codefaltungsfeature geben. Solange es geht versucht die Codefaltung
zusammengehörende Codeabschnitte anhand spezifischer Syntaxmerkmale zu
intervallisieren. Das Funktioniert wie oben schon erwähnt weil dem Editor Syntaxgrammatiken gänger Programmiersprachen bekannt sind. Hilft das nicht weiter wie bei unsereren Kommentarsequenzen, könnte der Editor dann anhand von Codeeinrückungen
zusammengehörende Schachtelungstiefen zu identifizieren versuchen. Diese
Strategie könnte sogar Vorteile aufweisen weil der Codeeditor dann gar
kein Syntaxwissen bräuchte. Das steckt quasi der Entwickler durch seine
geschickte Einrückungsstrategie in das System rein.
Was ist die Quintessenz obiger Überlegungen. Mit keinem Stilmittel der physischen Kontextzusammenfassung allein, sei sie nun durch elementare Klammerungszeichen, Tag-Klammerung oder Einrueckungebenen des Quelltextes erreicht, lässt sich der Konflikt der Diskrepanz der semantischen Kontextzusammenfassung mit mitteln der syntaktischen Klammerung wirklich umgehen.
Aber im Arrangement entfalten sie vielleicht die gewünschte Wirkung.
Der letzte aus meiner Sicht notwendige Schritt wäre dann noch nich nur ein einzelnes Intervall auf-und zuklappen zu können sondern gleich mehrere die sich dadurch auszeichnen einen zusammengehörigen Kontext zu bilden. Man hätte dann sozusagen spezifische Sichten auf den Quellcode.
Dirk Haar
mmmh.
Zuletzt habe ich (in der Entwicklung von SAS-Programmen) mit Notepad++ (ja, läuft nur unter „Jehova“) gearbeitet.
Wenn ich nicht ganz falsch liege, markiert man einen Bereich und klappt den ein.
Klappt man einen weiteren Bereich ein, der eine Einklappung enthält, geht das nach dem Zwiebelprinzip,
das Ausklappen entsprechend (oder komplett).
Bei meinen (zur Zeit) kurzen Skripten unter Linux habe ich Falten noch nie weiter benötigt – empfinde es aber seit Atari ST/GFA_Basic-Zeiten prinzipiell als eine essentielle Funktion.
(Ich meine, zumindest das Ausblenden aktuell nicht benötigter Zeilen gibt es selbst auf dem Mainframe seit wann – 1980 oder früher?)
Visual Studio und Godot Engine machen es offensichtlich syntax-orientiert (ganze Funktionen, Var.-Def., Befehlsstrukturen), Gambas kann es wohl nur mit einzelnen Prozeduren/Funktionen.
Womit entwickelst und editierst Du?
Heiko Künzel
Hallo Dirk,
zu aller erst muss ich sagen das dieser Beitrag völlig unabhängig von seinem Inhalt ein Test für den Backend Zugang zur Homepage der Wilhelmshavener Linuxer war. Das das ein Test war merkst du auch daran das ich ihn per Copy und Paste von meinem Rechner rübergezogen habe, und dabei ist gar nicht der volle Text rübergekommen. Deshalb endet es so abrupt. Dein Kommentar erinnert mich daran das ich das noch korrigieren muss !! Dann werden meine Überlegungen vielleicht noch etwas nachvollziehbarer:-) Dazu kommt das ich zur Demonstrationsvisualisierung HTML-Tags eingebaut hatte die dann das WordPress im Frontend einfach verschluckt.
Was ich eigentlich sagen wollte ist, das es oft sinnvoll wäre spezifische Codeansichten zu haben die Funktionsdeklarationen und ihre Aufrufe gleichzeitig anzeigen. Damit man beispielsweise Parameterübergaben, oder wo eine Funktionsrückgabe bleibt, mit einem Blick sehen kann. Denn manchmal sieht man einen Schnittstellenfehler zwischen Aufruf und Deklaration einer Funktion auf den ersten Blick gar nicht, weil sie eben nicht mit einem Blick erfassbar sind. Oft sind diese ja auch in verschiedenen Dateien versteckt, dann nützt einem die Codefaltung ohnehin herzlich wenig weil ein bestimmter Editor ja immer nur eine Datei zeigt.
Vielleicht poste ich das hier auch noch einmal. Denn das obige Beispiel ist nur eine Facette von etlichen Kritikpunkten die ich an die die meisten gängigen Quelltext Editoren habe. Alle haben eins gemein sie verstehen sich eben als Editoren die eine archaische Editation zulassen. Und diese Metapher als ganzes hinkt. Normalerweise müsste Editoren meiner Meinung nach so arbeiten das sie Editionen die zu einer auch nur zwischenzeitlich unkorrekten Syntax führen würden so gut es geht grundsätzlich zu unterdrücken suchen, anstatt das ich durch rätselhafte Compilermeldung die nie das wirkliche Problem anzeigen rausfinden muss was ich falsch gemacht habe.
Pseudo Freiheitsgrade vermeiden wäre meine Losung 🙂
Und wie wenig die Editoren das teilweise verinnerlicht haben kann man beispielhaft an der Autovervollständigungs Arbeitsweise zwischen „meinem“ Sublime Text Editor im Vergleich zum VS-Code , dessen Arbeitsweise ich letztens in einem youtube-Video gesehen habe sehr schön zeigen.
Wenn ich im „sublime-text“ ein öffnendes html-Tag ausschreibe, wird das zugehörige schliessende Tag erst in dem Moment erzeugt in dem ich wieder „spitze Klammer auf“ und dann „Schrägstrich“ tippe. In dem Moment erkennt der Editor das ich ein Tag schliessen will und er weiss ja auch noch welches geöffnet war und schliesst es dann korrekt.
Aber worin liegt die Notwendigkeit das dieser „Schließ-Kontext“ von mir aus erst einmal herbeigeführt werden muss?
Deshalb macht es VS-Code ganz anders und erzeugt den Schließ-Tag sobald das komplementäre öffnende Tag erkannt ist.
Ich vermute da endet aber auch die Intelligenz von VS-Code. Es macht eigentlich nie Sinn das schließende Tags selbst erzeugt werden müssen, und das heißt im Umkehrschluss das sie separat gar nicht anfassbar sein dürften. Der Editor müsste an dieser Stelle jede Editation verweigern als wär das Dokument schreibgeschützt.
Denn worin sollte an dieser Stelle ein sinnvoller Editionskontext bestehen? – was will ich denn erreichen?
Will ich den zwischen den Tags liegenden Text in einem anderen Tag einrahmen ? Na gut, dann spring in den öffnenden Tag und editiere diesen wobei der schließende analog mit geändert wird. Will ich das das ganze Element gelöscht wird, dann lösch alles – aber bitte nur wenn ich den Tag geklammerten Text erstmal separat entfernt habe, um zu vermeiden das der dann kontextlos in meinem Dokument rumbaumelt. Usw. usw.
Wie gesagt ich hab mir verschiedene Gedanken dazu gemacht. Beispielsweise auch wie man ein Editions- Management für Funktionsdeklarationen- und Aufrufe gestalten könnte um syntaktisch fehlerhafte Zwischenstände fast vollständig zu vermeiden.
Somit verbleibe ich erst einmal mit freundlichem Gruß
Heiko
Dirk Haar
Ich widerspreche übrigens deiner Ansicht, man solle Schließtags nie selbst einfügen müssen.
Wenn Du Code warten musst, kommst du mit einzelnen Einfügungen oft nicht weit,
bei Anderungen verschachtelteter if-Anweisungen ein größeres if einbauen zu müssen,
kann ganz leicht dazu führen, das die beendende Anweisung viel weiter unten hingehört als in den aktuellen Zweig.
Du bist in solchen Fällen einfach nicht Herr des Codes, du kannst nicht 25000 Zeilen erst
einmal in eine vernünftige Form bringen, die Gefahr von Regressionen ist zu groß.
Heiko Künzel
So hier nochmal mein Update mit dem gesamten Artikel
Claus du müsstest dann den Primärartikel rausschmeissen und durch diesen Text ersetzten.
Wie gesagt ich hab aktuell keinen funktionierenden Login
Tach an alle Linuxer,
Meine aktuelle Frage ist eventuell noch kniffliger als meine andere im
Blog erläuterte. Sie ist auch nicht Linux spezifisch aber eventuell
interessant für alle Coder.
Es geht um das Feature der Codefaltung und dessen effiziente Nutzung in
Codeeditoren. Fast alle aktuellen Quelltexteditoren bieten dieses
Ausstattungsmerkmal. Damit lassen sich ganze Codesequenzen im Quellcode ein
und ausklappen. Sinn ist das man nicht seitenweise in seinem Code scrollen
muss um diesen an einer ganz bestimmten Stelle zu editieren. Alle aktuell
nicht benötigten Codesequenzen werden einfach eingeklappt, und nur das
interessierende zum editieren ausgeklappt.
Realisiert wird dies durch eine zusätzliche Leiste am linken Rand des Quellcodeeditor neben der Zeilennummerierung außerhalb des eigentlichen Textbereiches beispielsweise mit anfassbaren Pfeilen.
So die Theorie. Basieren tut diese Technologie auf die automatische
Erkennung einer zusammenhängenden Codesequenz. Grundlage dafür ist das
Quellcode in Intervallen organisiert ist. Der Beginn eines Intervall wird
durch ein bestimmtes syntaktisch elementares Zeichen oder einer Sequenz
eingeleitet und am Ende durch deren komplementäres Element ausgeleitet.
Beispiel wäre hierzu die geschweifte Anweisungsblockklammer in der
C-Programmierung zur Einrahmung eines Sets an Anweisungen. Öffnende und
zugehörende schließende Klammer werden im Quelltext von der Codefaltung
identifiziert und der Code dazwischen ist dann wahlweise ein- oder ausklappbar.
Ich benötige dieses Feature aktuell in Zusammenhang mit der HTML- und
JavaScript Programmierung. Theoretisch bieten sich diese Sprachen
besonders gut fuer die Codefaltung an, da in ihnen das Prinzip der
Intervallgültigkeit durch die öffnenden und schließenden Tags auf die
Spitze getrieben ist.
Haken ist aber hierbei das die Faltung natürlich nur nach Quelltextsyntaktischen und nicht nach semantischen Kriterien funktionieren kann. Ein auf und zuklappbares Quelltextintervall muss nicht automatisch auch eine eigene inhaltlich funktionale Einheit bilden.
Eines der wenigen Gegenbeispiele sei im Folgenden erläutert. Wir lassen ein p – Absatz Tag“ mit Hilfe der Codefaltung ein- und ausklappen. In einem HTML- Formatierten klassischen Sachtext dient das P-Tag eigentlich nur der Formatierungsanweisung für die Absatzbildung in der Frontend Darstellung auf dem Bildschirm. Da Absätze aber auch eine thematisch zusammenhängende Informationseinheit bilden, haben wir in diesem speziellen Fall die Situation dass die technologische Codefaltung mit der der semantischen korrespondiert.
Möchte man aber beispielsweise einen Variablendeklarationsbereich innerhalb
einer JavaScript Sequenz spezifisch ein oder ausklappen, würde die
Codefaltung aber nur den kompletten JavaScript Bereich anhand der gesamten
öffnenden und schließenden Tag-Sequenz >script<…>/script<
identifizieren und alles ein oder ausklappen. Denn im Sinne der
Quelltextsyntax stellt der Variablendeklarationsbereich erst eimal keine
eigene Entität dar.
Ich habe es mir mittlerweile angewöhnt semantisch eine Einheit bildenden
HTML – Codes mit einer horizontalen Linie und einer mittig angeordneten
Hinweismitteilung zum Beginn und einer 2. am Ende einzurahmen und damit vom
anderen Code abzugrenzen. Diese Linie baue ich einfach mit Bindestrichen
auf. Da sie Syntaktisch natürlich in keiner Weise eine Wirkung haben darf
ist sie Teil einer HTML – Kommentar Sequenz.
In der Art:
>!– ——- Anfang : Codesequenz XY ——– –<
Bla, Bla, Bla
…
…
>!– ——- Ende : Codesequenz XY——– –<
Leider lässt sich eine so selbstdefinierte semantische Klammerung nicht in
das Codefaltungsfeature einbinden da die Codefaltung Kommentarsequenzen
generell ignorieren. Dachte ich zumindestens weil mir die Faltung im Editor sublime text zunächst nicht gelang. Dazu aber später mehr.
Allerdings könnte ich sie im oben gezeigten Beispiel der Faltung von
Absätzen dazu nutzen Kapitelüberschriften und deren Abschluss zu
generieren Die Kapitelgrenzen werden vor und nach dem jeweiligen p-Tag
gesetzt und sind damit selbst nicht Element der Codefaltung. Bleiben wenn
man so will immer ausgeklappt. Sind alle Absätze eingeklappt, seh ich vom
Sachtext nichts mehr, könnte aber anhand der als Kommentarsequenz
gestalteten Kapitelüberschrift sofort den Absatz identifizieren dem ich
noch eine Anmerkung hinzufuegen moechte und diesen über die Codefaltung
aufklappen.
Eine faltfähige Codesequenz ist im HTML – Kontext fast immer auch eine nach außen hin wirkende HTML-Formatierungs Sequenz. D.h man kann nicht einfach HTML-Tags in den Quelltext einbauen die nur der spezifischen Faltung des Codes dienen sollen. Sie würden
immer auch auf das Layout des Bildschirm Frontends durchschlagen.
Mit nach meiner bisherigen Erkenntnis einer Ausnahme dem JavaScript
Intervall einrahmenden >script < > /script < – Tag.Dieser Tag ist aber auch gar kein HTML-Tag im eigentlichen Sinne sondern leitet einen kompletten Kontextwechsel in einem Quelltext ein.
Man bräuchte also Quelltextstatements die nur in der Codefaltung wirken.
Codeelemente die nur innerhalb eines Quelltextes in einem eigenen Kontext
wirken, nennt man in einem anderen Zusammenhang typischer Weise
Praeprozessor Statements.
Im oben erläuterten Beispiel der separaten Einfassung des Variablendeklaration Abschnittes, für die Codefaltung könnte man also statt einen kompletten JavaScript intervall einrahmenden Script – Tag den Variablendeklarationsbereich mit dem >script < – Tag spezifisch einrahmen.
D.h. obwohl der JavaScript – Bereich eigentlich über den Variablendeklarationsbereich weiterwirken soll wird
er vor Beginn des Variablendeklaration Bereiches abgeschaltet und gleich
wieder eingeschaltet. Das gleiche am Ende des Variablenbereiches. Wir haben
damit die separate Anfassbarkeit des Variablendeklaration Bereiches erreicht.
Das aber ist eine unglückliche Vorgehensweise den >script < -Tag dazu Zweck zu entfremden eigentlich zusammengehörige Kontexte künstlich zu fragmentieren nur um damit die spezifische Zugriffsfähigkeit durch die Codefaltung zu erhalten und bedeutet dann natürlich auch das nur Code auf JavaScript Ebene semantisch separiert und kontextuell zusammengefasst werden kann.
Wollen wir JavaScript übergreifend Quelltext semantisch zusammnefassen bräuchten wir also eine Art HTML-Fake Tag
das nur fuer die Codefaltung da ist, im HTML-Sinne aber keine
Formatierungsbedeutung hat. Die ist aber im Sinne des HTML Hypertextparadigmas ist ein Widerspruch in Sich.
Hier wäre also ein eigenständiges Tag für die Faltung wünschenswert. Aber muss es überhaupt ein Tag sein. Die Codefaltung ist ein Feature das universell und unabhängig der gerade im Editor bearbeiteten Programmiersprache arbeitet. Sie funktioniert weil alle Programmiersprachen Syntaxelemente aufweisen die eine Klammerung von Kontexten ermöglichen. Diese Synaxstrukturen werden von der Codefaltung adaptiv erkannt und für die Faltung berücksichtigt.
Das führt zu der Frage welche Möglichkeiten es überhaupt gibt einen zusammengehörigen Kontext in einem Quelltext mit Mitteln der Notation zu klammern. Der Begriff Klammerung sagt es ja eigentlich schon. Zunächst eben alle Arten von klammernden Einzelzeichen also geschweifte, runde, eckige Klammern. Eine weitere wäre die Klammerung nicht durch Einzelzeichen sondern zusammengehörigen öffnenden und schließenden Zeichensequenzen. Ein erstes Beispiel ist hier die Blockkommentar Klammer /* */ in etlichen Programmiersprachen. In diese Kategorie gehören auch die öffnenden und schließenden HTML-Tags die ja oben schon ausführlich erläutert wurden.
Eine weitere blieb mir allerdings bisher verborgen, und wird im folgenden erläutert.
Ein aktuelles Experiment im Codeeditor sublime hat ergeben das HTML –
Kommentarsequenzen eventuell doch fuer die Codefaltung geeignet sind. Ich
habe festgestellt das die Codefaltung auch bei ihnen Funktioniert wenn die
korrespondierenden Zeilen am Beginn und am Ende eines Codeblocks die
gleiche horizontale Einrücktiefe aufweisen.
Das könnte Hinweise auf die tiefer gehende Arbeitsweise des
Codefaltungsfeature geben. Solange es geht versucht die Codefaltung
zusammengehörende Codeabschnitte anhand spezifischer Syntaxmerkmale zu
intervallisieren. Das Funktioniert wie oben schon erwähnt weil dem Editor Syntaxgrammatiken gänger Programmiersprachen bekannt sind. Hilft das nicht weiter wie bei unsereren Kommentarsequenzen, könnte der Editor dann anhand von Codeeinrückungen
zusammengehörende Schachtelungstiefen zu identifizieren versuchen. Diese
Strategie könnte sogar Vorteile aufweisen weil der Codeeditor dann gar
kein Syntaxwissen bräuchte. Das steckt quasi der Entwickler durch seine
geschickte Einrückungsstrategie in das System rein.
Was ist die Quintessenz obiger Überlegungen. Mit keinem Stilmittel der physischen Kontextzusammenfassung allein, sei sie nun durch elementare Klammerungszeichen, Tag-Klammerung oder Einrueckungebenen des Quelltextes erreicht, lässt sich der Konflikt der Diskrepanz der semantischen Kontextzusammenfassung mit mitteln der syntaktischen Klammerung wirklich umgehen.
Aber im Arrangement entfalten sie vielleicht die gewünschte Wirkung.
Der letzte aus meiner Sicht notwendige Schritt waere dann noch nich nur ein einzelnes Intervall auf-und zuklappen zu koennen sondern gleich mehrere die sich dadurch auszeichnen einen zusammnegehoerigen Kontext zu bilden. Man haette dann sozusagen spezifische Sichten auf den Quellcode.
Heiko Künzel
So wie immer sind jetzt trotzdem noch Fehler drin. In der 1. Version hatte der WordPress Blog output die erläuternden Spitzen Klammern verschluckt. Deshalb hab ich sie durch deren Äquivalente „gt; und lt; ersetzt. Aber leider falsch herum 🙂