[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:       2012-11-19 17:58:34
Message-ID: 1542176.X5X87bj5Mi () milian-kdab2
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 18 November 2012 13:35:26 Dominik Haumann wrote:
> Hi,
> 
> several times we've discussted that the default styles list should be
> extended. Currently, the default styles list is a flat list. I'd keep it
> that way in the implementation. Still, in the UI, I'd like to have a tree
> to categorize our default styles.
> The following is a first idea of how it could look like, along with new
> default styles:
> 
> Text
> - dsNormal
> - dsKeyword
> - dsFunction
> - dsDataType
> - dsArgument    (new, complement for dsDataType, e.g. int var;)

And _var_ would be highlighted with dsArgument?

> - dsChar
> - dsString
> - dsOthers
> - dsError
> - dsScope       (new, needed? maybe \begin{...} \end{...} in tex)

Could probably also be used for namespaces then in KDevelop?

Generally, could we plug in custom colors there so the user has one place 
where he could define everything? That would be *very* much appreciated.

Here are the colors we add on top in KDevelop, some of them are also quite 
generic imo and could be supported in Kate directly:

Class (struct _Foo_ {}; could be dsOthers but that name is just bad imo 
essentially we want two different colors, one for built-in data types 
(dsDataType) and one for user defined types)
TypeAlias (using _foo_ = int; or typedef int _foo_;)
Enum (enum _Foo_ {};)
Enumerator (enum Foo{ _Bar_ };)
Function (int _main_() {} - could be dsFunction)
MemberVariable (struct Foo { int _Bar_; };)
LocalClassMember (struct Foo { int Bar; Foo() : _Bar_() {} };)
InheritedClassMember (struct Foo { int f; }; struct Bar : Foo { Bar() : _f_() 
{}};)
LocalVariable (int main() { int _i_; })
FunctionVariable (function argument, could be dsArgument)
NamespaceVariable (namespace foo { int _bar_; })
GlobalVariable (int _bar_;)
Namespace (could be dsScope)
ErrorVariable (could be dsError)
ForwardDeclaration (struct _foo_;)

<snip>

> Comments & Documentation
> - dsComment
> - dsDescription (new, e.g. @brief in doxygen, or """ in Python?)
> - dsCommand     (new, e.g. doxygen commands @param, etc...)
> - dsVariable    (new, e.g. doxygen @param foobar)
> - dsRegionMarker

Description, Command and Variable sound too generic, if they are supposed to 
be used by Comments & Documentation only, no?

> Notifications
> - dsAlert
> - dsPositive    (new, e.g. NOTE)
> - dsInformation (new, e.g. TODO)
> - dsWarning     (new, HACK, ###)
> 
> The categorization might make sense for indenters to get the correct context
> (e.g. are we in a comment or in a string or in source code?).
> With this motivation, dsOthers etc. should not be used in comments, instead,
> it should simply be dsComment.
> 
> This is just a draft, and I'm sure it's not that good ;)

-- 
Milian Wolff
mail@milianw.de
http://milianw.de
["signature.asc" (application/pgp-signature)]

_______________________________________________
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]