> 1* Review all (some/many/most) XML syntax and unify them.

Yes, I really wish we'd do that...

> 2* Consider expanding the default set of "Color Elements" that have particular colors (like "Control Structures", "Constants" and "Variables") so all languages that have them will be uniform.

This might be harder, we are already eeking by with the color roles we have in KDE4. New "styles" will either necessarily match existing styles, or else will have to differ by default in formatting only. (Though, that's already true of keywords, so maybe not a big deal...)

Matthew,

i think i was not clear about my 2nd item: on Settings > Fonts & Colors, there is a tab called "Normal Text Style", which have a series of items that have a particular style. All syntaxes uses these items as a base value.

However, this list is limited and dont include some common stuff found on languages (like "Control Structures", "Constants" and "Variables"), forcing the syntax for some languages to be customized to include such particular items.

I propose to expand this list, so many languages can refer to a broader list of default styles. I might suggest to include all common structures:
* Control Structures (to be used on if clauses and loop structures)
* Constants
* Variables (since some languages have a clear identification)
* Build-in Functions (print(), echo() and time() on many languages)
* String Escapes (\n, \t and company)
* Operators (+ - * / and or && ! ||)

C++, PHP, Python, Ruby, XML and Lua have at least one of these items as a custom style.

> i think i was not clear ...

I understood, I was simply pointing out why "fixing" this might be technically difficult.

(Hmm... but maybe we could use faded-out flavors of some color roles, like Active, Link, etc?)

On torsdag 10 April 2008, Matthew Woehlke wrote:
> (Hmm... but maybe we could use faded-out flavors of some color roles, like
> Active, Link, etc?)


Please no. Those rarely becomes very usable, and you can't know if they have 
high or low contrast to the background (for example active text is about 
guaranteed to be useless with normal color schemes, and combining active 
background with active text is a guaranteed disaster, as active text can not 
be specified but is calculated from active background in a bad way).

Personally I agree with the reporter, we should add to kateparts palette of 
predefined roles.

> Please no. Those rarely becomes very usable, and you can't know if they have high or low contrast to the background [...]

I didn't say it was a *great* idea... I'm fishing here.

> for example active text is about guaranteed to be useless with normal color schemes [...]

Umm... why?

> [...] as active text can not be specified but is calculated from active background in a bad way

Huh? Active text is specified. Active background is based on Normal background plus Active text, but it's like that for all background roles except Alternate.

> Personally I agree with the reporter  [...]

Eh? I didn't say I disagreed... but we're already making use of all color roles KColorScheme provides. If you have a suggestion how to add kate roles in a colorscheme-safe manner, I'd be glad to hear them. (I must admit that adding roles to KCS isn't my first choice. Aside from questions of what fallout that might have across KDE, it's hard enough to pick out distinct colors to make schemes with the roles we have.)

On fredag 11 April 2008, Matthew Woehlke wrote:

Maybe I am partially wrong. I hope so. The current default color schemes does 
not work well, and the calculated color can't be guaranteed to work, imo it's 
most likely not to.

> The current default color schemes does not work well

Are we talking katepart or KDE? What specifically is wrong with it?

On Monday 14 April 2008, Matthew Woehlke wrote:
> Are we talking katepart or KDE? What specifically is wrong with it?


The contrast using the activetext background and foreground is so bad that the 
text rendered is hard to see, and it is hiding rather than standing our from 
the surrounding normal text. (katepart, using directional word completion, 
type a letter and press c-8 or c-9 with word completion plugin enabled)

Guys,

since reviewing ALL syntax XMLs would be painful (and it would take quite a while), i suggest to focus on <a href="http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html">the 10 most-popular-languages rank</a> by <a href="http://www.tiobe.com">TIOBE</a>, which (today) are: Java, C, (Visual) Basic, PHP, C++, Perl, Python, C#, Ruby, Delphi and JavaScript.

Once the new color roles (or whatever the solution is), i can help on converting the XMLs. They must be not only be converted to the new color scheme, but also contain the color roles that were not previously assigned (if PHP doenst highlight the functions or Python doesnt highlight the float numbers, we must create them).

regards,

massa

Guys,

with several changes in Plasma, KDE libs and Kate itself, its now possible to advance on this?

I reiterate that i can help on some labor work (if there is some need to focus on the main languages) on changing XML syntax files by hand. But i would need the implementation of more complete Color Palette.

best regards,

massa

Maybe we should first come up with a better list of dsXXX attributes. What is missing? What is really required? We should really make sure that the highlights are consistent, editing lots of syntax files by hand will be required, no matter what.

Since adding new attributes to an enum is not an issue for BC we can do this easily. Maybe I'll fix this in the feature freeze period. But I'd really appreciate it if you could go over syntax files and check:

- is the extra highlighting _really_ required?
- what dsXXX is missing? this should be some sort of semantic identifier, like dsKeyword, dsFunction etc. pp.

Intorducing more default styles it not really necessary: If you use e.g. <itemData name="Operator" defaultStyle="dsOthers" /> you still fall back to defaults. No real need for a new style.

Anyway, Matthew worked in this area and afaik Kate now uses partially colors from the KDE color scheme. So is this report still an issue? It's also getting very long and thus hard to track what this report is about ...

yes, very much an issue and I still hope to eventually fix it properly by introducing more default styles and also a read-only default style that always adapts to the current KDE scheme. If it is not read-only one doesn't know what to do with custom user-set colors.

The fix will look like the following:

Kate will ship a kateschemarc and katesyntaxhighlightingrc.
In that rc's we ship non-removable color schemes (the user still can edit them).

Per default we will have at least: Normal, Printing, KDE

Normal is the default, as "well choosen" set of colors that actually show up on normal LCD screens, not like now, where on most machines e.g. the line hl is not visible with the distribution shipped default color scheme.

Printing will be for printing, as name say, auto-default for "File -> Print" Dialog and normal printing. Use can  change to other scheme in the printing dialog.

KDE will be a scheme without any hardcoded colors in the rc files, just falling back to KDE default colors, if the users wishs.

We can ship some "Dark" color scheme, too, then, without any problems.

The remaining problem stays: inventing perhaps more default item styles to avoid the massive amount of hardcoded colors in the different highlightings.

Git commit 1abf862307c93f7d191eb4c37206e98338eac29d by Christoph Cullmann.
Committed on 03/11/2012 at 16:30.
Pushed by cullmann into branch 'master'.

Ship preconfigured Normal + Printing
Have a KDE schema to fallback to KDE color schema without any problems
Printing has NO black background 
BUG: 197911

M  +1    -1    part/data/CMakeLists.txt
M  +58   -0    part/data/kateschemarc
A  +47   -0    part/data/katesyntaxhighlightingrc

http://commits.kde.org/kate/1abf862307c93f7d191eb4c37206e98338eac29d

I guess we need to invent more default roles :) Volunteers?

*** Bug 181111 has been marked as a duplicate of this bug. ***

yeah, that was my proposal, too. i guess if we want to discuss it, we should collect all hardcoded colors, root out what could be expressed as existing color role, and consolidate the remaining hardcoded colors into a set of new roles.

so except if highlighting A has a hardcoded color for “Classes” and for “Octals”, we see that maybe (or maybe not) a new “class” role would be nice, while “Octals” could simply be changed to “dsBaseN”.

especially for languages like LaTeX, the current roles don’t really fit, and as result, the LaTeX scheme is a NIGHTMARE.

we could map quite a few (e.g. sectioning to dsKeyword, macros to dsFunction, verbatim to dsString and environments to dsRegionMarker), but some are still without even remotely matching role.

*except → e.g.

don’t know what i was thinking

if you could come up with some proposal, which new default styles we should have, that would be awesome. I just grepped in the .xml files and found around 576 matches for "itemData.*color=""

is there a official KDE wiki, where we can compile a list?
i think a community effort would be best.

You could start a page on http://community.kde.org , still I am not sure if that really helps a lot, as until now the community feedback was close to zero ;)

(In reply to comment #22)
> You could start a page on http://community.kde.org ,

done: http://community.kde.org/Kate#Color_role_consolidation

> still I am not sure if that really helps a lot, as until
> now the community feedback was close to zero ;)

i guess that’s because nobody really ever used other color schemes than the standard one, since it was such a big effort to do it. i hope in the future, more would like not to have unreadable code.

Move this to wishlist status.

(In reply to comment #23)
> i guess that’s because nobody really ever used other color schemes than the
> standard one, since it was such a big effort to do it. 

I use my own dark scheme... and it is always pain in the ... to configure colors using current UI :(
but I have to, cuz most syntaxes unreadable in dark schemes. it is why I've started to export and put all modified syntaxes into a github repo.

> i hope in the future,
> more would like not to have unreadable code.

constantly thinking (in background) about how to improve color support in kate :)
I hate the current UI...

Alex, the first step has to be an assessment of the necessary additional color roles.

what i think is necessary (at least, most likely more):

* dsDecorator or dsAnnotation (for @Annotations in python, java C#, rust, …)
* dsFormat (for string interpolation and formatting syntax like %s in many languages, $foo and ${bar} in shell, {0} in python, and #{} in ruby)
* dsSpecialRef (for this, self, super, parent, …)

but we have to find everything that’s necessary for most languages, then implement it in kate and the default color schemes, and then port all inconsistent language highlighting files.

e.g. the list for gnu source-highlight is: http://paste.kde.org/pc19b418f
calculated via: source-highlight --lang-list | cut -d " " -f 3 | xargs -n 1 source-highlight --show-lang-elements | sort -u

Dear user,

this wish list item is now closed, as it wasn't touched in the last two years and no contributor stepped up to implement it.

The Kate/KTextEditor team is very small and we can just try to keep up with fixing bugs. Therefore wishs that show no activity for two years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users.

If you want your feature to be implemented, please step up to provide some patch for it. If you think it is really needed, you can reopen your request, but keep in mind, if no new good arguments are made and no people get attracted to help out to implement it, it will expire in two years again.

We have a nice website kate-editor.org that provides all the information needed to contribute, please make use of it. For highlighting improvements our user manual shows how to write syntax definition files.

Greetings
Christoph

we actually did the color role thing but still didn’t convert all the languages to the new system – there’s much hardcoded stuff left, but fewer than ever!

here’s the docs: https://docs.kde.org/trunk5/en/applications/katepart/highlight.html#kate-highlight-default-styles

Dear user, this wish list item is now closed, as it wasn't touched in the last year and no contributor stepped up to implement it.

The Kate/KTextEditor team is small and we can just try to keep up with fixing bugs.

Therefore wishes that show no activity for a years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users.
If you want your feature to be implemented, please step up to provide some patch for it.

If you think it is really needed, you can reopen your request, but keep in mind,
if no new good arguments are made and no people get attracted to help out to implement it,
it will expire in a year again.

We have a nice website https://kate-editor.org that provides all the information needed to contribute, please make use of it.

Patches can be handed in via https://phabricator.kde.org/differential/

Greetings
Christoph Cullmann

To elaborate on this: Indeed new default styles were added for control statements, constants, variables, etc... see blog post:
https://kate-editor.org/2014/03/07/kate-part-kf5-new-default-styles-for-better-color-schemes/

However, what's still open is to go over the ~300 highlighting files and fix hard-coded colors. I started with that once and fixed ~50 files, meaning there are certainly still >200 to go. But that's a lot of work. Volunteers welcome. I am in favor of keeping this bug closed, though, since this is a case-by-case fix needed for many files, and not a general thing anymore.