whoops, didn’t get the round 2. OK. all together:

1. 2014-02-17 23:49 GMT+01:00 Milian Wolff <mail@milianw.de>:
   
    > Can you elaborate why you want to have [dsBuiltin], and how it differs from
    > dsKeyword, dsFunction, dsConstant?

    * dsKeyword: keywords. class, if, else, break, continue, match, switch, yield, function, def, try, raise, …
    * dsFunction: function/method declarations, i.e. the function name after the function keyword: defun …, String …() {}, function …() {}, def …():
    * dsConstant: NAMES_WITH_UNDERSCORES per convention
    * dsBuiltin: functions, classes, etc. which are defined in the default namespace: e.g. http://docs.python.org/3.3/library/functions.html and the types like int, set, …, http://golang.org/pkg/builtin/

    i agree,  is maybe to much. those are special constants/singletons like true, false, null, … we could highlight them as constants or keywords.

    i still definitely want dsBuiltin!

2. dsBuiltinValue, dsValueKeyword or dsLanguageConstant are all the same thing, and imho preferable to dedicated dsBoolean, dsNull, dsEllipsis, …

3. eureka! i’ve got an idea about rawString and specialString/regex:

    how about dsVerbatimString and dsSpecialString (as well as dsSpecialChar) both?

    dsVerbatimString could be used for raw strings and markup verbatim sections and dsSpecialString/Char for LateX math mode and regexes (and their special escape sequences inside).

    i think that’s best, because ruby, perl, and coffeescript (at least) all have both raw strings and literal regexes, and dsVerbatimString is a more versatile name as “raw string”.