[disc] code highlight kleuren

[crisp]

Zoals sommigen van jullie wellicht gemerkt zullen hebben is er onlangs een en ander gewijzigd aan de code highlighter van GoT. Omdat de standaard built-in highlighter van PHP nogal ranzige HTML produceert en de laatste versie van .oisyn's highlighter ook PHP ondersteund, is besloten om deze highlighter ook voor PHP te gaan gebruiken.
Ik heb in eerste instantie de kleuren voor deze highlighter een beetje aangepast aan de standaard PHP highlight kleuren, maar ik hoor zo hier en daar dat niet iedereen daar even tevreden mee is...

Nu heb ik daar eens over lopen nadenken, en op dit moment zie ik een aantal mogelijkheden:

1. We passen de kleuren aan voor alle highlighted code naar een kleurenschema waar de meerderheid het mee eens is
2. We passen de highlighter aan zodat voor verschillende talen verschillende kleurschema's kunnen worden gebruikt
3. We stellen een aantal kleurschema's ter beschikking waarvan je er 1 kan uitkiezen in je prefs (dit geld dan weer voor alle highlighted talen)

Het is technisch niet haalbaar cq. wenselijk dat mensen hun eigen kleurschema kunnen gaan opgeven in de prefs, dus die optie overweeg ik ook niet. (als je een abo hebt zou je dat nog dmv een custom CSS kunnen doen, en anders bieden browsers vaak ook wel mogelijkheden om je eigen CSS op te geven).

Aangezien de mensen hier in P&W denk ik het meest de [code]-tags hanteren leek mij dit de gepaste plaats om een dergelijke discussie te starten en feedback te krijgen. Allereerst zou ik dus graag de meningen weten welke van de door mij 3 genoemde opties omtrent de highlighter kleurschema's het meest aanspreekt.
Daarnaast zou ik dus graag input hebben over de kleurschema's zelf. Daarvoor heb ik onderstaande codekleur-generator gemaakt waar je zelf met kleurtjes kan prutsen en ze dmv de >>>-button naar het textvlak kan kopieeren om ze in je post tussen bijvoorbeeld [code] of [pre] tags te zetten zodat andere mensen 'm weer naar het textvlak kunnen kopieeren en mbv de <<< knop kunnen importeren

De knoppen schema1 en schema2 geven respectievelijk het huidige kleurschema en .oisyn's oorspronkelijke kleurschema te zien.

Happy coloring!

codekleur generator:

php:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<?php     // just something to test     $page = $_GET['id'];     $validpages = array (         './index.html',         './cavia.html',         './konijn.html'     );     if (!isset($validpages[$page])) $page = 0;     if (file_exists($validpages[$page]))     {         include($validpages[$page]));     }     else     {         echo 'File missing: ', $validpages[$page];     } ?>

c++:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

// comment class Blaat { public:     int c;    /* hier nog meer comments */          Blaat ();     void doeIets (); }; int main () {     for (int i = 0; i < 0x20; i++)     {         cout << "blaat\"blaat" << endl;     }          /* uitgecomment stukje code:     cout << ""\"\""" "" \'\' \' \' \'\\' \\' \\'\\' << endl;     */          return 0; }

Code Kleurtjes

Keywords:
Special names:
Identifiers:
Numbers:
Methods:
Strings:
Comments:
Preprocessor:

[.oisyn]

code_keyword #0000ff
code_special #800000
code_ident #000080
code_number #800080
code_method #000080
code_string #e000e0
code_comment #008000
code_preproc #ff0000



(Het is trouwens een beetje dommig dat je de C highlighter gebruikt om C++ code te highlighten in je voorbeeld . Daardoor worden keywords als 'class' en 'public' niet correct gehighlight)

Overigens moet ik m'n C highlighter eens C99 compatible maken

[ Voor 47% gewijzigd door .oisyn op 25-11-2004 13:41 ]

[Verwijderd]

code:

code_keyword    #0000FF
code_special    #9900FF
code_ident  #000099
code_number #990099
code_method #009900
code_string #CC0000
code_comment    #999999
code_preproc    #FF0000

\o/

Ik stel voor om gewoon er een te pakken, en als mensen wat anders willen, moeten ze er maar een stylesheet overheen leggen
Je kunt het heel erg handig aanpakken met CSS door het codeblock een className mee te geven die de taal aangeeft, en van elk van de bovenstaande 8 items een class te maken. Zo kun je het volgende doen:

Cascading Stylesheet:

.csharp .identifier {
   color: #0000FF;
   background-color: inherit;
}

Dit vereist denk ik de minste aanpassingen aan het geheel, en is volgens mij dé manier om het op te lossen.

[Michali]

code:

code_keyword    #0000bb
code_special    #000000
code_ident  #660000
code_number #dd0000
code_method #000000
code_string #008800
code_comment    #999999
code_preproc    #000088

Beetje de Zend Studio kleuren waar ik erg tevreden over ben. Werkt lekker hier iig.

Commentaar grijs: gemakkelijk te onderscheiden van code en toch goed leesbaar.
String groen: Ik vind string echt een geval apart en dat mag van mij goed opvallen.
Keywords blauw: beetje de standaard kleur hiervoor en ik ben het wel gewend.

[ Voor 31% gewijzigd door Michali op 25-11-2004 14:10 ]

[OkkE]

Ik gebruik alleen PHP, en daarvan vond ik de kleuren zoals ze waren prima. Alleen gebruik ik zelf altijd Oranje voor comments.

Maar imho is 1 vast kleurenschema per taal het beste.

[whoami]

Ik denk dat optie 1 niet werkbaar is; optie 3 zou mooi zijn als dat kan uitgebreid worden naar een preference die je kan opgeven per taal, maar aangezien dat er niet is, denk ik dat optie 2 de beste oplossing is.

[Verwijderd]

Ik kan er niet zoveel om geven. Het is belangrijker _dat_ de code gehighlight is dan _hoe_ hij gehighlight is.

Als je het kan realiseren lijkt 3 me de mooiste optie, maar dat is wel meer werk natuurlijk. Daarna lijkt 2 me de beste, aangezien je misschien ook dingen als HTML en CSS wilt gaan highlighten en daar komen toch weer net iets andere constructies bij kijken (en zijn andere kleuren dus ook op zijn plek).

[RedRose]

code_keyword #0000ff
code_special #008080
code_ident #000080
code_number #0000ff
code_method #000080
code_string #dd0000
code_comment #008000
code_preproc #ff0000

of iets dergelijks

Wat doet de hightlighter met bijvoorbeeld $mooh->splut = 2 ?

Optie 2 lijkt mij het beste. Het gaat er uiteindelijk om dat hier op het forum de code duidelijk en prettig leesbaar is voor iedereen. Als mensen het niet met een vast kleurenschema eens zijn, moeten ze maar een abo nemen.

[NMe]

crisp schreef op donderdag 25 november 2004 @ 13:37:
Nu heb ik daar eens over lopen nadenken, en op dit moment zie ik een aantal mogelijkheden:

1. We passen de kleuren aan voor alle highlighted code naar een kleurenschema waar de meerderheid het mee eens is
2. We passen de highlighter aan zodat voor verschillende talen verschillende kleurschema's kunnen worden gebruikt
3. We stellen een aantal kleurschema's ter beschikking waarvan je er 1 kan uitkiezen in je prefs (dit geld dan weer voor alle highlighted talen)

Je vergeet dit:
4. Onder elk code blokje deze codekleur generator toevoegen.

Even serieus: ik zou voor optie twee gaan. Op die manier kun je voor elke taal de kleuren van de meest gebruikte editor overnemen om te highlighten. De syntax highlighting wordt op die manier een soort van herkenningspunt voor een taal, aangezien bijvoorbeeld Delphi standaard heel anders gehighlight wordt dan PHP, en beiden zijn prima leesbaar.

[André]

Kan die highlighter dan ook gebruikt worden voor JS en CSS?

JavaScript:

// Blaat
function Bla()
{
  var Andre = "cool";
}

Cascading Stylesheet:

body {
  color: #000000;
}

/* Testje */

[Orphix]

Ik ga voor schema 2. Dit is puur omdat ik groen als commentaar gewend ben. Dit is bijvoorbeeld ook default bij Visual Studio. Het enige wat ik minder mooi vind aan schema 2 is dat de strings paars zijn, dit zie ik liever rood. Dus hierbij mijn lijstje:

code_keyword #0000ff
code_special #800000
code_ident #000080
code_number #800080
code_method #000080
code_string #dd0000
code_comment #008000
code_preproc #ff0000

Verder vind ik het, zoals hierboven ook al was genoemd, eigenlijk niet zo heel erg boeiend welke kleurtjes er precies gebruikt worden. Ik merk dat ik onbewust zonder moeite van de ene kleurencodering op de andere overstap. Gewoon een enkel schema aanhouden en dat gebruiken.

[Verwijderd]

Ik ben het 100% met -NMe-

Om even terug te komen op de reply van Andre > Dat is volgens mij wel mogelijk, maar dan moet iemand (jij? .oisyn? crisp?) het flex lexer bestand aanmaken voor JavaScript en CSS

[André]

Verwijderd schreef op donderdag 25 november 2004 @ 17:02:
Ik ben het 100% met -NMe-

Om even terug te komen op de reply van Andre > Dat is volgens mij wel mogelijk, maar dan moet iemand (jij? .oisyn? crisp?) het flex lexer bestand aanmaken voor JavaScript en CSS

Dat lijkt me niet zoveel moeite, helmaal niet voor css. En JS doet het al (bijna) prima op de c++ of php highlighter.

[NMe]

André schreef op donderdag 25 november 2004 @ 17:06:
Dat lijkt me niet zoveel moeite, helmaal niet voor css. En JS doet het al (bijna) prima op de c++ of php highlighter.

En als het wel teveel werk is om in het drukke schema van crisp te passen, wil ik wel wat hulp aanbieden.

[Soultaker]

Ik ben het eens met OneOfBorg: het maakt me echt geen reet uit welke kleurtjes er gebruikt worden (ik zou ook niet weten wat kate, vim, UltraEdit en Visual Studio doen; ik gebruik ze regelmatig en ze doen allemaal wat anders, denk ik, maar het stoort me niet).

Het gaat er wat mij betreft puur om dat er contrast is tussen verschillende soorten dingen, zodat je fouten makkelijk kan zien (strings die niet afgesloten zijn, code in commentaar-blokken, keywords die als identifier gebruikt worden). Verder heb ik als enige eis dat alle tekst een beetje leesbaar blijft (dus niet zoals vim donkerblauw op zwart).

Van de twee schema's vind ik de tweede wat fijner. De groene tekst van de eerste vind ik wat minder duidelijk en wat teveel contrast leveren met het blauw van de identifiers.

[.oisyn]

Orphix schreef op donderdag 25 november 2004 @ 16:56:
Ik ga voor schema 2. Dit is puur omdat ik groen als commentaar gewend ben. Dit is bijvoorbeeld ook default bij Visual Studio. Het enige wat ik minder mooi vind aan schema 2 is dat de strings paars zijn, dit zie ik liever rood.

Dan conflicteert het met preprocessor directives voor C/C++ en de php begin en eind tag, dat is namelijk ook rood.

JS, CSS en HTML highlighters staan op de todo lijst, maar aangezien niemand zin heeft om de flex syntax aan te leren ben ik de enige die het toe kan voegen, en ik heb over het algemeen wel wat anders te doen

[Alarmnummer]

Persoonlijk vind ik het erugh prettig dat commentaar grijs is. Kan je erover heen lezen en de echte structuur van het programma zien.. maar als het moet kan je ook het commentaar lezen.

[drm]

Alarmnummer:
Persoonlijk vind ik het erugh prettig dat commentaar grijs is. Kan je erover heen lezen en de echte structuur van het programma zien.. maar als het moet kan je ook het commentaar lezen.

with 112 ^^^

[Denker]

Mee eens, commentaar moet grijs. Niet paars ofzo, dat valt teveel op.

[Wolfboy]

Deze vind ik opzich wel prettig

code:

code_keyword    #060
code_special    #06F
code_ident  #00C
code_number #F00
code_method #009
code_string #C00
code_comment    #F90
code_preproc    #F00

Optie 3 lijkt mij overigens het beste, iedereen is toch wat anders gewend en zal ook wat anders willen.

[ Voor 22% gewijzigd door Wolfboy op 25-11-2004 23:42 ]

[X-Lars]

JS, CSS en HTML highlighters

IMO voldoen mogelijkheid 1 en 2 prima. Iedereen slikt het toch wel, als het maar een klein beetje logisch is en dat vertrouw ik degene die erover gaan wel toe

[Tomatoman]

Code highlighting hoort natuurlijk de standaard Delphi syntax highlighting te reproduceren:
• reserved words vetgedrukt
• strings en getallen donkerblauw (navy)
• commentaar cursief donkerblauw
• compiler directives groen



Anders gezegd: vergeet niet dat er ook nog andere programmeertalen dan PHP en C/C++ zijn.

Een jaar geleden heb ik alle regels voor syntax highlighting in Delphi - inclusief een lijst met reserved words - vastgelegd in een Word-document. Zie dit maar als een hint voor crisp en .oisyn

[Soultaker]

.oisyn schreef op donderdag 25 november 2004 @ 17:59:
JS, CSS en HTML highlighters staan op de todo lijst, maar aangezien niemand zin heeft om de flex syntax aan te leren ben ik de enige die het toe kan voegen, en ik heb over het algemeen wel wat anders te doen

De W3C publiceert bij hun specificaties meestal wel een formele grammatica in Lex formaat (dat is compatible met Flex, denk ik?)

Voor SGML (HTML enzo) staat 'ie bijvoorbeeld hier:
http://www.w3.org/TR/WD-html-lex/sgml.l

Voor CSS1 is het een appendix bij de specificatie:
http://www.w3.org/TR/1999/REC-CSS1-19990111.html#appendix-b

Voor ECMAScript (gestandaardiseerd eJavaScript) is er wel een specificatie, maar niet direct in Lex formaat; dat is misschien wat meer werk:
http://www.mozilla.org/js...formal/lexer-grammar.html

[Sendy]

Ik zou voor optie 1) gaan. Misschien een tutorialtje erbij schrijven hoe je met Mozilla/Firefox en/of andere browsers een eigen cssje kan maken.

Verder maken de kleuren mij niet zo uit, misschien dat comments (zoals eerder genoemd) grijs, of mijn voorkeur, blauw-grijs zijn (iets van #4444BB, ofzo).

[12_0_13]

Ik heb echt een hekel aan dat vetgedrukte in code, dus als er een optie in zit om dat uit te zetten, maak je mij iig blij

edit mijn favorieten:

code:

code_keyword    #0000ff
code_special    #800000
code_ident    #000000
code_number  #FF0000
code_method  #000080
code_string  #008080
code_comment    #008000
code_preproc    #ff0000

[ Voor 47% gewijzigd door 12_0_13 op 26-11-2004 00:18 ]

[dev icey]

In den beginne...
Hierbij mijn keuze voor de kleuren voor de syntax highlighting.

De basis
Het belangrijke van kleuren is herkenning, en om je oog ergens op vast te pinnen. Het belangrijke is dus dat je de goede kleuren kiest. Irritante kleuren en onleesbare kleuren moeten dus niet voorkomen, ook niet in deze highlighter. Roze voor strings is bijvoorbeeld “not done”, net als kleuren als geel. Dit is gewoon totaal onleesbaar en ook nog eens irritant.

Kijk maar naar dit voorbeeld:


Iets waar je ook aan moet denken is dat je voor typen code die veel voorkomen, je de beste kleuren moet gebruiken.

Een plaatje van het totaal zegt meer dan honderd woorden:


Het verplichte lijstje
Mijn lijstje komt er als het goed is dan zo ongeveer eruit te zien:

code:

code_keyword    #ff8000
code_special    #ff8000
code_ident  #408080
code_number #ff0000
code_method #0000ff
code_string #ff0000
code_comment    #b6b6b6
code_preproc    #0000ff

Nog wat uitleg
Comments: Grijs; Omdat het commentaar is, het moet eigenlijk niet opvallen, je moet het alleen zien als het nodig is, dus vandaar grijs. Het liefst lichtgrijs.
Strings&nummers: Rood; Niet speciaal een reden, maar ik gebruik die kleur al vanaf het begin, en opzich vind ik het prettig ermee te werken.
Variabelen: Zeegroen; Weet niet waarom, maar vind het een mooie kleur voor de veelgebruikte variabelen.

Het plaatje is overigens van mijn favoriete editor: UltraEdit-32, dus er zullen wat meer kleuren gebruikt worden dan dat je gevraagd hebt. In ieder geval vind ik dit prettig werken. De kleuren die ik heb opgegeven, mogen natuurlijk altijd wat donkerder en/of lichter. Het is maar een indicatie, en ik zou er blij mee zijn als deze kleuren gebruikt werden. Overigens zou ik tevreden zijn met elke logische opmaak van de syntax highlighter. Als je nog verdere hulp nodig hebt, en eventueel de overige talen, ik kan nog wel wat hulp leveren.

Nu hopen dat ik niks vergeten ben, en dat alles klopt wat ik gezegd heb. Zo niet, wijs me erop en ik pas het aan.

[Erkens]

tomatoman schreef op donderdag 25 november 2004 @ 19:35:
Code highlighting hoort natuurlijk de standaard Delphi syntax highlighting te reproduceren:
• reserved words vetgedrukt

alleen jammer dat mozilla dat "verkeerd" renderd
[rml][ bug] regelnummering bij PHP blok[/rml]

[Wolfboy]

dev icey schreef op vrijdag 26 november 2004 @ 00:18:
[....]
Het verplichte lijstje
Mijn lijstje komt er als het goed is dan zo ongeveer eruit te zien:

code:

code_keyword    #ff8000
code_special    #ff8000
code_ident  #408080
code_number #ff0000
code_method #0000ff
code_string #ff0000
code_comment    #b6b6b6
code_preproc    #0000ff

Ik moet zeggen dat ik je kleuren niet lelijk vind maar wel een beetje erg bleek, op mijn laptop is dat toch een heel stuk minder goed te zien (of ik moet m'n scherm wat draaien)
Imho iig te flets en te onopvallend.

[Morrar]

Misschien lichtelijk off-topic, maar als we dan toch met code tags bezig zijn... Als je in FireFox de text-size aanpast (CTRL + scrollwheel bijv), dan schaalt de code anders dan de regelnummers. Het gevolg is dat de nummering niet meer klopt. De nummers komen soms tussen de regels in te staan. In IE6 staat de font-size van beiden vast en gaat het wel goed... Bugje?

Wat betreft de kleuren: mij maakt het niet zoveel uit als het maar duidelijke kleuren zijn. De highlighting zoals ie nu is vind ik helder. Ben zelf gewend aan het schema van UltraEdit, maar vind omschakelen ook niet zo'n punt

//Edit:
Ik ben het qua kleuren eens met dev icey, weinig aan zijn post toe te voegen

[ Voor 8% gewijzigd door Morrar op 26-11-2004 00:52 ]

[Tomatoman]

Zijn die PHP-highlighters eigenlijk altijd van die 'domme' dingen? Het lijkt erop dat ze nog nooit gehoord hebben van cursieve tekst, iets waar highlighters in andere programmeeromgevingen al sinds jaar en dag gebruik van maken. Door vette en cursieve opmaak te gebruiken kun je ook wat minder scheutig met kleurtjes omspringen, zodat de tekst er op je een stuk rustiger uitziet zonder aan leesbaarheid in te boeten.

* Tomatoman vindt de kleurschema's van PHP-code over het algemeen een hoog kleuterschoolgehalte hebben

[ Voor 4% gewijzigd door Tomatoman op 26-11-2004 00:59 ]

[SuperRembo]

Ik vind cusieve tekst op een beeldscherm echt niet prettig lezen. Van vette tekst hou ik in code ook niet zo.
Ik gebruik liever Andale mono in plaats van Courier.
Verder heb ik commentaar altijd grijs en keywords blauw.

code:

code_keyword    #0000ff
code_special    #800000
code_ident  #000080
code_number #800080
code_method #000080
code_string #008000
code_comment    #808080
code_preproc    #ff0000

Maar met optie 1 is ook prima te leven. Het is niet zo dat je uren achter elkaar naar lappen code op GoT zit te staren.

[Tomatoman]

Ik vind cursieve tekst uitstekend lezen als hij alleen voor commentaar wordt gebruikt. Het commentaar is zo duidelijk te onderscheiden van de overige code.

[Verwijderd]

dev icey schreef op vrijdag 26 november 2004 @ 00:18:
De basis
Roze voor strings is bijvoorbeeld “not done”, net als kleuren als geel. Dit is gewoon totaal onleesbaar en ook nog eens irritant.
Kijk maar naar dit voorbeeld:
[afbeelding]

Met je opmerking over geel ben ik het wel eens (althans, geel op wit, want dat heeft natuurlijk te weinig contrast om goed zichtbaar te zijn), maar waarom is roze volgens jou `not done'? Heb je daar een reden voor of ben je gewoon homofoob? Het contrast is goed genoeg (de string valt voldoende op), en al zou het niet mijn eerste keus zijn omdat de kleur toch iets te licht is, verder is het gewoon een kleur als elke andere. Ik zie geen principiële bezwaren tegen de kleur roze.

Iets waar je ook aan moet denken is dat je voor typen code die veel voorkomen, je de beste kleuren moet gebruiken.

Dat lijkt me een redelijk tautologische opmerking. Natuurlijk moet je uit alle alternatieve `de beste' kiezen. Maar wat zijn volgens jou de beste kleuren dan?

Een plaatje van het totaal zegt meer dan honderd woorden:
[afbeelding]

Breng je dit nou als voorbeeld van hoe het wel moet, of van hoe het niet moet?

Ik vind dit namelijk behoorlijk onoverzichtelijk, aagenzien zo'n beetje alles in roodtinten is (rood danwel oranje). En er zit zwart door, maar aangezien zwart niet een kleur is die opvalt kun je dat niet echt als dominante kleur tellen. Symbolen en zo zou ik zwart maken (tokens die niet direct een belangrijke betekenis hebben), geen keywords. Oh, en er bengelt onderaan nog een blauw woordje.

Ik vind dit dus geen duidelijk kleurenschema.

[dev icey]

Verwijderd schreef op vrijdag 26 november 2004 @ 04:04:
[...]

Met je opmerking over geel ben ik het wel eens (althans, geel op wit, want dat heeft natuurlijk te weinig contrast om goed zichtbaar te zijn), maar waarom is roze volgens jou `not done'? Heb je daar een reden voor of ben je gewoon homofoob? Het contrast is goed genoeg (de string valt voldoende op), en al zou het niet mijn eerste keus zijn omdat de kleur toch iets te licht is, verder is het gewoon een kleur als elke andere. Ik zie geen principiële bezwaren tegen de kleur roze.

Waarom ben ik nou weer gelijk een homofoob als ik zeg dat roze niet kan? Mijn god, als ik iets een irritante kleur vindt dan krijg ik gelijk de stempel van homohater op mijn hoofd gedrukt ofzo. In iedergeval gaat het mij erom, dat ik het in het rijtje van geel plaats (of ben ik nu weer een bananenhater ). Ik vind het slecht leesbare kleuren op een witte achtergrond, en ze leiden gewoon heel erg af.

[...]

Dat lijkt me een redelijk tautologische opmerking. Natuurlijk moet je uit alle alternatieve `de beste' kiezen. Maar wat zijn volgens jou de beste kleuren dan?

Ik zie de tautologie er niet in? In dit stukje praatte ik nog niet eens over kleuren, alleen wat over de basis. Het gaat er hier gewoon om, dat je bepaalde goed leesbare kleuren, die ook op een goede manier opvallen, gebruiken voor de typen code die het meest voorkomen. Hier vind ik dus als voorbeeld variabelen in de kleur zeegroen, die ik al gaf. Variabelen komen meestal veel voor in stukken code. Net zoals de string, vandaar dat ik die de kleur rood wil geven. Het valt wel op, maar ik vind het er juist prettig ervan als de string opvalt. Omdat het toch een basisonderdeel is.

[...]


Breng je dit nou als voorbeeld van hoe het wel moet, of van hoe het niet moet?

Dit is als voorbeeld hoe ik vind dat het wel moet.

Ik vind dit namelijk behoorlijk onoverzichtelijk, aagenzien zo'n beetje alles in roodtinten is (rood danwel oranje). En er zit zwart door, maar aangezien zwart niet een kleur is die opvalt kun je dat niet echt als dominante kleur tellen. Symbolen en zo zou ik zwart maken (tokens die niet direct een belangrijke betekenis hebben), geen keywords. Oh, en er bengelt onderaan nog een blauw woordje.

Ik heb inderdaad maar 2 roodtinten gebruikt, waar je overigens aardig het verschil tussen kan zien. Die oranje is overigens nu erg dominerend, omdat ik een class heb zitten schrijven waar dus veel oranje in komt. Over dat blauwe woordje, kan ik niet veel zeggen. Het wordt gebruikt voor de preprocessor, als je kan zien in de TS.

Ik vind dit dus geen duidelijk kleurenschema.

En wie ben ik om te zeggen dat je dat wel moet vinden.

Wolfboy schreef op vrijdag 26 november 2004 @ 00:32:
[...]
Ik moet zeggen dat ik je kleuren niet lelijk vind maar wel een beetje erg bleek, op mijn laptop is dat toch een heel stuk minder goed te zien (of ik moet m'n scherm wat draaien)
Imho iig te flets en te onopvallend.

Overigens ligt dit waarschijnlijk aan de verschillende contrast instellingen, en of laptop scherm. Aangezien ik niet weet welk scherm je hebt, kan ik hier niet over oordelen.

Overigens is het zo, dat ik zelf aan dit kleurenschema gewend ben. Ik werk er al weer een tijd mee, dus vandaar dat ik het zelf een goed schema vind. Ik moest er in het begin ook aan wennen, na mijn overstap. Maar nu werkt het juist erg prettig.
Overigens kunnen de kleuren per beeldscherm verschillen. Je hebt al gauw dat als je een ander contrast dan ik heb, dat je de kleuren juist erg donker of juist weer te licht vindt. Ik denk dat het vooral met laptopschermen verschilt, aangezien ik zelf achter een crt zit.

[crisp]

Erkens schreef op vrijdag 26 november 2004 @ 00:20:
[...]

alleen jammer dat mozilla dat "verkeerd" renderd
[rml][ bug] regelnummering bij PHP blok[/rml]

Dat heb ik op weten te lossen

tomatoman schreef op vrijdag 26 november 2004 @ 00:59:
Zijn die PHP-highlighters eigenlijk altijd van die 'domme' dingen? Het lijkt erop dat ze nog nooit gehoord hebben van cursieve tekst, iets waar highlighters in andere programmeeromgevingen al sinds jaar en dag gebruik van maken. Door vette en cursieve opmaak te gebruiken kun je ook wat minder scheutig met kleurtjes omspringen, zodat de tekst er op je een stuk rustiger uitziet zonder aan leesbaarheid in te boeten.

* Tomatoman vindt de kleurschema's van PHP-code over het algemeen een hoog kleuterschoolgehalte hebben

Bold en cursief zijn wel degelijk mogelijkheden aangezien dat gewoon met CSS te regelen is

[Erkens]

crisp schreef op vrijdag 26 november 2004 @ 08:41:
[...]

Dat heb ik op weten te lossen

dat staat er ja, maar het verteld me niet of je dat hebt opgelost door "bold" te dumpen of door iets anders

verder vind ik "scheme 1" zeer duidelijk

[crisp]

Erkens schreef op vrijdag 26 november 2004 @ 08:51:
[...]

dat staat er ja, maar het verteld me niet of je dat hebt opgelost door "bold" te dumpen of door iets anders

verder vind ik "scheme 1" zeer duidelijk

In de CSS heb ik nu expliciet nog een line-height: 100% toegevoegd, en dan gaat bold wel goed in Mozilla

[Verwijderd]

Zelf vind ik scheme 1 ook erg duidelijk; hoewel ik zoals eerder genoemd is het commentaar grijs maken. Oftewel #880088 wordt dan #888888. Dat geeft wat meer rust binnen de code en wordt de aandacht gevestigd op de code ipv het commentaar.

[Erkens]

Verwijderd schreef op vrijdag 26 november 2004 @ 08:58:
Zelf vind ik scheme 1 ook erg duidelijk; hoewel ik zoals eerder genoemd is het commentaar grijs maken. Oftewel #880088 wordt dan #888888. Dat geeft wat meer rust binnen de code en wordt de aandacht gevestigd op de code ipv het commentaar.

zelf vind ik commentaar belangrijker dan de code opzich, zeker als je code van andere moet bestuderen. Een grijs kleurtje valt in dat geval niet goed genoeg op en leest vrij ongemakkelijk imo.

crisp schreef op vrijdag 26 november 2004 @ 08:52:
In de CSS heb ik nu expliciet nog een line-height: 100% toegevoegd, en dan gaat bold wel goed in Mozilla

vage engine

[.oisyn]

tomatoman schreef op donderdag 25 november 2004 @ 19:35:
Een jaar geleden heb ik alle regels voor syntax highlighting in Delphi - inclusief een lijst met reserved words - vastgelegd in een Word-document. Zie dit maar als een hint voor crisp en .oisyn

Euh, Delphi wordt allang ondersteund in de nieuwe highlighter hoor. Zie dit maar als een hint voor tomatoman

[ Voor 49% gewijzigd door .oisyn op 26-11-2004 10:20 ]

[Annie]

Kleuren op het forum? Lekker belangrijk

Voor je editor, waar de hele dag naar zit te staren, kan ik me nog wel voorstellen dat het helemaal perfect moet zijn. Maar voor het forum maakt het me allemaal niet zoveel uit. Als er wat kleurtjes in zitten is het mooi meegenomen.

Get a life

[Tys]

code:

code_keyword    #007700
code_special    #0000BB
code_ident  #0000BB
code_number #0000BB
code_method #0000BB
code_string #DD0000
code_comment    #FF8000
code_preproc    #007700

Lekker default (PHP highlight)

Edit: { } ( ) en ! tekens vallen nergens onder?

[ Voor 11% gewijzigd door Tys op 26-11-2004 11:24 ]

[JayVee]

Ik vind zelf schema 2 het prettigst. Zelf heb ik strings dan nog eens grijs, aangezien het voor de meeste apps alleen "data" is. In strings kan niets misgaan. Bbehalve als je

PHP:

 echo "bla $var bla"

schrijft, wat ik toch al lelijk vind.

Mijn voorkeur dus duidelijk schema 2, het liefst met grijse strings:

code:

code_keyword    #0000ff
code_special    #800000
code_ident  #000080
code_number #800080
code_method #000080
code_string #777777
code_comment    #008000
code_preproc    #ff0000

Oh, en wat mij ook net opvalt is dat [code=php ] blokjes beginnen met <? ipv <?php!

[-FoX-]

Ikzelf kan me het beste vinden met:

code:

code_keyword    #0000FF
code_special    #9900FF
code_ident      #000099
code_number     #990099
code_method     #009900
code_string     #CC0000
code_comment    #999999
code_preproc    #FF0000

Maar ik denk dat dat wel een groot deel afhangt van persoonlijke smaak. Ik althans, vind de code zo het leesbaarst.. in elke taal!

[curry684]

.oisyn schreef op donderdag 25 november 2004 @ 17:59:
[...]

JS, CSS en HTML highlighters staan op de todo lijst, maar aangezien niemand zin heeft om de flex syntax aan te leren ben ik de enige die het toe kan voegen, en ik heb over het algemeen wel wat anders te doen

Ik had een SQL highlighter ook nog ergens op de todo staan

* curry684 verkiest overigens schema 2, dat zijn namelijk Visual Studio colors

[RayNbow]

Ik zou schema 2 prima vinden, maar 't volgende schema (NetBeans)...
 

code:

code_keyword    #000099
code_special    #800000
code_ident      #000000
code_number     #780000
code_method     #000000
code_string     #99006b
code_comment    #737373
code_preproc    #000099

code_keyword    vet
code_method     vet
code_comment    cursief

...vind ik ook wel goed.

[Tomatoman]

.oisyn schreef op vrijdag 26 november 2004 @ 10:16:
[...]


Euh, Delphi wordt allang ondersteund in de nieuwe highlighter hoor. Zie dit maar als een hint voor tomatoman

als het goed werkt. Op dit moment zie ik nog dit:

Delphi:

if (Edit1.Text <> '') and (Edit2.Text <> '') then
begin
  try
    Form1.Client.Host := Edit2.Text;
  except
    on E: EMijnVerkeerdeHostError do
    begin
      { zomaar wat commentaar }
      ShowMessage('Verkeerde hostnaam - de host wordt ingesteld op 127.0.0.1');
      Form1.Client.Host := '127.0.0.1';
    end
    else
      raise; // bla bla bla
  end;
  try
    Form1.Client.Port := StrToInt(Edit1.Text);
  except
    Form1.Client.Port := 123; // nog meer geblaat
  end;
  Form1.Client.Connect;
end;

Op regel 4, 6, 10, 13, 16, 18 en 20 gaat het helaas mis - hier worden de reserved word/ standard directives zoals 'on', 'or' en 'in' middenin een woord gehighlight. Als dat is opgelost vind ik het helemaal geweldig en zou ik zelfs kleuterschoolkleurtjes voor lief nemen

[.oisyn]

Hmm vaag, dat zou ie helemaal niet mogen doen. De rest van de highlighters doen dat ook niet, en daar is de Delphi highlighter toch op gebaseerd

.edit: heel erg vaag, dezelfde highlighter staat ook op mijn website en daar werkt hij dus wel goed. Gooi je code maar eens hierdoorheen: http://www.oisyn.nl/tests/hl.php

* .oisyn kijkt naar crips

[ Voor 41% gewijzigd door .oisyn op 26-11-2004 13:42 ]

[Twilight Burn]

Zelf vind ik schema 2 het mooist, alleen heb ik dan liever strings rood dan roze, iets als:

code:

code_keyword    #0000ff
code_special    #800000
code_ident  #000080
code_number #800080
code_method #000080
code_string #ff0000
code_comment    #008000
code_preproc    #000000

[crisp]

.oisyn schreef op vrijdag 26 november 2004 @ 13:37:
Hmm vaag, dat zou ie helemaal niet mogen doen. De rest van de highlighters doen dat ook niet, en daar is de Delphi highlighter toch op gebaseerd

.edit: heel erg vaag, dezelfde highlighter staat ook op mijn website en daar werkt hij dus wel goed. Gooi je code maar eens hierdoorheen: http://www.oisyn.nl/tests/hl.php

* .oisyn kijkt naar crips

ik heb volgens mij niets met de delphi.l gedaan, maar ik zal eens kijken

checked, maar de lexer_delphi.l die ik heb gebruikt is inderdaad gewoon het origineel

[ Voor 8% gewijzigd door crisp op 26-11-2004 14:21 ]

[Verwijderd]

Ik ben nu bezig met lexer_css.l, die kan binnenkort worden toegevoegd. Ik zal vanavond nog gebruiken om het een en ander te testen, en dan schiet ik hem wel naar .oisyn en/of crisp.

Ik moet er namelijk nog de standaard properties en bijzondere waarden aan toevoegen, anders ziet het er wat saai uit

[crisp]

Cheatah: thanks voor de lexer, maar helemaal perfect is hij nog niet:

css:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

/* GENERAL */ html {     color: #fff;     background-color: #c6c1b4; } body {     position: relative;     margin: 0;     padding: 0; } body, td, th, input, textarea {     font: normal 13px arial, helvetica, sans-serif;     color: #000; } input, select, textarea {     background-color: #fff; } a {     color: #000;     text-decoration: none; } a:hover {     color: #c00042;     text-decoration: underline; } a img {     border: 0 solid; } p {     margin: 13px 0; }

Het probleem met de delphi highlighting heb ik op weten te lossen door de windows newlines uit de lexer_delphi.l om te zetten naar *nix newlines en de boel opnieuw te compileren. Ik zal 'm met de eerstvolgende update meenemen.

[ Voor 13% gewijzigd door crisp op 28-11-2004 20:51 ]

[Verwijderd]

Lokaal @ devbak... Lijkt me prima zo

Het lijkt erop dat er ergens iets toch verkeerd gaat

[alienfruit]

Ik wil gewoon dat je de kleuren kan instellen in myreact of preferecnes

[crisp]

Verwijderd schreef op zondag 28 november 2004 @ 21:04:
[afbeelding]
Lokaal @ devbak... Lijkt me prima zo

Het lijkt erop dat er ergens iets toch verkeerd gaat

Flex 2.5.4, GCC 3.3.4 onder Slackware 10. Gewoon de lexer_css toegevoegd aan het rijtje in makefile en make highlighter gedaan

[Erkens]

alienfruit schreef op zondag 28 november 2004 @ 21:10:
Ik wil gewoon dat je de kleuren kan instellen in myreact of preferecnes

abo nemen en eigen css gebruiken

[Verwijderd]

Hoe zit het met html, css en javascript in hetzelfde code stuk? Gaat dat ook werken?

[Wolfboy]

Verwijderd schreef op zondag 28 november 2004 @ 23:42:
Hoe zit het met html, css en javascript in hetzelfde code stuk? Gaat dat ook werken?

Het is relatief eenvoudig om te laten scannen op <script en <style dus in theorie moet het kunnen.
Of de devvers het ook gaan doen is maar de vraag
Dan zou er eigenlijk ook direct op php, asp en andere talen gecontroleerd moeten worden

[crisp]

crisp schreef op zondag 28 november 2004 @ 23:29:
[...]

Flex 2.5.4, GCC 3.3.4 onder Slackware 10. Gewoon de lexer_css toegevoegd aan het rijtje in makefile en make highlighter gedaan

Na een find . -type f -maxdepth 1 -print | xargs sed -i 's/^M$//' is het me gelukt een versie te compileren die het met CSS ook goed doet

[Tomatoman]

crisp schreef op zondag 28 november 2004 @ 20:51:
Het probleem met de delphi highlighting heb ik op weten te lossen door de windows newlines uit de lexer_delphi.l om te zetten naar *nix newlines en de boel opnieuw te compileren. Ik zal 'm met de eerstvolgende update meenemen.

Dankuwel Sinterklaas! Dit stond bovenaan mijn verlanglijstje

[pjvandesande]

alienfruit schreef op zondag 28 november 2004 @ 21:10:
Ik wil gewoon dat je de kleuren kan instellen in myreact of preferecnes

Daar was ik ook al voorstander van

* pjvandesande kiest toch maar gewoon voor scheme #2.