Syntax-Highlighting in Browser-Textarea

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Syntax-Highlighting in Browser-Textarea

Beitragvon sma » Sonntag 1. Juni 2008, 11:16

Ich glaube daran, dass IDEs früher oder später browserbasiert sein werden. Kernstück einer klassischen IDE ist der Texteditor und hier erwartet man farbliche Syntaxhervorhebung. Hat jemand so etwas schon mal gebaut? Es gibt ein paar Ansätze, doch nix funktioniert richtig - zumindest nicht in Safari.

Das HTML-textarea ist zugegeben primitiv. Was tun?

Ein naiver Ansatz ist, alles mit JavaScript selbst zu machen und nach jedem Tastendruck einen String passend zusammenzubauen, dann Einfärbungen durch Hinzufügen von HTML-Tags zu machen, an der richtigen Stelle noch ein Bild für den Cursor einzufügen und dann das ganze einem <div> als `innerHTML` zuzuweisen, um den "Editor" dazustellen.

Das funktioniert, ist aber bereits nach wenigen Zeilen extrem langsam. Zudem weiß ich nicht, ob es möglich ist, etwas mit der Maus zu selektieren. Bekommt man die Events mit und kann die normale Selektionsfunktion des Browsers überschreiben?

Ein anderer Ansatz, der wohl von CodePress verfolgt wird ist, den "WYSIWYG"-Modus (der leider in jedem Browser etwas anders funktioniert und einem total kaputten Hack vom IE folgt) zu benutzen. Man bekommt dadurch die Bearbeitung von Text inklusive Selektion geschenkt, muss aber damit umgehen, das Anwender beliebiges HTML in den Text per Zwischenablage einfügen können. Das Einfärben muss nach jedem Tastendruck immer wieder passieren und geht man ähnlich naiv wie oben beschrieben vor, ist das ebenfalls langsam.

Größtes Problem ist aber, dass die CodePress-Demo im Safari einfach gar nicht geht.

EditArea scheint trickreich ein <textarea> mit normalem HTML zu überlagen und dort jeweils den aktuellen Inhalt des Eingabefelds in Farbe nachzuvollziehen. Interessant und funktioniert auch mit Safari, doch es gibt zwei Selektionen - die des Browsers in dem überlagerten HTML und die im Eingabefeld. Sehr verwirrend. Zudem scheint EditArea das Syntaxhighlighting in der aktuellen Zeile jeweils abzuschalten - vielleicht aus Performance-Gründen - ich finde das jedenfalls häßlich.

Mir scheint der beste, aber wohl auch aufwendigste Ansatz der, einen Editor direkt basierend auf dem DOM zu bauen, um das ständige neue Parsen beim Zuweisen eines Strings an `innerHTML` zu vermeiden. Ich habe den Nachbau eines Emacs und eines vi in JavaScript gefunden, die möglicherweise so vorgehen. Beide funktionierten nicht unter Safari. Ich glaube jedoch, beim Emacs-Clone liegt das daran, dass Webkit relativ streng in der Auslegung ist, wie Keyboard-Events zu funktionieren haben und sich der Autor wohl mittels trial-and-error die fehlerhaften Umsetzung von Mozilla erarbeitet hat. Beide Editoren haben den Vorteil, dass sie keine Maus-Selektion brauchen.

Die Rails-IDE Heroku scheint einen Editor zu haben so wie ich mir das vorstelle - wie der realisiert ist, kann ich nur raten, da sie nur ein Video aber keinen Code zeigen. Allerdings haben die Jungs auch $3,000,000 Risikokapital bekommen und dann ist es ja wohl locker drin, sich da einen eigenen Editor zu bauen. Vielleicht ist das ja auch eine Flash-Komponente?

Es gibt noch einen längeren Aufsatz von jemandem, der den Weg der DOM-Manipulation gegangen ist und der klagt über Unterschiede zwischen den Browsern. Er benutzt einen inkrementellen JavaScript-Parser mit Continuations für das Einfärben (er kann nur JavaScript) was meinen Respekt verdient, doch der Quelltext ist umfangreich und nicht verlockend, studiert zu werden. EditArea ist auch unglaublich groß und es will mir nicht in den Kopf, dass man dafür soviel Code brauchen soll.

Lasse ich das Einfärben weg und nutze ein <pre> als Container, dann habe ich folgenden DOM:

Code: Alles auswählen

<pre id='editor'>...<span id='cursor'>...</span>...</pre>

Der PRE-Knoten hat drei Kinder, Ein Text-Knoten (kann leer sein oder fehlen, wenn Cursor am Textanfang ist) für den Text vor dem Cursor, ein SPAN-Knoten mit einem optionalen Text für die Selektion und einem weiteren Text-Knoten für das, was dem Cursor folgt.

Möglicherweise ist es effizienter, pro Zeile einen Text-Knoten zu benutzen und dann die Zeilen mit BR-Knoten zu trennen. Innerhalb einer Zeile könnte ich dann nach wie vor `innerHTML` benutzen, um das Syntax-Highlighting zu realisieren und muss nicht weitere SPAN-Knoten erzeugen.

Die Cursorposition speichert man entweder als Index vom Anfang des Texts oder als Paar aus Zeile und Spalte. Zu einer Cursorposition muss man dann den passenden DOM-Knoten und den Offset im Text des Knotens bestimmen. Grundoperationen sind das Einfügen eines Zeichens, Einfügen eines Zeilenumbruchs, Löschen eines Zeichens, Löschen eines Zeilenumbruchs und das Setzen des Cursors. Kann man auch eine Selektion aufspannen, so muss man damit klarkommen, dass diese mehrere Zeilen überspannen kann.

Am einfachsten scheint mir, wenn man parallel zu den DOM-Knoten nochmals den Text als einfache Strings vorhält, um darauf schneller das Syntax-Highlighting durchzuführen. Idealerweise erkennt man irgendwie, dass Text schon korrekt eingefärbt ist und macht dann nichts.

Ich habe keine Zeit mehr, aber falls jemand da noch weitere Informationen hat, würde ich mich freuen. Vielleicht komme ich heute Abend mal dazu, den überlegten Ansatz auszuprobieren.

Stefan
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon mitsuhiko » Sonntag 1. Juni 2008, 13:12

sma hat geschrieben:Ich glaube daran, dass IDEs früher oder später browserbasiert sein werden.

Hier hab ich aufgehört zu lesen. Was du suchst gibt es in CodePress und was besseres wirst du nicht bekommen weil die JavaScript APIs momentan keine Alternative zulassen.

Warum muss den alles in den Browser?
TUFKAB – the user formerly known as blackbird
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Beitragvon audax » Sonntag 1. Juni 2008, 19:30

Wenn all die tollen Dinge nicht in Safari funzen, dann wechsel halt den Browser.
Warum denkst du eigentlich, dass alles im Browser laufen wird?
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon birkenfeld » Sonntag 1. Juni 2008, 20:27

mitsuhiko hat geschrieben:Warum muss den alles in den Browser?


Weil man das den Leuten dann als Innovation verkaufen kann. In fünf bis zehn Jahren kann man dann wieder Desktop-Applikationen als *die* Neuheit vermarkten.

Zum Thema an sich: es wäre eigentlich nicht so schwierig, einen vernünftigen Editor via XEmbed/ActiveX/$OSXBUZZWORD anstatt eines faden Textcontrols anzuzeigen (Konqueror kann das mit einem Patch, siehe http://www.yzis.org/wiki/images/f/fe/Khtml-textarea.jpg). Anscheinend ist das den Browserbauern aber nicht wichtig genug.
Zuletzt geändert von birkenfeld am Sonntag 1. Juni 2008, 20:30, insgesamt 1-mal geändert.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon gerold » Sonntag 1. Juni 2008, 20:28

sma hat geschrieben:Ich glaube daran, dass IDEs früher oder später browserbasiert sein werden.

Hallo Stefan!

:cry: Ich mag diesen Gedanken nicht. Ich will nicht mit JavaScript herumpfuschen müssen. Ich will solide Programme schreiben, in denen ich mich nicht um die Restriktionen eines Browsers kümmern muss. Und wenn die Einschränkungen der Browser aufgeweicht werden, dann ist die Gefahr von Sicherheitslücken wieder größer (wie z.B. bei ActiveX-Controls). Das mag ich auch nicht.

Microsoft musste die damals geschaffene Möglichkeit, ActiveX-Controls in HTML-Seiten eingebettet laufen zu lassen, von Jahr zu Jahr mehr einschränken. Nur verifizierte Controls dürfen ausgeführt werden und dürfen auch nicht alles -- je nach Sicherheitscode.

Wenn ich im Internet surfe, dann will ich nicht, dass der Browser irgendwelche Programme mit "Rechten" ausführen kann. Der Browser soll zum Surfen da sein und für nichts Anderes.
Wenn ich ein Programm zum Betrachten von Internetseiten starte, dann erwarte ich mir, dass dieses Programm auch nur das tut und tun kann.
Wenn ich ein Schreibprogramm starte, dann erwarte ich mir, dass man damit Text schreiben kann und nicht irgendwelche Skripts im Hintergrund ausgeführt werden.
Und wenn ich eine IDE starte, dann will ich damit ohne die Einschränkungen eines Browsers programmieren können.

Mir gefällt das also keineswegs, was Google und Co. vor haben. Ich will nicht, dass mein Browser mit meinen Rechten auf das Dateisystem zugreift. Ich will dass mein Browser Internetseiten darstellen und drucken kann.

Ich weiß nicht, ob ich die richtigen Worte gefunden habe, um mein Gefühl zu dieser Sache zu beschreiben. Aber ich habe es zumindest versucht.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Sonntag 1. Juni 2008, 20:50

Ein Browser sourcecode editor wäre evtl. eine interessante alternative zu Gobby: http://de.wikipedia.org/wiki/Gobby

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon Leonidas » Sonntag 1. Juni 2008, 21:08

gerold hat geschrieben:Mir gefällt das also keineswegs, was Google und Co. vor haben. Ich will nicht, dass mein Browser mit meinen Rechten auf das Dateisystem zugreift. Ich will dass mein Browser Internetseiten darstellen und drucken kann.

Dito.

Aber ich fürchte sma wird da im großen und ganzen Recht behalten und nach "worse is better" wird sich der Desktop zunehmend ins Web verlagern. Was ich nicht besonders toll finde, denn Web-Applikationen schreiben ist ein grausamer PITA. Warum ist dies so. Ganz einfach. User werden inzwischen immer unfähiger und sind bald kaum noch in der Lage Desktop-Applikationen zu nutzen. Das hat schon vor einiger Zeit angefangen, etwa mit den Webmail-Programmen. Webmailer sind nur traurig beschnittene Versionen von echten MUAs und trotzdem gibt es unglaublich viele die sie einsetzen. Weil sie nicht in der Lage sind, ihren MUA zu konfigurieren (Ist das schwer? Nein, keineswegs). In Webmail muss man nichts konfigurieren. In einem Browser muss man auch nichts konfigurieren, das heißt man kann, aber man tut nicht. Da kommt auch die ganze Fähnchen-Klickerei her, obwohl doch jeder Browser entsprechende Sprach-Header mitschickt, die so eine Sprachauswahl unnötig machen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Beitragvon lunar » Sonntag 1. Juni 2008, 22:01

Ja und? Was interessiert mich, was "alle" machen? Ich nutze keinen Webmailer, und würde nicht mal im Traum daran denken, eine Browser-IDE zu nutzen... selbst normale IDEs können ja nicht mit emacs mithalten ;)

Microsoft hat schon einmal versucht, den Desktop ans Internet zu hängen, in dem es bei Windows 98 dem Browser und damit Webanwendungen weitreichende Kontrolle gegeben hat. Diesen Fehler auszubügeln, hat MS Jahre und viel Vertrauen geschenkt. ActiveX war vor zehn Jahren mal die Killer-Technologie für Webanwendungen, heute ist es Symbol für das Böse schlechthin.

Man muss nicht versuchen, die Fehler der Vergangenheit auf Teufel komm raus zu wiederholen ;)
BlackJack

Beitragvon BlackJack » Montag 2. Juni 2008, 06:05

@lunar: Doch, die Fehler muss man immer wiederholen. Liess noch mal was birkenfeld über Innovationen geschrieben hat. So läuft das eben… ;-)
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon jens » Montag 2. Juni 2008, 06:51

Leonidas hat geschrieben:In einem Browser muss man auch nichts konfigurieren, das heißt man kann, aber man tut nicht. Da kommt auch die ganze Fähnchen-Klickerei her, obwohl doch jeder Browser entsprechende Sprach-Header mitschickt, die so eine Sprachauswahl unnötig machen.

Nicht unbedingt. Vielleicht möchte jemand, der seinen Browser auf deutsch eingestellt hat, dennoch mal die englische Variante sehen... Btw. es gibt bestimmt auch ein Firefox Addon dafür...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Montag 2. Juni 2008, 07:08

Desktopanwendungen als Web Applikation *graus* Ohne mich. Sollte das tatsächlich passieren geht diese "Innovation" an mir vorbei, genauso wie Googles Webmail, Office & co.

@sma: am besten du verwirfst den Gedanken. Du beschwörst damit nur den Teufel, von dem wir dachten wir seien ihn langsam wieder los.

Ich schließe mich da Gerold an
Mir gefällt das also keineswegs, was Google und Co. vor haben. Ich will nicht, dass mein Browser mit meinen Rechten auf das Dateisystem zugreift. Ich will dass mein Browser Internetseiten darstellen und drucken kann.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon Leonidas » Montag 2. Juni 2008, 09:27

jens hat geschrieben:Nicht unbedingt. Vielleicht möchte jemand, der seinen Browser auf deutsch eingestellt hat, dennoch mal die englische Variante sehen...

Dafür gibt es Browsereinstellungen, die kann der User einstellen. Letztendlich habe ich letztens einen Mix implementiert: die Sprache kommt aus den Browser-Headern und man kann trotzdem, mittels Session die Sprache über die Seite ändern. Aber so Sachen hätte man wirklich lieber komplett über den Header geregelt, da spart man sich die Session und das Cookie. Wenn es mehr Leute nutzen würden, dann wären die Spracheinstellungen im Browser auch einfacher zu finden, weil zentraler.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Montag 2. Juni 2008, 09:29

Du hast mich nicht richtig verstanden oder ich hab mich dumm ausgedrückt...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Montag 2. Juni 2008, 09:39

jens hat geschrieben:Du hast mich nicht richtig verstanden oder ich hab mich dumm ausgedrückt...

Was hast du denn gemeint? Ich habe deinen Einwand so verstanden, dass du den Sinn der Fahnenklickerei aufzeigen wolltest.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Re: Syntax-Highlighting in Browser-Textarea

Beitragvon jens » Montag 2. Juni 2008, 09:42

Leonidas hat geschrieben:
jens hat geschrieben:Nicht unbedingt. Vielleicht möchte jemand, der seinen Browser auf deutsch eingestellt hat, dennoch mal die englische Variante sehen...

Dafür gibt es Browsereinstellungen, die kann der User einstellen.


Leonidas hat geschrieben:
jens hat geschrieben:Du hast mich nicht richtig verstanden oder ich hab mich dumm ausgedrückt...

Was hast du denn gemeint? Ich habe deinen Einwand so verstanden, dass du den Sinn der Fahnenklickerei aufzeigen wolltest.


Genau. In den Brwosereinstellungen kann man nur global die Sprache umstellen. Wenn man auf einer Webseite auf die Fahne klickt, ist die Sprache nur auf der Webseite geaendert.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder