Quelltext-Editor mit Syntax Highlighting
0 0 0 0 
tk
0 Felix Riesterer
0 0 0 0 0 Tim Tepaße
0 0 Tim Tepaße
0
0
Quelltext-Editor mit Syntax Highlighting
Der MartinHi!
Ich bin gerade dabei, einen Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
Die Software ist noch relativ neu und macht unter Opera und IE diverse Probleme, sollte aber in Webkit- und Gecko-Browsern einigermaßen gut laufen. Natürlich hab ich das bislang nur mit eigenen Codeschnipseln getestet, daher würde mich interessieren, wie gut das Highlighting mit dem Code anderer Leute funktioniert. Falls Ihr also Zeit und Lust habt, damit mal etwas rumzuspielen und mir ggfs. falsch hervorgehobene Code-Snippets oder sonstige Bugs zu schicken, wäre das sehr cool.
Experimentierfreudige können den Editor natürlich auch aus dem SVN runterladen und in eigene Seiten oder Anwendungen einbauen, eine Dokumentation für derartiges muss allerdings noch geschrieben werden...
-
Hi!
Ich bin gerade dabei, einen Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
noch geschrieben werden...
-
Hallo,
Die Hervorhebung der passenden Klammern gefällt mir :-)
Falls Ihr also Zeit und Lust habt, damit mal etwas rumzuspielen und mir ggfs. falsch hervorgehobene Code-Snippets oder sonstige Bugs zu schicken, wäre das sehr cool.
Wohl ein Bug:
Die Home-Taste (oder "Begin" oder "Pos1", wie auch immer) tut nicht richtig.
Sie führt nicht zum Zeilenanfang, sondern zum nächsten Zeichen.WinXP Sp3, FF 3.5.3
Gruß, Don P
-
Wohl ein Bug:
Die Home-Taste (oder "Begin" oder "Pos1", wie auch immer) tut nicht richtig.
Sie führt nicht zum Zeilenanfang, sondern zum nächsten Zeichen.Ist wahrscheinlich Geschmackssache, aber ich finde, Home und End sollten an den Anfang und das Ende des kompletten Texts springen. Das war zwar kaputt, ist jetzt aber repariert. Für Anfang/Ende der Zeile bin ich noch am Überlegen, was da ein guter Shortcut wäre. In Emacs wäre das Ctrl-A und Ctrl-E, aber a ist ja schon anderweitig vergeben...
WinXP Sp3, FF 3.5.3
Gruß, Don P
-
Hallo,
Ist wahrscheinlich Geschmackssache, aber ich finde, Home und End sollten an den Anfang und das Ende des kompletten Texts springen.
das würde aber dem widersprechen, was man aus den meisten Editor- und Textverarbeitungssystemen gewöhnt ist. Es ist fast schon "Standard", dass die Home-Taste an den Zeilenanfang und die End-Taste ans Zeilenende führt.
Um an den Anfang des gesamten Texts (Dokuments) zu springen, gibt's ja normalerweise die Kombis Ctrl-PgUp (alternativ Ctrl-Home) und Ctrl-PgDn (oder Ctrl-End).Ciao,
Martin--
Wenn die Amerikaner eines Tages von jeder Tierart ein Pärchen nach Cape Canaveral treiben ...
ja, DANN sollte man endlich misstrauisch werden.
-
Hallo,
Ist wahrscheinlich Geschmackssache, aber ich finde, Home und End sollten an den Anfang und das Ende des kompletten Texts springen.
das würde aber dem widersprechen, was man aus den meisten Editor- und Textverarbeitungssystemen gewöhnt ist. Es ist fast schon "Standard", dass die Home-Taste an den Zeilenanfang und die End-Taste ans Zeilenende führt.
Um an den Anfang des gesamten Texts (Dokuments) zu springen, gibt's ja normalerweise die Kombis Ctrl-PgUp (alternativ Ctrl-Home) und Ctrl-PgDn (oder Ctrl-End).Naja, kommt wahrscheinlich drauf an, was für Editoren man benutzt, mein Eclipse springt bspw. zum Dateianfang und -ende. OpenOffice verhält sich allerdings wie von Dir beschrieben. Über kurz oder lang werde ich denke ich einfach die entsprechenden Funktionen bauen und die Tastatur-Mappings dann konfigurierbar machen (und vielleicht einen Poll auf die Seite, auf der man über das default-Mapping abstimmen kann :-).
Ciao,
Martin
-
-
-
Hallo Don, Hallo sonic,
Die Hervorhebung der passenden Klammern gefällt mir :-)
Funktioniert aber irgendwie nicht so ganz korrekt: ich habe in das Tool mal die Datei in /__inc/class/wettkaempfe.inc.php aus tkswim geladen (Vorsicht, die Datei hat 115K, bis Firefox die Datei geladen hat, dauert es etwas, bei mir kommt die Meldung dass das Script nicht reagieren würde o.ä.). Bei manchen if-Klammern werden nicht die jeweils zusammengehörigen Klammern hervorgehoben sondern irgendein Zeichen der Bedingung (das gleiche passiert auch bei anderen Blöcken, z.B. foreach), Beispiele: Zeilen 460, 607, 612, 619, 650 und 2826. Ich vermute, dass das Script Probleme hat wenn eine Zeile mit Leerzeichen *und* Tabulatoren (das ist editorbedingt, dass das nicht einheitlich ist) eingerückt ist. Auch bringt eine einzelne öffnende geschweifte Klammer (Zeile 1370) in einem Kommentar das Script durcheinander.
Gruß,
Tobias-
Hallo Don, Hallo sonic,
Die Hervorhebung der passenden Klammern gefällt mir :-)
Funktioniert aber irgendwie nicht so ganz korrekt: ich habe in das Tool mal die Datei in /__inc/class/wettkaempfe.inc.php aus tkswim geladen (Vorsicht, die Datei hat 115K, bis Firefox die Datei geladen hat, dauert es etwas, bei mir kommt die Meldung dass das Script nicht reagieren würde o.ä.).
Die kam bei mir auch. Aber ich hatte auch noch nie 2800 Zeilen probiert :-)
Bei manchen if-Klammern werden nicht die jeweils zusammengehörigen Klammern hervorgehoben sondern irgendein Zeichen der Bedingung (das gleiche passiert auch bei anderen Blöcken, z.B. foreach), Beispiele: Zeilen 460, 607, 612, 619, 650 und 2826. Ich vermute, dass das Script Probleme hat wenn eine Zeile mit Leerzeichen *und* Tabulatoren (das ist editorbedingt, dass das nicht einheitlich ist) eingerückt ist.
Ja, das liegt tatsächlich an den Tabs (die Position des Markers wird anhand der Anzahl der Zeichen berechnet). Werde mal versuchen, das abzufangen, ohne dass die Performance zu sehr leidet.
Auch bringt eine einzelne öffnende geschweifte Klammer (Zeile 1370) in einem Kommentar das Script durcheinander.
An der Stelle hat er bei mir nicht gemeckert (d.h. Klammern davor und danach matchen korrekt), aber ich ab auch gerade einen anderen Bug im Matching behoben, vielleicht lags daran
Gruß,
Tobias
-
-
-
Lieber sonic,
Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
irgendwie erinnert mich das Teil sowas von an EditArea... sodass ich mich ehrlich frage: Was ist der Unterschied?
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Lieber sonic,
Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
irgendwie erinnert mich das Teil sowas von an EditArea... sodass ich mich ehrlich frage: Was ist der Unterschied?
Tatsächlich hatte ich angefangen, den Code von EditArea etwas für meine Bedürfnisse anzupassen, habe dann aber schnell festgestellt, dass das (für mich) nicht wartbar ist, weshalb die Architektur komplett umgestellt ist (vergleiche einfach mal die Quelltexte).
Funktional ist der größte Unterschied im Moment, dass das Highlighting meines Editors mit Code Blocks arbeitet (angelehnt an Pygments), d.h. dass z.B. in PHP-Code die öffnenden und schließenden <? ?>-Tags auch tatsächlich das Highlighting beeinflussen (während EA seine Regexps global auf den ganzen Text anwendet und dann versucht, die Ungenauigkeiten durch CSS-Regeln zu verstecken). Analog dazu werden z.B. auch Variablen in interpolierten Strings korrekt erkannt.
Ansonsten dürfte mein Editor deutlich ressourcenschonender sein. EditArea lässt (je nach Browser und config) eine nicht unerhebliche Zahl von Funktionen per setTimeout alls 50-100ms durchlaufen (und zwar unabhängig davon, ob der Editor überhaupt fokussiert ist). Aber es stimmt schon, aus Endanwendersicht sind sich die beiden noch sehr ähnlich. aber ich arbeite dran :-)
Liebe Grüße,
Felix Riesterer.
-
[latex]Mae govannen![/latex]
Ansonsten dürfte mein Editor deutlich ressourcenschonender sein. EditArea lässt (je nach Browser und config) eine nicht unerhebliche Zahl von Funktionen per setTimeout alls 50-100ms durchlaufen (und zwar unabhängig davon, ob der Editor überhaupt fokussiert ist). Aber es stimmt schon, aus Endanwendersicht sind sich die beiden noch sehr ähnlich. aber ich arbeite dran :-)
Stimmt, EditArea kommt reichlich zäh daher.
Aber nun zu deinem Projekt: Du solltest dringend davon Abstand nehmen, irgendwelche Browser zu ermitteln und ausschließlich browserübergreifend arbeiten (insbesondere #3 ff) , sonst wirst du die Probleme mit diversen Browsern nie in den Griff bekommen.
Cü,
Kai
--
A workaround for an avoidable problem often adds clutter and overhead to the program which
could have been avoided by not creating the problem in the first place.(Garrett Smith/clj)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Aber nun zu deinem Projekt: Du solltest dringend davon Abstand nehmen, irgendwelche Browser zu ermitteln und ausschließlich browserübergreifend arbeiten (insbesondere #3 ff) , sonst wirst du die Probleme mit diversen Browsern nie in den Griff bekommen.
Ja, so als Design-Ziel ist das denke ich auf jeden Fall erstrebenswert. jQuery macht ja seit 1.3 soweit ich weiß diese capabilty-basierenden Weichen, aber nachdem nichtmal tinyMCE ganz ohne Browsererkennung auskommt weiß ich ja nicht, ob ich das hinbekomme...
Cü,
Kai
-
-
-
-
Hallo,
Ich bin gerade dabei, einen Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
Die Software ist noch relativ neu und macht unter Opera und IE diverse Probleme, sollte aber in Webkit- und Gecko-Browsern einigermaßen gut laufen. Natürlich hab ich das bislang nur mit eigenen Codeschnipseln getestet, daher würde mich interessieren, wie gut das Highlighting mit dem Code anderer Leute funktioniert. Falls Ihr also Zeit und Lust habt, damit mal etwas rumzuspielen und mir ggfs. falsch hervorgehobene Code-Snippets oder sonstige Bugs zu schicken, wäre das sehr cool.
Ich war so frei und habe: http://redaktion.selfhtml.org/selfhtml-preview/src/selfhtml9.css in deinem Editor hineinkopiert.
Kannst du auch, dann siehst du wo er noch Probleme mit CSS hat.Grüße
Thomas-
Ich war so frei und habe: http://redaktion.selfhtml.org/selfhtml-preview/src/selfhtml9.css in deinem Editor hineinkopiert.
Kannst du auch, dann siehst du wo er noch Probleme mit CSS hat.Das war ja dann doch so einiges. Die meisten Sachen hab ich jetzt denke ich korrigiert, wobei ich die browserspezifischen Attribute glaube ich ungematcht lassen werde.
Grüße
Thomas-
Hallo,
Das war ja dann doch so einiges. Die meisten Sachen hab ich jetzt denke ich korrigiert,
Dann kann können wir einen kleinen Härtetest machen ;-)
https://redaktion.selfhtml.org/export/6802/projekte/sdmladdon/css/selfhtml.css
Grüße
Thomas-
Hallo,
Das war ja dann doch so einiges. Die meisten Sachen hab ich jetzt denke ich korrigiert,
Dann kann können wir einen kleinen Härtetest machen ;-)
https://redaktion.selfhtml.org/export/6802/projekte/sdmladdon/css/selfhtml.css
Härtetest triffts ganz gut...
Die Sachen, die ich identifizieren konnte (at-Rules, Attribut-Selektoren u.ä.) hab ich jetzt eingebaut, bei einigen Konstrukten muss ich aber echt passen (hab auch keinen Editor installiert, der das irgendwie sinnvoll darstellen kann). Gibts irgendwo ne Beschreibung zu den hier verwendeten Funktionen? Wenn ich z.B. bei Google nach @property-group suche, bekomme ich keinen einzigen sinnvollen Teffer
Grüße
Thomas-
Hallo Sonic
Gibts irgendwo ne Beschreibung zu den hier verwendeten Funktionen? Wenn ich z.B. bei Google nach @property-group suche, bekomme ich keinen einzigen sinnvollen Teffer
@property-group ist eine proprietäre Erweiterung ohne vendor prefix des XML-Editors XMLMind (den Thomas für das Schreiben von SELFHTML 9 vorgegeben hat). Sie definiert in etwa Konstanten bzw. Variablen für CSS, ähnlich wie das beim W3C spezifiziert werden soll.
Aber eigentlich brauchst Du so genaue Beschreibungen nicht. Mach Dir das Leben etwas einfacher und konzentrier Dich auf die großen Sprachenkonstrukte, sprich definiere @-Regeln statt „@import & @media und @whatever“. Was Dir dabei helfen kann sind die CSS Specs wie CSS 3 Syntax (Neuerer Entwurf) und CSS 3 Values and Units (Neuerer Entwurf). Diese definieren dann die Metasyntax, die tatsächlich ausgedrückten @-rules, Eigenschaften, Schlüsselwörter, Werte und funktionale Notationen folgen dieser Metasyntax. Es reicht dann, wenn Du diese Metasyntax highlightest anstatt ins Details zu gehen. Die formale Grammatik im neuesten Entwurf von CSS 3 Syntax deckt z.B. @property-group ab.
Ähnliches findet sich auch bei anderen Sprachen, so dass man nicht unbedingt per Trial & Error unterwegs sein muss.
-
Hallo,
Härtetest triffts ganz gut...
Die Sachen, die ich identifizieren konnte (at-Rules, Attribut-Selektoren u.ä.) hab ich jetzt eingebaut, bei einigen Konstrukten muss ich aber echt passen...
Das war zugegeben fies von mir. Ich habe nicht zuletzt deshalb die Datei verlinkt, weil darin sehr viele Erweiterungen stehen, die ein "guter" Editor "ignorieren" sollte. Ansonsten würde ich eben auch auf die Grammatik von CSS verweisen. Jedoch nicht unbedingt auf 6 Jahre alte, vergesse Entwürfe ;-).
Es würde einfach reichen, wenn dein Editor CSS 2.1 könnte:
http://www.w3.org/TR/CSS2/grammar.html bzw.
http://www.w3.org/TR/css3-selectors/#w3cselgrammarGrüße
Thomas-
Ansonsten würde ich eben auch auf die Grammatik von CSS verweisen. Jedoch nicht unbedingt auf 6 Jahre alte, vergesse Entwürfe ;-). Es würde einfach reichen, wenn dein Editor CSS 2.1 könnte:
Ey. ;)
Ich hab den alten Entwurf doch extra rausgekramt, weil er so flexibel ist. Die CSS-2.1-Grammatik beschreibt ja eben nicht beliebige @-Rules, obwohl das im CSS-3- oder Extension-Land recht praktisch wäre.
-
Hallo Tim,
Ey. ;)
Ich hab den alten Entwurf doch extra rausgekramt, weil er so flexibel ist. Die CSS-2.1-Grammatik beschreibt ja eben nicht beliebige @-Rules, obwohl das im CSS-3- oder Extension-Land recht praktisch wäre.
Das stimmt, aber ich fürchte sie werden noch Jahre brauchen um sich von dort zu bewegen und bis dahin ist eh alles wieder vollkommen anderes.
Ich bilde mir jetzt auch ein dass CSS 2.1 schon Rec. war und jetzt ist es (wieder) doch nur CR.
Und was die Browser angeht: Microsoft hat sich selbst ins Abseits gespielt - auch wenn der IE8 schon mal wirklich gut ist - weil sie nie und nimmer mehr flexibel reagieren können und bremsen damit Entwiklung und Entwickler ohne Ende. Die anderen können zwar schneller reagieren, aber sie werden auch nicht viel machen, weil wer will schon an etwas Arbeiten, an dem sich in den letzten 6 Jahren nur der Staub angesammelt hat. Zudem: noch immer haben alle Browser Probleme mit CSS 2.1.
Es wurden paar eigene Erweiterungen geschaffen und sonst ruhen sich alle friedlich auf ihren Lorbeeren aus bzw. basteln an der HTML5 Unterstützung.
Opera ist, wo noch das meiste in Sachen CSS passierte. FF enwickelt sich zunehmend zu einem echten IE-Nachfolger und hat mehr Probleme mit Speicherverbrauch als der IE jemals hatte. Aber das ist schon ein anderes Thema ;-)Grüße
Thomas
-
-
Das war zugegeben fies von mir. Ich habe nicht zuletzt deshalb die Datei verlinkt, weil darin sehr viele Erweiterungen stehen, die ein "guter" Editor "ignorieren" sollte.
Das Problem dabei ist zumindest bei einem Regexp-basierten Parser, Erweiterungen von Fehlern zu unterscheiden. Klar könnte ich als letzte Regexp einfach eine Catchall einbauen (und vermutlich werde ich das auch machen), aber ich würde schon gerne das Feature behalten, dass z.B. eine Attribut-Angabe wie 'text-algin' rot (d.h. als Fehler) markiert wird, während 'text-align' die richtige Farbe hat.
Ansonsten würde ich eben auch auf die Grammatik von CSS verweisen. Jedoch nicht unbedingt auf 6 Jahre alte, vergesse Entwürfe ;-).
Es würde einfach reichen, wenn dein Editor CSS 2.1 könnte:
http://www.w3.org/TR/CSS2/grammar.html bzw.
http://www.w3.org/TR/css3-selectors/#w3cselgrammarwerd ich mir demnächst mal ansehen, danke für die Links!
Grüße
Thomas
-
-
-
-
-
-
Hi!
Ich bin gerade dabei, einen Online-Editor für Quelltext zu entwickeln, der innerhalb von Webseiten für textareas geladen werden kann. Das Ganze ist unter http://sourcepad.org zu begutachten.
Die Software ist noch relativ neu und macht unter Opera und IE diverse Probleme, sollte aber in Webkit- und Gecko-Browsern einigermaßen gut laufen. Natürlich hab ich das bislang nur mit eigenen Codeschnipseln getestet, daher würde mich interessieren, wie gut das Highlighting mit dem Code anderer Leute funktioniert. Falls Ihr also Zeit und Lust habt, damit mal etwas rumzuspielen und mir ggfs. falsch hervorgehobene Code-Snippets oder sonstige Bugs zu schicken, wäre das sehr cool.
Experimentierfreudige können den Editor natürlich auch aus dem SVN runterladen und in eigene Seiten oder Anwendungen einbauen, eine Dokumentation für derartiges muss allerdings noch geschrieben werden...
Hallo sonic,
ich hab ein allgemeine frage an dich.
ich hab auchmal daran gedacht einen online-editor wie du zu machen,
aber ein freund hat mir davon abgeraten den wenn nutzer eigenen php-code eingeben und ausführen lassen können, ist das doch ein extremes Sicherheitsrisiko.
Hacker könnten auf den server und alle dateien zugreifen, sie löschen, usw....wie hast du das problem gelöst ?
gibt es überhaupt eine lösung ?mfg relaxx
-
Hi!
Hallo,
wie hast du das problem gelöst ?
gibt es überhaupt eine lösung ?Wie währe es damit, den Code nicht auszuführen. Zumal eh kein PHP bei einer Clientanwendung im Spiel[1] ist.
mfg relaxx
mfg Pryos
[1]zumindest was den Usercode betrifft
-
Hallo sonic,
ich hab ein allgemeine frage an dich.
ich hab auchmal daran gedacht einen online-editor wie du zu machen,
aber ein freund hat mir davon abgeraten den wenn nutzer eigenen php-code eingeben und ausführen lassen können, ist das doch ein extremes Sicherheitsrisiko.Der Server hat damit ja gar nichts zu tun und der eingegebene Code wird auch nicht ausgeführt, lediglich ein Regexp-Parser läuft drüber, um einzlene Teilstrings zu matchen. Ob es sich bei dem Text um PHP, C++ oder Buchstabensalat handelt, spielt dabei keine Rolle. Der Parser läuft zudem auf dem Client.
-