Peppy -- an XEmacs-like editor in Python. Eventually.

[Leonidas]

Für alle die einen mächtigen Editor suchen, aber nicht ganz von Emacs oder Vim überzeugt sind, für die könnte peppy nun eine Alternative sein. Habe es bisher aber nicht ausprobiert.

[sma]

Hm, ich bin ja bei all diesen Editor, die auf scintilla basieren, sehr skeptisch, weil dieses Rahmenwerk die Möglichkeiten stark limitiert und gleichzeitig wenig erweiterbar ist. Der Weg von TextMate oder vi, schachtelbare reguläre Ausdrücke zu benutzen, ist einfacher und mächtiger als nur aus einem Set von vordefinierten Lexern etwas auszuwählen und dann ein paar Farben einstellen zu können. Wirklich guten Sprachsupport bekommt man zudem nur, wenn man die Sprache versteht und statt syntaktischem ein semantisches Highlighting macht (wie es bei Java-IDEs inzwischen Standard ist). So erwarte ich von einer guten Python-IDE, dass sie mir etwa unbenutzte lokale Variablen markiert - vielleicht sogar unbenutzte Imports (was glaube ich aber nicht eindeutlich feststellbar ist).

peppy soll aber wohl ein Editor in Python und nicht unbedingt ein Editor für Python sein.

Stefan

[BlackJack]

Unbenutzte lokale Namen sind auch nicht eindeutig feststellbar, man könnte ja immer noch über ``locals()['foo']`` drauf zugreifen. Oder gar über Stackrahmen von einer aufgerufenen Funktion.

PyDev kann die Ausgabe von `pylint` nutzen um dessen Fehlermeldungen oder Warnungen im Editor an den entsprechenden Stellen an zu zeigen.

[Leonidas]

Der Weg von TextMate oder vi, schachtelbare reguläre Ausdrücke zu benutzen, ist einfacher und mächtiger als nur aus einem Set von vordefinierten Lexern etwas auszuwählen und dann ein paar Farben einstellen zu können.

Da kommt man auch irgendwann an die Grenzen. Ich editiere Django Templates und da dreht der Vim-Highlighter bei eingebettetem JavaScript fast komplett durch, dass er entweder alles einfarbig macht, nichts highlightet oder es abschnittsweise highlightet.

Bin jetzt gerade dabei für solche Templates auf Emacs umzustellen, dort gibt es MuMaMo, welches den Major-Mode wechselt, je nachdem welcher Teil editiert wird. Leider friert es Emacs bei einigen Dateien ein, der Autor scheint aber schnell zu reagieren. Mal sehen.

Mehrere Sprachen auf einmal mit einem Lexer zu erfassen ist so oder so keine gute Idee.

Und für alle die sich Emacs oder Vim in vereinfacht wünschen gibt es ja immer noch PIDA, Cream und den CUA-Mode vom Emacs

[sma]

Mehrere Sprachen auf einmal mit einem Lexer zu erfassen ist so oder so keine gute Idee.

Lexer sind keine gute Idee. Wer mehrere Sprachen kombinieren will, fährt mit Parsing Expression Grammars (PEGs) besser. Meines Wissen baut allerdings bislang kein Editor auf diesem Prinzip auf, auch wenn die verschachtelbaren REs von vi oder TextMate ähnlich sind.

Und irgendwie muss der Editor damit klarkommen, dass man verschiedene Sprachen in einer Datei benutzt, das ist nun mal die Realität.

Stefan

[lunar]

Lexer sind keine gute Idee.

Wieso? Wenn man Lexer verschachteln kann, und je nach aktuellem Codestück andere Lexer anwenden kann, kommt man doch auch mit Lexern zurande, oder sehe ich das gerade falsch?

[sma]

Lexer sind keine gute Idee.

Wieso? Wenn man Lexer verschachteln kann, und je nach aktuellem Codestück andere Lexer anwenden kann, kommt man doch auch mit Lexern zurande, oder sehe ich das gerade falsch?

Ich definiere Lexer als ein Programm, welches einen Strom von Zeichen nimmt und einen Strom von Token liefert. Was der Lexer einmal gelesen hat, dass steht nicht mehr zur Verfügung. Nun stelle man sich eine Sprache vor, in der ein Zeichen am Zeilenende vorgibt, wie der Text davor zu zerteilen ist. Diese Aufgabe kann kein Lexer alleine ohne semantische Regeln erfüllen. Das mächtigere Konzept ist daher, direkt den Parser auf den Zeichenstrom anzusetzen, und den Optimierungsschritt, Zeichenfolgen erst zu Token zu machen, damit's der Parser einfacherer hat, wegzulassen. Andernfalls braucht der Lexer einen unbegrenzten Lookahead, etwas, dass man in der Praxis nicht haben will.

Stefan