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

List:       kwrite-devel
Subject:    Re: Default Styles
From:       Milian Wolff <mail () milianw ! de>
Date:       2014-02-17 22:09:45
Message-ID: 1435309.5e8sfyFkjS () minime
[Download RAW message or body]

On Monday 17 February 2014 22:43:08 Dominik Haumann wrote:
> Some time ago, I've made a list of default styles. This list is now extended
> by the few additions proposed in the last thread. Further, I think it makes
> a lot of sense if we add categories. These categories should be followed
> when using a default style (i.e. one should not use dsFunction in a
> comment).

Wooh, I so hope we get this in sooner rather than later! Awesome work, 
everyone involved - thanks a ton!

> The current list looks as follows:
> Legend:
>  '-': already exists
>  '+': new, and makes a lot of sense
>  '?': new, really needed?
> 
> Text
> - dsNormal
> - dsKeyword
> + dsExtension   (new, same as keyword, e.g. Qt, tr1, and other extensions)

This is problematic imo. Extension to what? A new function? A new data type? 
Has anyone a suggestion how to handle this? Otherwise, better have one 
extension than none at all.

> + dsControlFlow (new, or dsStructure, if, else, switch, continue)
> - dsFunction
> - dsDataType
> + dsVariable    (new, $bla in php or perl, or dsIdentifier?)

A class identifier is also an identifier. dsVariable sounds good to me.

> ? dsSection     (new, e.g. [general] in ini file, or \section in LaTeX)

Could use dsControlFlow as well?

> Strings
> - dsChar
> - dsString
> ? dsRawString   (new, '' in Perl, CoffeeScript and Bash, r'' or r"" in
> Python)

Personally, I don't see the need for this. A raw string is a string. What one 
might want to highlight in a different format is the surrounding stuff which 
makes it "raw" but there one could use some other highlight, such as 
dsKeyword, dsOperator, ... Also note that this applies equally to 
heredoc/nowdoc syntax as exists in bash, PHP, Perl, ...

> + dsRegExp      (new, JavaScript and other languages heavily rely
> on it) ? dsRegExpOp    (new, RegExp semantics: ^\., [:space:], ...)

This, I like. Perl and JavaScript are already two widely used languages with 
this feature. There are probably others I don't know of. And maybe we'll get a 
standardized string literal for regexes in C++ in some years as well - who 
knows.

> Numbers
> - dsDecVal
> - dsBaseN
> - dsFloat
> + dsOperator    (new, for +-*/::<> etc..., lots of languages define this)
> ? dsConstant    (new, if needed? maybe M_PI or similar things? not sure...)

dsConstant could be used for enums in languages which have them. So +1 from my 
side.

> Misc
> - dsOthers
> ? dsLink        (new, url, path)

Bot sure about this one, personally. This is mostly useful for text formats 
like Markdown, which don't have a lot of other highlighting features and could 
just use one of them as basis for the custom dsLink then, no?

> ? dsDeprecated  (new: maybe for deprecated stuff?)

Similar to extension, this is more of an "on-top" attribute. I.e. I'd expect a 
deprecated data type to look still look like a data type, but the same would 
apply to a function etc. pp. So maybe we need a new concept for such 
attributes? Deprecated could add a strike-through effect. Extensions could 
change the color. Suggestions anyone?

> Comments & Documentation
> - dsComment
> + dsDescription (new, e.g. @brief in doxygen, or """ in Python?)
> + dsAnnotation  (new, e.g. @... in Java, @param in Doxygen)
> + dsCommentVar  (new, e.g. foobar in "@param foobar", etc...)
> ? dsExample     (new, e.g. @code ... @endcode, or dsVerbatim ? )
> - dsRegionMarker
> 
> Notifications
> - dsError
> - dsAlert
> ? dsPositive    (new, e.g. NOTE)
> ? dsInformation (new, e.g. TODO)
> ? dsWarning     (new, HACK, ###, FIXME)

Imo, dsAlert + dsError are enough, no? HACK, FIXME, ### are imo dsError's. 
Note and TODO are dsAlerts.

> This makes 8 new default styles (+), and again 10 new default styles marked
> with "?".
> 
> 
> I'm currently not convinced of:
> ? dsInterface: C# interfaces, Scala mixins, declarations, protocols
> ? dsReference: Markdown links, C pointers, LaTeX refs

same as dsLink above, no?

> ? 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, ...
> ? dsBuiltinValue
> ? dsBuiltinFunction

These are either keywords (which are builtin) or plain functions/datatypes. 
There should be no difference in highlighting whether I call a custom function 
or a built-in imo.

> ? dsException: Often with Exception or Error in the name

-1 from my side as well.

> ? dsSymbol

-1 here as well - too generic, everything is a symbol.

> I think it would be nice to discuss this a bit, update the list again, and
> then add at least the default styles that we agree on.
> 
> The big question is:
> Will these default styles enable us to ditch many/most of the hard-coded
> colors? (I have not checked in detail)

I'll write another mail to this but start a new thread in regard to KDevelop 
languages.

Cheers, and thanks everyone again!
-- 
Milian Wolff
mail@milianw.de
http://milianw.de
_______________________________________________
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]