Re: PHP IDE, Editor

Thomas 'PointedEars' Lahn schrieb:

Somit kaeme von vornherein nur eine IDE in Frage, die es
erlaubt, den Code in eigenstaendigen xterms mit frei
definierbarem Editor zu oeffnen - und das widerspricht
natuerlich dem Grundkonzept einer _I_DE.
Ergo bleibe ich bei meinen selbst zusammengestoppelten
Werkzeugen und bin soweit ganz zufrieden damit.
xterm bzw. konsole verwende ich nur für (ba)sh-Scripts, für alles
andere in den meisten Fällen Eclipse. Mehrere xterms/konsolen
finde ich unübersichtlich; vielleicht solltest Du Dir mal
screen(1) anschauen.
Ich kenne screen recht gut, da ich es fuer alle Verbindungen zu
externen Servern (d.h. insbesondere zum Schreiben von Mail und News)
verwende, um Verbindungsabbrueche abfangen zu koennen. Die Idee
mehrerer Sitzungen in _einem_ Fenster ist fuer mich der reinste
Alptraum. Ich benoetige einen grossen Bildschirm und viele Fenster,
gerne auch ueberlappend (die Entdeckung von focus follows mouse war
in den fruehen 90ern eine wahre Sternstunde fuer mich).

YMMV. Du kannst screen-Fenstern aber auch Namen geben (bzw. automatisch geben lassen), oder sich sogar einen Bildschirm teilen lassen. Dann wird
es übersichtlicher. IMHO sollte man unbedingt in der .screenrc eine feste Statusleiste definieren, damit man gleich sieht, welche Fenster (mit welchem Namen) offen sind und welches aktiv ist.

Falls man denn mehr als eines verwendet. Ich habe immer exakt ein aktives Fenster, dass den kompletten Monitor beansprucht. :D

Meine Frage zielte aber nicht auf einen allgemeinen Vergleich
zwischen Editoren/IDEs oder gar ein irrationales Bauchgefühl hin,
sondern auf definitive Kriterien, welche einen Editor *für PHP*
geeigneter erscheinen lassen als einen anderen.
Ich glaube, fuer die meisten Autoren werden Dinge wie das
Bauchgefuehl beim Editor viel ausschlaggebender sein, als (fast)
alle objektiven Kriterien.

Das wäre schade, denn durch diese Irrationalität würde so manche Perle übersehen.

Das stimmt wohl. Es gibt aber auch erstaunlich geringe Anforderungen, die so manch Editor oder IDE nicht erfüllt. Es überrascht mich immer wieder, wie wenig Editoren in der Lage sind, beim Tippen eines Tabulators diesen durch Leerzeichen zu ersetzen.

Bei mir fallen die meisten IDEs und Editoren wegen einer Kleinigkeit durch: Wenn ich eine neue Datei öffne, möchte ich eine neue Datei. Tatsächlich werde ich aber regelmäßig mit Dialogen begrüßt, die mich nach Dateityp, Dateinamen und anderen befragen - alles Dinge, die ich an dieser Stelle nicht wollte. Ich wollte eine neuen Schreib"buffer". ;)

Die aus der Oberfläche heraus nachinstallierbaren Plugins für diverse Programmiersprachen und Anwendungsgebiete integrieren sich nahtlos in die Eclipse-Plattform. Es ist immer dasselbe Look & Feel, nur das eine Editor-
Plugin kann manchmal etwas, was das andere nicht kann, weil es nur für die Sprache(n), die dieses Plugin unterstützt, nötig ist. EPIC kann z. B. Perl::Critic per <Ctrl>+<Shift>+<C> (default) aufrufen und die entsprechenden Markierungen setzen; bei PDT wäre das gänzlich überflüssig. Also *keine* Extrawürste.

Zumindest das dürfte sich bei NetBeans ähnlich verhalten.

Ich persönlich finde es meist suboptiomal, wenn IDEs die persönliche Tool-Chain ersetzen sollen. Ich bevorzuge Editoren, die sich per Projekt so einstellen lassen, dass sie z.b. Beispiel mit dem Klick auf "speichern" Testfälle ausgeführt werden, Dokumentationen aktualisieren und so weiter.

Je nach Projekt können die notwendigen Tools zum Teil stark divergieren. So können andere Code-Repositories verwendet werden, unterschiedliche Bugtracker, Testfälle, Sprachen, Datenbanken, Organisationsgrundlagen, Dokumentationsformen und so weiter. Als ich zuletzt einen Blick auf IDEs warf, waren sie nicht mal ansatzweise in der Lage, dies (auf Projektbasis) abzubilden.

Es muss ja beispielsweise einen triftigen Grund gehabt haben,
weshalb Ulf schrieb "*endlich* weg von Eclipse!" und nicht bloss
"mir gefällt Netbeans gut/besser als Eclipse, weil …".
Ja: "Die Usability/Nutzbarkeit der IDE entspricht nicht meiner
Vorstellung vom bequemen Arbeiten", was aber letztlich auch nichts
anderes ist, als "gefaellt mir nicht", und das vermutlich ganz
unabhaengig von PHP.

Zumindest liesse sich Usability quantifizieren (z. B. durch die Anzahl der nötigen Arbeitsschritte, um eine bestimmte häufige Aufgabe zu erledigen);
"gefällt nicht" hingegen nicht.

Mit ein wenig Selbstreflexion läßt sich das "gefällt nicht" zumindest hinreichend quantifizieren.

Mir ist zum Beispiel wichtig, dass ich es mit freier Software zu
tun habe, dass meine IDE sehr kompatibel, flexibel und innovativ
ist
Flexibel ist klar - das will man sowieso haben.

Nur um das zu verdeutlichen, da ich nicht weiss, ob wir hier beide dasselbe meinen: Mit flexibel meine ich hier unter anderem, dass ich so gut wie alle Elemente der Oberfläche beliebig anordnen kann. Wenn ich gerade keinen Projekt/PHP-Explorer brauche, minimiere ich ihn, damit mehr Platz für die Quelltextansicht und den Outline View bleibt. Brauche ich den Quelltext im Vollbild, genügt ein Doppelklick auf den Editor-Tab (oder Maximize im Kontextmenü) und ein weiterer um alles in den alten Zustand zu bringen. Muss ich an zwei weit entfernten Stellen einer Datei etwas gleichzeitig bearbeiten, wähle ich einfach "New Editor" und schiebe mir den zweiten Editor-View dorthin, wo ich möchte. Mehr Platz für die Problemliste? Kein Problem, ein bisschen am Rand des Views ziehen und der Rest der Oberfläche gibt den benötigten Platz frei. Und RegExps muss ich nicht ständig testen, daher reicht dafür ein Fast View (hat zum Auslösen einen Button in der Statusleiste; legt sich über die anderen Views und verschwindet automatisch, wenn ich ihn nicht mehr brauche).

Deine Aufzählung von Flexibilität ist eher eine Aufzählung deiner typischen Arbeitsweise und daher benötigten Features. Ad hoc stelle ich fest, dass ich keines davon auch nur ansatzweise regelmäßig benötige.

Kompatibel: zu was?

Betrübssystemen. Auf dem Büro-Desktop muss ich Windows 7 verwenden, zuhause und mit dem Notebook bleibe ich bei Debian GNU/Linux. Da ist es gut, wenn ich zur Not das unter Windows erstellte Eclipse-Projekt per USB-Stick/VPN in meinen Linux-Workspace importieren kann und umgekehrt bzw. mit wenigen Anpassungen komplette Workspaces ins andere System übernehmen kann.

Nicht mit der notwendigen Arbeitsumgebung ausgestattet zu sein, ist für mich ein Kündigungsgrund. Ich halte die freie Wahl meiner Arbeitsumgebung - soweit es sich mit der Firmenstruktur vereinbaren läßt - in meinen Arbeitsvertrag fest.

Gruß,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8 verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse auswerten kann.
.

Relevant Pages

  • Re: PHP IDE, Editor
    ... da ich es fuer alle Verbindungen zu ... welche einen Editor *für PHP* ... Flexibel ist klar - das will man sowieso haben. ...
    (de.comp.lang.php)
  • Re: Empfehlung fuer Linux-Einsteigerseite?
    ... ich keinen Editor mehr anfassen, der nicht mit UTF-8 umgehen kann. ... fuer Config files magst du Recht haben. ... dass Umlaute nirgends "einfach so" funktionieren. ... Schon Unicode ist nicht immer UTF8 und selbst UTF8 hat ASCII nicht ...
    (de.comp.os.unix.linux.misc)
  • Re: ssh Verbindung mit einem Skript
    ... gewaehlten Editor aufrufen. ... Ich dachte mein Hinweis haette fuer die nahe- ... dass das erste entsprechende Programm ... Default" fuer den Editor ist, ...
    (de.comp.os.unix.linux.misc)
  • Re: PHP IDE, Editor
    ... _einem_ Fenster ist fuer mich der reinste Alptraum. ... Bauchgefuehl beim Editor viel ausschlaggebender sein, ... Editor starte, um sie zu bearbeiten. ...
    (de.comp.lang.php)
  • Re: Child window aus einer Bibliothek erzeugen
    ... ob die umgebende Anwendung einen MDI-Rahmen bereit stellt (da ... Ein "aktives Fenster" ist für mich dann dadurch visualisiert, ... Dieser Editor soll nun in die Anwendung integriert ... unabhängige Bibliothek zu realisieren. ...
    (microsoft.public.de.vc)