--===============8968713482399599797== Content-Type: multipart/alternative; boundary=001a11c322c0f9c17104f2ae7516 --001a11c322c0f9c17104f2ae7516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-02-17 23:49 GMT+01:00 Milian Wolff : > Can you elaborate why you want to have [dsBuiltin], and how it differs fr= om > dsKeyword, dsFunction, dsConstant? > dsKeyword: keywords. class, if, else, break, continue, match, switch, yield, function, def, try, raise, =E2=80=A6 dsFunction: function/method declarations, i.e. the function name after the function keyword: defun =E2=80=A6, String =E2=80=A6() {}, function =E2=80= =A6() {}, def =E2=80=A6(): 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, =E2=80=A6, http://golang.org/pkg/builtin/ i agree, dsBuiltinValue is maybe to much. those are special constants/singletons like true, false, null, =E2=80=A6 we could highlight t= hem as constants or keywords. but i still definitely want dsBuiltin! At least JavaScript and C++ don't have it. PHP has it though. Anyhow, this > depends on semantic analysis (see my other email) and maybe needs a > different > approach. That said, why would one want to highlight exceptions different= ly > from other objects? Where is this useful to know directly whether a type = is > actually an Exception? > the python highlighting has the builtin exceptions highlighted, which is useful for knowing that you spelled them wrong. but probably overkill and better done with completion. --001a11c322c0f9c17104f2ae7516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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?

dsKe= yword: keywords. class, if, else, break, continue, match, switch, yield, fu= nction, def, try, raise, =E2=80=A6

dsFunction: function/metho= d declarations, i.e. the function name after the function keyword: defun = =E2=80=A6, String =E2=80=A6() {}, function =E2=80=A6() {}, def =E2=80=A6():=

dsConstant: NAMES_WITH_UNDERSCORES per convention

<= div>dsBuiltin: functions, classes, etc. which are defined in the default na= mespace: e.g. http://docs.python.org/3.3/library/functions.html and the types like i= nt, set, =E2=80=A6, http://golan= g.org/pkg/builtin/

i agree, dsBuiltinValue is maybe to much. those are special = constants/singletons like true, false, null, =E2=80=A6 we could highlight t= hem as constants or keywords.

but i still definitely want= dsBuiltin!

At least JavaScript and C++ don't have it. PHP has it though. Any= how, this
depends on semantic analysis (see my other email) and maybe needs a differe= nt
approach. That said, why would one want to highlight exceptions differently=
from other objects? Where is this useful to know directly whether a type is=
actually an Exception?

the python highl= ighting has the builtin exceptions highlighted, which is useful for knowing= that you spelled them wrong. but probably overkill and better done with co= mpletion.

--001a11c322c0f9c17104f2ae7516-- --===============8968713482399599797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============8968713482399599797==--