Ein nicht zu vernachlässigender Faktor im »Ökosystem« einer Programmiersprache ist die Unterstützung durch Editoren – ist es doch diese Komponente, in der die meiste Arbeit erledigt wird. Für REXX ist die Situation da leider nicht optimal, zumindest soweit ich sie bisher erkundet habe. Es soll zunächst eine kurze Information zu jEdit (http://www.jedit.org) geben.
jEdit kennt einen Dateityp »objectrexx«. Dieser leistet Syntaxhervorhebung für REXX-Dateien, allerdings recht unvollständig. Zum Beispiel wird bei Kommentaren die Schachtelung nicht beachtet; viele Schlüsselwörter werden nicht hervorgehoben (anscheinend die abhängigen Schlüsselwörter, die nur dann als Schlüsselwörter gelten, wenn ein anderes Schlüsselwort vorausgeht). Kleine Probleme gibt es auch, wenn es darum geht, das Ende einer Zeichenkette zu bestimmen.
Automatische Einrückungen werden im Modus »objectrexx« zum Großteil sinnvoll vorgenommen. Das ist sehr angenehm.
Mit Hilfe der jEdit-Erweiterung CtagsSideKick gelingt eine rudimentäre Auflistung der Unterprogramme, sodass man per Mausklick dorthin navigieren kann. Diese Lösung basiert auf ctags, das zurzeit wohl noch keine mit ::routine definierten Unterprogramme listen kann. Das ist schade. Dazu kommt, dass bei komplexeren Programmen die Unterprogrammliste einfach nicht mehr angezeigt wird. Ich vermute, dass das ein Problem in CtagsSideKick ist, denn vim kann die Liste basierend auf dem gleichen ctags durchaus anzeigen.
Trotz der genannten Probleme ist jEdit trotzdem eine brauchbare Lösung zur Erstellung von REXX-Programmen.
Posts mit dem Label jEdit werden angezeigt. Alle Posts anzeigen
Posts mit dem Label jEdit werden angezeigt. Alle Posts anzeigen
Mittwoch, 13. August 2014
Samstag, 6. Juni 2009
jEdit und Speicherverbrauch
Wenn man jEdit unter Windows XP und Java 6 betreibt, kann es vorkommen, dass der Speicherverbrauch sprunghaft ansteigt, nachdem der Bildschirmschoner aktiv war. Ich vermute, dass die JVM durch den Bildschirmschoner gezwungen wird, den Fensterinhalt im eigenen Speicher zu puffern. Wenn der Schirm dann eine große Auflösung hat, kommt da schon was zusammen.
Um dieses Problem zu lösen, habe ich folgende Java-Option in das Kommando aufgenommen, das jEdit startet: -Dsun.java2d.noddraw=true
Das erhöht zwar den Speicherverbrauch von Anfang an, verhindert aber die extreme Steigerung durch den Bildschirmschoner, sodass insgesamt weniger Speicher verbraucht wird.
Um dieses Problem zu lösen, habe ich folgende Java-Option in das Kommando aufgenommen, das jEdit startet: -Dsun.java2d.noddraw=true
Das erhöht zwar den Speicherverbrauch von Anfang an, verhindert aber die extreme Steigerung durch den Bildschirmschoner, sodass insgesamt weniger Speicher verbraucht wird.
Abonnieren
Posts (Atom)