GoldEd 6 Studio - Testbericht von Thomas Aglassinger

Seit etlichen Jahren schon ist GoldEd einer der beliebtesten Texteditoren für den Amiga. Inzwischen steht uns die sechste Version ins Haus.

Grundlegendes

GoldEd ist ein Editor zum bearbeiten von reinen Texten in ASCII bzw. ISO Latin-1. Damit eignet er sich zum Erstellen von Quellcodes in diversen Programmiersprachen, bearbeiten von Befehldateien und kurzen, unformatierten Texten wie E-Mail, aber auch zum Erstellen von AmigaGuide- und HTML-Dokumenten.

Der Editor stellte über ARexx eine beachtliche Anzahl von Befehlen zur Verfügung. Diese kann man aber nicht nur über ARexx schicken, sondern auch Tasten und Menüs zuweisen. Natürlich ist das bei den gelieferten Voreinstellungen schon zur genüge gemacht worden, sodaß man ohne großes Herumkonfigurieren loslegen kann. Installer sei Dank.

Die Konfiguration geschieht nicht über kryptische Dateien, in die man unreflektiert abstruse Zeichenketten schreibt, sondern über komfortable Dialoge. Im Unterschied zu älteren Versionen ist es möglich, Konfigurationen zu kombinieren. So kann man sich z.B. eine Standardtastaturbelegung machen, um dann zum Bearbeiten von C-Programmen ein paar zusätzliche Tasten zu belegen. Ändert man jetzt in der Standardbelegung eine Taste, so hat das auch auf die C-Belegung diesielbe Auswirkung. Gleiches gilt natürlich auch für Menüs, Toolbars und viele andere Elemente.

"Pfui Gack - Fast wie Windows!"

Eine Sache, die viele Leute zu erschrecken scheint, ist, daß GoldEd sehr mit Windows kokettiert. Für die meisten Amiganer scheint sowas ideologisch nicht tragbar. Zwar war GoldEd schon immer eine Ansammlung von Zitaten aus verschiedenen Lagern: von MacOS kam z.B. das Piktogramm von GoldEd 4, und das "?"-Menü für die Hilfe gibt es noch immer. Dennoch nimmt inzwischen Windows ein Groß der Anspielung für sich in Kauf.

Anscheinend hat der Autor einem möglichst einfachen Weg gesucht zu haben, ein Amiga Produkt in die kommerziell interessanten Windows-Markt zu bringen, ohne die alte Amiga-Benutzerschaft zu entsorgen. Die Lösung sieht dann so aus: GoldEd läuft nur unter AmigaOS, hat aber eine Oberfläche, die in vielen Dingen der von Windows ähnelt. Dadurch soll es für Windows-Benutzer leichter sein, GoldEd unter einem Emulator wie UAE zu verwenden. Letzteres hört sich vielleicht etwas absurd an. Diverse Features von UAE, wie dem Zugriff des Emulators auf Windows-Dateien, könnten dieses aber erträglich machen. Zumindest mehr als das Windows-Notepad.

Nachdem ich gottlob einen echten Amiga verwende stand letzteres gar nicht zur Debatte. Man konnte aber kurz nach der Veröffentlichung von GoldEd 5 vieler Orts Gejammer über die Bastard-GUI hören. Inzwischen hat sich der Autor einiger dieser Probleme angenommen, insbesondere:

Ausschalten kann man die omnipräsenten, meist viel zu bunten und Platz fressenden Piktogramme in Listen und Dialogen

Ausschalten kann man das Context-Menu, das mittels der rechten Maustaste im Editorfenster kommt.

Eine Option läßt ein paar Eingabefelder wieder wie die alte GadTools aussehen. Die Hintergründe in Texteingabefeldern kann man auch auf grau statt weiß stellen.

Die krankhaft knalligen Toolbar-Piktogramme kann man pauschal in Graustufen zeichnen lassen. Oder ganz als Text darstellen.

Die Terminologie wie "Studio", "Service Pack", "Registry" etc ist zwar ungewohnt wenn man sonst überall "Magic", "Update" und "Preferences" hat, wirkt sich aber auf das praktische Arbeiten kaum aus.

Als sehr störend empfand ich nur, daß der Zwischenspeicher in Texteingabefeldern (wie in Windows) mittels Control-C und Control-V angesprochen wird. Bekanntlich unterstützt das GadTools-Feld normalerweise gar keinen Zwischenspeicher. De facto hat aber jeder ernsthafte Amiganer einen Patch ("EditHook") laufen, der diese Funktionen Styleguide-konform über Amiga-C und Amiga-V nachrüstet. So ein Patch funktioniert in GoldEd aber nicht, da das Eingabefeld Marke Eigenbau ist. Daher gibt es nur die inkonsistenten Tastaturkurzbefehle mittels Control-Taste. Und das kann einem leider an dem Rande des Wahnsinns treiben.

Im Vergleich: GadTools-alike und Windows-Emulation

Manche Dinge hingegen kann man ohne große Vorbehalte gut heißen: das Symbol zum ändern der Fenstergröße in Dialogen ist kleiner und nicht Teil des Rahmens, wodurch Fenster kompakter und ruhiger wirken. Die Toolbars kann man nach Lust und Laune durch Drag&Drop neu anordnen. In Fensterleisten finden sich oft zusätzliche Symbole: Ein "?" erlaubt es, durch klicken auf ein bestimmtes Feld eine kurze Hilfe zu erhalten (vgl. auch MUI, nur ist GoldEd hier weniger penetrant) . Ein "x" ermöglicht, einen Dialog auf den Bildschirm zu "kleben", sodaß er beim beenden durch "Ok" nicht geschlossen wird (Obwohl, für Windioten muß das furchtbar sein; die schließen ja normalerweise ein Fenster mit "x"). Viele GUI-Elemente wie Register und Listenbäume, die es im AmigaOS offiziell nicht gibt, werden in GoldEd reichlich verwendet, und erhöhen in der Regel den Bedienungskomfort.

Endlich kann bei den meisten Fenstern und Dialogen die Größe verändert werden. Wer einmal mit älteren Versionen gearbeitet hat, kennt das Gefühl: Da hat man angenehme 1024 Pixel Platz, und dann öffnet der Editor eine Liste auf 300 Pixel, in der man herumrollen kann wie Sissiphus zu seien besten Zeiten. Wie schreibt man den komischen Sissiphus wirklich? Angenehm auch, daß sich der Editor die Größe der Fenster merken kann. Weniger schön, daß er sich die Position nicht merkt, und beim nächsten mal das Fenster wider in der Mitte des Bildschirms daherkommt. (Das Problem betrifft natürlich nicht die Fenster zum bearbeiten des Textes, sondern nur die Dialoge für die Kommunikation mit dem Benutzer außerhalb des Textes.)

Dateitypen

Eine der angenehmsten Fähigkeiten ist die Unterstützung mehrere Dateitypen. Damit ist es dem Editor möglich, sich in bestimmte Dingen dem Text anzupassen. Dazu gehören das farbig Darstellen verschiedener Textteile (syntax coloring), Menüs und Tastaturbelegung, Toolbars und vieles mehr. Natürlich können verschiedene Dateitypen zugleich bearbeitet werden. Es ist sogar möglich, verschiedene Typen auf unterschiedlichen Bildschirmen zu haben. Praktisch ist es z.B., AmigaDOS-Skripten auf der Workbench zu bearbeiten, während C-Programme auf einem eigener Bildschirm erscheinen.

Ein Dateityp mit Toolbar und einem "Container" für die Kurzhilfe

Dateitypen gibt es für alles mögliche, z.B.:

C/C++. Für SAS/c und StormC sind erweiterte Umgebungen vorhanden, die eine bessere Integration mit dem Compiler erlauben.

ARexx. Die langerwartet Unterstützung wurde kürzlich nachgereicht. Da kommt Freude auf.

AmigaGuide. Erleichtert das Erstellen von Online-Hilfen ungemein. Meiner Meinung nach einer der gelungensten Modi.

Joyce, eine Rechtschreibkontrolle basierend auf dem weit verbreiteten ISpell. Eher nur für gut ausgerüstete Systeme, was aber in der Natur der Sache liegt. Unterstützt sowohl Deutsch als auch Englisch. Andere Sprachen kann man zwar einbinden, arten aber in obkure CLI-Spiele und Manpages aus.

HTML-Dokumente. Hier fand ich nur die Voreinstellung zu überladen und verspielt.

Ein Thesaurus, basierend auf dem Roget's Thesaurus aus dem Projekt Gutenberg. Nachdem das Ding über 100 Jahre alt ist, hat es heute nur mehr beschränkten Nutzen. Viele moderne Begriffe fehlen, dafür findet man etliche vorgeschlagene Wörter nicht einmal mehr im Webster's Dictionary.

Bis vor kurzem war die Erkennung von Dateitypen an Dummkonzepte wie MIME und Windows angelehnt: "Dateiendung rulez!". Für viele Dinge ist das unzureichend. Jetzt gibt es endlich auch erweiterte Regeln, die eine Datei nach bestimmten Zeilen oder Zeichen untersuchen können. Damit kann man nun endlich ARexx- und CLI-Skripte erkennen.

Eine Regel, um AmigaGuide Dokumente zu erkennen.

Neu ist auch der generic.parser. Dabei handelt es sich um einen Syntax Parser, bei dem man die "Grammatik" einer Programmiersprache über ein paar simple Dialoge einstellen kann. Das ist zwar nicht so flexible wie ein händisch "ausprogrammierter" Parser in C, aber dafür kinderleicht und für viele Zwecke ausreichend.

Eine neue Syntax ist schnell definiert. Hier die Struktur eines ARexx Programms.

Leider sind einige Features nicht in das Konzept der Dateitypen integriert, obwohl sie es sein sollten. Die Klammerüberprüfung zieht Escape-Sequence nicht in Betracht. Folgender C-Befehl z.B. liefert ein "Too many closing brackets":

printf("\"");

Gleiches gilt für sogenannte Scanner, die verwendet werden, um einen Text nach bestimmten Dingen zu durchsuchen. In einem C-Quellcode kann das eine Liste der deklarierten Funktionen sein, in einem Autodoc die einzelnen beschriebenen Seiten, in einem AmigaGuide-Dokument die Knoten.

Eine Funktionsliste, erstellt von einem externe Scanner

Schön ist, daß man mittels der Scanner ein Verzeichnis über mehrere Dateien hinweg anlegen kann (vgl. XRef). Anschließend kann man über Dateigrenzen hinweg Fundstellen anspringen. Der Editor erlangt damit praktisch Hypertext-Fähigkeiten. Leider wird dabei aber nur ein globaler "Name Space" unterstützt.

Zur Verdeutlichung ein Beispiel in Eiffel: wenn eine Klasse list.e und eine andere Klasse tree.e beide eine Routine remove haben, hat der Editor keine Ahnung, welche Funktion bei einem Aufruf wie sepp.remove(...) gemeint ist. Selbst dann nicht, wenn zwei Zeilen weiter oben die Deklaration sepp: LIST; steht. In Chaos-Sprachen wie C existiert dieses Problem natürlich nicht, weil sowieso alles in einem Name Space steht (was natürlich kein Pluspunkt dieser Sprache ist).

Weiters sind die Scanner für viele Dinge zu primitiv, weil immer nur genau eine Zeile sichtbar ist. So ist es unmöglich, einen größeren Zusammenhang aufzubauen. Infolge erkennt z.B. der Scanner für C-Funktionen nur Deklarationen, die einem bestimmten Stil entsprechen. Hier hilft manchmal nur das komplette neuformatieren mit einem Indent-Werkzeug (was dem Aufwand von einem Tastendruck entspricht). Für machen Dinge aber ist es schier unmöglich, einen Scanner zu schreiben (z.B. eine Eiffel Short Form), obwohl es ansich trivial wäre, einen kompletten Parser zu machen.

Blockoperationen

Blockoperationen sind massig vorhanden. So ist es möglich, Blöcke zeichen-, zeilen- oder spaltenweise zu markieren - wahlweise per Tastatur oder Maus. Mit der Maus muß nur die Shift- oder Alt-Taste gedrückt sein, um Zeilen oder Spalten zu wählen.

Außer Standardaufgaben wie Löschen, Kopieren und Verschieben von Blöcken kann man sie auch formatieren (recht/linksbündig, zentriert oder im Blocksatz), die Einrückung verändern, Texte in jeder Zeile des Blocks einfügen oder anhängen und einiges mehr. Zu guter letzt ist auch möglich, Dinge wie Suchen und Ersetzen nur auf den markierten Block anzuwenden.

Zur Verdeutlichung eine kleine Bildfolge, wie man einen Text in ein ARexx-Skript umwandelt, das ihn ausgibt:

Der Text, nichts als der reine Text, sowahr mir ISO 8859-1 helfe.

Block zeilenweise markieren (Shift + Linker Mausknopf)

Text in jeder Spalte des Blocks einfügen bzw. am Ende jeder Zeile anhängen (Menu "Block/Edit block/Insert text column" und "Block/Edit block/Append text")

Schon ganz gut. Aber halt: Großbuchstaben sind häßlich... Die müssen weg!

Leicht gemacht: vertikalen Block markieren (Alt + linker Mausknopf) und in Kleinschrift umwandeln (Menu "Block/Convert to lowercase")

Kommentar in erste Zeile, Speichern als ".rexx" - Voila!

Im Unterschied zu früheren Versionen kann GoldEd inzwischen auch mit vertikalen Blöcken so umgehen, wie man es erwartet. Nur beim Einfügen muß man aufpassen, daß man auch wirklich "Block/Clipboard · Paste/As column" anwählt.

Gewöhnungsbedürftig ist die Tatsache, daß es zwei verschiedene Blöcke gibt: einen im Editorfenster, und einem im Zwischenspeicher. Fast alle oben beschriebenen Operationen arbeiten mit ersterem, was sinnvoll ist, da er sichtbar ist und die Auswirkungen eines Befehls sofort am Bildschirm erkennbar sind. Letzterer ist in erster Linie für den Austausch von Daten mit anderen Anwendungen zuständig. Leider findet sich in diesem Zusammenhang eine der schlimmeren Styleguide-Affronts: Amiga-C kopiert nicht den Fensterblock in den Zwischenspeicher, sondern an die Cursorposition. Eine Kopie im Zwischenspeicher muß man stattdessen mit der hierfür obskuren Kombination Amiga-Y erzeugen.

Lästig: ein "Undo" löscht die Blockmarkierung. Und nach dem Kopieren ist immer noch der alte Block aktiv, anstatt die Kopie zu markieren. Das ist wenig sinnvoll, denn in der Regel will man die Kopie gleich weiterbearbeiten (z.B Einrückung ändern oder ein Wort im Block ersetzen).

Tabulatoren

Eines der großen Dramen rund um GoldEd war das der Tabulatoren. Inzwischen scheint der letzte Akt vorüber, und der Vorhang bleibt hoffentlich geschloßen.

Zu Zeiten von GoldEd 4 mußte sich der Autor wegen der fehlenden Unterstützung von Tabs des öfteren Wörter wie "Sturschädel" gefallen lassen. War es doch unmöglich, mit GoldEd Makefiles für "tolle" Werkzeuge wie GNUmake zu schreiben, die dann die Fehlermeldung

*** missing separator. Stop.

ausgeben, wenn eine Zeile mit einem Leerzeichen beginnt statt mit einem Tab. Am Bildschirm sieht ein Tab natürlich gleich aus wie ein Leerzeichen. Aber dafür sind ja die drei hübschen Sternderl in der Fehlermeldung da: damit man was hat, worüber man sich freuen kann. Soviel zum Thema Unix-Kultur.

Inzwischen unterstützt der Editor Tabs nicht nur laut Dokumentation, sondern auch in der Praxis. Wer in der Entwicklungsgeschichte (History) nachsieht, der merkt, daß es eine schwere Geburt war. Vor allem Parser und Scanner waren auf die Tabs nicht vorbereitet, und etliche Kleinigkeiten funktionierten auf einmal nicht mehr so wie sie sollten. Jetzt kann man aber endlich Zeilen eingeben wie:

[tab][tab]Alles[tab]bleibt wie [tab] es war.

Einziges Problem ist, daß die Tabulatoren-Konfiguration stimmen muß. GoldEd kann nämlich nach wie vor Tabs in Leerzeichen umwandeln und umgekehrt. Außerdem kann die Tab-Taste zum Herumspringen statt zum Einfügen von Tabulator verwendet werden. Und zu guter letzt kann man nicht nur eine fixe Tab-Größe einstellen, sondern Tabulatoren an bestimmten Spalten setzte. Das alles so hinzukriegen, wie man es haben will, ist nicht leicht. Aber möglich.

An dieser Stelle sei nur angemerkt, daß Konzept von Tabulatoren im ASCII-Text ein idiotisches ist. Das Grundproblem besteht darin, daß der Text per Definition WYSIWYG ist - jedes eingegebene Zeichen erscheint genau dort, wo es eingeben wurde. Tabulatoren entsprechen aber mehreren Zeichen, und es wird nirgends klar definiert, wievielen.

Das scheint auf den ersten Blick praktisch, weil sich dann jeder aussuchen kann, wie groß er seine Tabs haben will. Solange man das nur am Zeilenanfang macht, funktioniert es sogar halbwegs. Dies entspricht dann aber nicht mehr dem "physikalischen" WYSIWYG-Prinzip, sondern einem logischen Layout, daß der Benutzer jederzeit ändern kann. Wobei sich die Änderung auf den ganzen Text auswirkt.

Außerdem gibt es viele schlaue Editoren, die glauben, die Weisheit mit dem Löffel gefressen zu haben, und behaupten: "1 Tab = 8 Leerzeichen". Dann kommt aber der andere und sagt "1 Tab = 4 Leerzeichen". Und bumm, niemand kann mehr was lesen ohne den Text vollkommen neu zu formatieren.

Auf konzeptioneller Ebene ist dieses Problem gar nicht lösbar. Der auf lange Sicht einzig sinnvolle Weg ist, sich vom primitiven ASCII-Editor zu verabschieden, hin zum Strukturierten Editor, wobei hier natürlich auch die Programmiersprache angepaßt werden muß. Lesestoff für Interessierte gibt's bei [1].

Projektverwaltung? Kann man das essen, oder ist es ansteckend?

Wenn sich ein Editor plötzlich Studio nennt, dann will man meinen, daß er nicht nur hilft, einzelnen Texte zu erstellen, sondern auch, selbige zu verwalten. GoldEd hat zwar einige Features, die es erleichtern, mit mehreren Texten gleichzeitig herumzuwurschteln, von einer echten Projektverwaltung kann man aber nicht sprechen.

Zum einen kann man Sitzungen ("Sessions") speichern, die sich alle Dateinamen merken, die zur Zeit im Speicher sind. Beim Start kann man dann den Namen der Session als Parameter angeben, und alle Dateien werden geladen. Über Inhalt und Funktion der Dateien wird dabei aber nirgends reflektiert.

Einen anderen Weg geht das Explorer-Plugin. Es durchsucht einfach ganze Verzeichnisse nach Dateien mit bestimmten Namensmustern und führt sie in einer Liste am Bildschirmrand an. Die Anname dabei ist, das alle Datei eines Musters wichtig sind, und alle anderen nicht.

Der Explorer zeigt am rechten Rand alle HTML-Dateien an. Wahlweise kann man sich auch GIF- und JPEG-Bilder aufführen lassen.

Durch Klick auf einen Namen wird der Text geöffnet. Manchmal gibt es noch weitere Operationen über Alt-Klick. Im HTML-Modus kann man damit z.B. einen Link auf die angeklickte Datei in den Text einfügen. Das ist dann aber auch schon alles. Weniger angenehm: Jedes Fenster kriegt seinen eigenen Explorer, der dann zig-mal Platz wegnimmt. Der Umstand, daß ein Iconify zu einem Toolbar-Knopf möglich ist tröstet nur bedingt.

Für's Compilieren u.Ä. gibt es in den meisten Dateitypen einen "Make"-Knopf. Der ist mit dem Befehl PROJECT MAKE belegt, den man wiederum in einem eigene Dialog mit einem Makro belegen kann. Dort kann man auch Dateien angeben, die zum Projekt gehören.

Der Zusammenhang zwischen Session und Projekt ist nicht ganz klar. Beide scheinen eine ähnliche Funktion anzustreben, ohne sie wirklich zu implementieren. Die Dokumentation erklärt, daß externe Projektverwaltungs-Werkzeuge die im Projekt enthaltenen Dateien abfragen können. Das manuelle Verwalten dieser Liste und das offensichtliche Fehlen von externen Werkzeugen zwingen einem aber fast zu Un-Programmen wie make, die sich dann um den ganzen Humbug im Editor erste recht wieder nicht kümmern.

Zur Verteidigung muß aber auch gesagt werden, daß es nirgendwo etwas Vernünftiges zur Projektverwaltung zu geben scheint. Entweder findet man ein chaotisches Chaos aus 65432 verschiedene Skripten in mindestens ebenso vielen Skriptsprachen vor, oder man hat inflexible Werkzeuge, die meist nur mit eine Sprache oder gar nur einem Compiler von einem Hersteller zusammenarbeiten. So gesehen ist das, was GoldEd hier liefert, nicht schlimmer und unzufriedenstellender als anderswo.

Entwicklerspielzeug

GoldEd bietet etliche öffentliche und dokumentierte Schnittstellen, an denen die Funktionalität leicht erweitert werden kann. Im Pakte enthalten sind etliche Beispiele, Skripten, Includes und Autodocs. Das meiste Material richtet sich an C-Programmierer und verwendet DICE als Compiler, dessen Vollversion es wie berichtet als Freeware im Aminet gibt Link zu deinem DICE Artikel .

Damit kann man eigene Scanner, Syntaxparser, API-Erweiterungen usw. schreiben. Fortgeschrittene Kenntnisse zum Thema "ARexx in C" und "Library Programmierung" sind hier aber praktisch Voraussetzung. Das meiste spielt sich auf einem ziemlich tiefen Level ab, was aber in der Natur der Sache liegt. Für den "Normalverbraucher" gibt es ohnehin Dinge wie den generic.parser, ARexx-Befehle, Templates und Makros, die für viele Zwecke ausreichend sind.

Ein "Wrapper" hilft, das gesammelte Material zu verpacken und zusammen mit einem Installer Skript als neuen Dateityp für andere zugänglich zu machen. Die Sache läuft zwar nicht vollautomatisch ab, erleichtert den Prozeß aber dennoch.

Überzeugend ist hier das offene Konzept, daß dennoch nicht sehr zu Lasten der Arbeitsgeschwindigkeit geht.

Motz, raunz, suder

Manch einer stört sich vielleicht an folgenden Dingen:

Es gibt nur eine Ansicht pro Text. Man kann nicht einen Text ein zweites mal laden, und dann an verschiedenen Stellen bearbeiten, wobei auch die Kopie geändert wird. Das sollte kein großes Problem sein, weil man Texte falten kann und man Lesezeichen setzen und wieder anspringen kann. Und das unabsichtliche zweifache Laden weiß der Editor in der Regel zu verhindern.

Manche Leute glauben, daß Text- und Hex-Editor ein und dasselbe Programm sein sollen. Diese werden mit GoldEd nicht glücklich, weil er eine beschränkte Zeilenlänge von 999 Zeichen hat, automatisches Ersetzen von CR/LF in PC-Texten machen kann und Leerzeichen am Ende der Zeile automatisch wegläßt.

Oft lästig sein kann der Umstand, daß "Undo" nicht zeichenweise funktioniert, sondern mehr oder weniger die ganze Zeile wieder herstellt.

Die Standardtastaturbelegung kann einem leicht zu Schreikrämpfen reizen. "Undo" muß z.B. auf Amiga-8 liegen. Weil auf Amiga-U liegt bereits "Absatz linksbündig ausrichten" - wo auch sonst? Und Control-Right bewegt nicht den Cursor wortweise, sondern will einen Block nach rechts verschieben. Eine der Funktionen, die man sehr selten braucht. Die Help-Taste darf natürlich nicht die Hilfe zeigen, sondern wird zum Falten benutzt. Amiga-C wurde ja bereits "gewürdigt", und man könnte hier endlos weiterlamentieren. Dazu reicht aber der Platz nicht.

Vertrieb und Support

Erhältlich ist das Programm beim Autor selbst bzw. neuerdings über einen Vetriebspartner. In der Regel also über den Postweg. Ein paar Tage nach der Bestellung findet sich dann ein Kuvert im Briefkasten, das eine selbstgebrannte CD-ROM in einer ziemlich schnörkellosen Hülle enthält. Gedruckte Dokumentation gibt es keine, die Benutzung wird in einem etwa 250K großen AmigaGuide erläutert. Sowohl die Dokumentation als auch die Oberfläche sind in Deutsch und Englisch vorhanden. Das Manual erklärt in kompakter Form die Bedienung und die einzelnen Menüs und Dialoge. Weitere Hilfe kriegt man oft über den "?"-Knopf im Fensterrahmen.

Unzureichend finde ich nur die Beschreibung mancher ARexx-Befehle. Worin genau der Unterschied zwischen QUERY LINE und QUERY ABSLINE besteht wird nicht wirklich erläutert. Verschlimmert wird das ganze noch durch den oft extrem chaotischen Aufbau der Befehlsstruktur. So gibt es z.B. einen OPEN Befehl, der eine neue Datei lädt. Oft will man aber, das eine Datei nur dann geladen wird, wenn sie noch nicht im Speicher ist; ansonsten soll einfach das richtige Fenster aktiviert werden. Das geht mit WINDOW FORCE USE=dateiname, wird aber bei OPEN nirgends erwähnt.

Support gibt es per E-Mail, Telefon und FAX. Meiner Erfahrung nach gibt es hier nicht viel zu bemängeln. Fragen werden prompt beantwortet. Bei Bug-Reports, die für den Autor nachvollziehbar sind, findet sich in der Regel nach ein paar Tagen ein neuer Service Pack im Netz (Beschreibung des Systems, Anweisung zum Reproduzieren, etwaige Enforcer-Hits usw. sollte man natürlich mitschicken). Die eine oder andere kleine Feature-Nachfrage geht auch manchmal durch, Wunder darf man sich natürlich keine Erwarten. Die Weiterentwicklung von GoldEd war seit Version 5 eher eine stetige - was ja nichts Negatives ist, wenn es um Stabilität geht.

Der Preis von DM 100 (90+10 Porto) scheint für einen Editor vergleichsweise hoch. Man muß aber auch in Betracht ziehen, daß anderen kommerziellen Produkte in dieser Klasse nur einen Bruchteil der Funktionalität offerieren. So gesehen halte ich den Preis für durchaus akzeptabel.

Kopierschutz gibt es keinen, außer einem Keyfile auf der CD. Dieses wird beim installieren eines Service Packs überprüft, weshalb der Installer jedesmal um die CD bittet. Da diese Prozedur selten nötig ist, stört das aber nicht wirklich. Witziges Detail: Das Keyfile ist 64MB groß, was das Raubkopieren etwas erschweren sollte - zumindest für die Modem-Wabbler.

Neue Versionen des Programms und der Dateitypen des Autors gibt es zum freien Download auf der GoldEd Homepage. Von dort kriegt man auch eine Demo-Version. Im Aminet finden sich einige Erweiterungen anderer Leute. Hier ist etwas Vorsicht geboten, weil vieles davon nur mit GoldEd 4 läuft. Der Installer erkennt solche Probleme in der Regel aber, und ein Blick in die README wirkt oft auch Wunder.

Fazit

GoldEd ist ein feiner Editor, auch wenn das nach meinen Schilderungen vielleicht nicht sofort erkennbar ist. Viele der kritischen Bemerkungen haben sich auf Details bezogen. Mit kleinen Problemen läßt sich meist besser leben, als wenn die Funktionalität gar nicht vorhanden wäre - wie bei vielen anderen Editoren. Bemerkenswert ist die hohe Flexibilität und Erweiterbarkeit, die dennoch keine gravierenden Auswirkungen auf die Geschwindigkeit und den Resource-Verbrauch hat. Man nimmt nur das, was man braucht - die Antithese zu EMACS sozusagen.

Ein größeres Redesign bietet sich bei den Scannern an. Die in horrender Zahl vorhandenen Inkonsistenzen (vor allem in der Namensvergabe der ARexx-Befehle und der Benuteroberfläche) werden für 68k-Amigas wohl nicht mehr behoben. Hoffentlich aber dann, wenn GoldEd irgendwann einmal auf einem ganzen anderen System rauskommt (welchem auch immer). Denn dann gibt es keine Entschuldigung mehr wie die nicht zu verärgernde existierende Benutzerschaft, die langjährige, schwer vorauszusagende Weiterentwicklung oder fehlende bzw. veralterte Styleguides.

Alles in allem und in Anbetracht potentieller Alternativen kann man GoldEd für Amiga-Programmierer ziemlich uneingeschränkt empfehlen. Und auch der ernsthafte Anwender sollte damit seine Freude haben. Für's gelegentlich Bearbeiten der Startup-Sequence aber bleibt man besser bei den Bordmittel der Workbench, ed und memacs. Die kosten nämlich nichts.

Bedienung
Features
Qualität
Preis/Leistung
Stabilität
Dokumentation
Gesamt

Thomas Aglassinger
N/A

http://members.tripod.com/golded/ - GoldEd Homepage; bietet auch eine Demoversion

SAS/c Dateityp - Für das Volk

ARexx Dateityp - lang hat's gedauert, aber jetzt ist er da

Joyce - die Rechtschreibkontrolle

Installer Dateityp - überprüft automatisch die Schachtelung der Klammern

Eiffel Dateityp - was es noch nicht gibt, bastelt man sich selbst

[1] Mössenböck, H. & Koskimies, K. 1996. Active Text for Structuring and Understanding Source Code, Software Practice Experience. Vol. 26, no. 7, 833-850.