[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Syntax colouring
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2014-02-17 17:31:19
Message-ID: ldth0q$7ih$1 () ger ! gmane ! org
[Download RAW message or body]

On 2014-02-15 14:07, Philipp A. wrote:
> hi, glad that topic surfaces again!
>
> Firstly I'm against anonymous variants. Better let people use semantically
> slightly off target stuff and add more later, while having some sort of
> consistent colors that people can rely on. E.g. the string example: Let's
> just add dsRawString. that's '' in Perl, CoffeeScript and Bash, r'' or
> r""in Python and
> raw"" Scala.

...and long-brackets in CMake. And doesn't C++11 also have raw strings? 
So this seems at least widely used.

> dsPunct and dsOperator are fine additions. Furthermore I propose:

If you do add this, may I vote for dsSymbol rather than dsPunct?

>     - dsInterface: C# interfaces, Scala mixins, declarations, protocols

Hmm, not convinced.

>     dsReference: Markdown links, C pointers, LaTeX refs

C pointers? Really? How are you going to highlight those? (And no, I 
don't think you should try to highlight '*' and '&'; you'd have to do it 
differently when used in data types or unary operators vs. binary 
operators, and doing so is (a) going to be hard, and (b) liable to make 
the HL rules into an unmaintainable maze of complexity.)

Tons of markup formats will probably use this though, so I'd agree with 
adding it.

>     dsAnnotation: @annotationname in e.g. Java and Python, #[…] in rust
>      - dsConstant: THOSE_THINGS

Okay.

>     - dsBuiltin: Value keywords like Java's true, R's FALSE, Python's None,
>     JS' null, as well as Python's open, reversed, …, and Go's predeclared
>     identifiers like new, print, …
>     - dsException: Often with Exception or Error in the name
>
> Maybe even split up dsBuiltin into dsBuiltinValue, and dsBuiltinFunction,
> the latter of which also being used for special function names like
> operator* and __init__.

Hmm... I guess I can live with those.

While we're on this subject... something else that would be really nice 
is if the 'default' value for an included context was NOT the dsXYZ 
value, but the user-provided value for the HL (which itself may of 
course be the dsXYZ). And note that I include in that that the 'use 
default' check box.

That way I can tweak Doxygen to my liking and have those colors used by 
Python rather than having to configure them all over again.

-- 
Matthew

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel

[prev in list] [next in list] [prev in thread] [next in thread]