Post by David EmersonI've been able to create an inverted color scheme by editing
SciTEUser.properties as well as the language properties (e.g.
html.properties, pascal.properties, perl.properties, etc.)
Unfortunately, many of the language properties filters have
hard-coded colors instead of inheriting from the style hierarchy.
This is, in my opinion, bad style :-)
If you'd like, I can post the relevant lines from my
SciTEUser.properties, as well as the language properties files I use
(mostly pascal.properties, so the others are not as well tuned)
It would be great if these changes could be migrated into the
distribution version
Any requests? Shall I post them?
Why not, as long as the file is small...
Note that since quite a long time, I provide my own set of .properties
files (those I changed for my needs), for inspiration purpose.
My tastes may not fit all tastes, but can provide ideas.
It was there that I first experimented with $(color.*), using the idea
Neil had with font reuse. It took some time before Neil adopted the
idea, but since it provided consistency accross the various lexers, he
saw it was a good idea.
But I changed only the properties of the languages I use most, so I
suppose lot of .properties files are still in "raw" state.
And I still use hard-coded colors where:
- A style is specific to a language, hence it is not reusable in other
languages (eg. verbatim string in C#);
- Some color combination doesn't look good in a given language,
depending on the density of a given style, or how often a style is near
other styles, so I need to hand edit some colors.
Per personal taste, I use low contrast colors. Well, high contrast of
fore color against back color (avoiding putting pastel text on pastel
background...), but low contrast of fore styles between them:
I use black for plain text (HTML) or identifiers, dark blue for
keywords, dark colors for most other styles. I use reddish colors mainly
for warning purposes, like "End of line where string is not closed".
And background colors are mostly white (I have no problem with this
color) or pastel colors for embeded languages (in HTML) or some block
comments or literal strings.
Of course, such settings may not look good on another display, depending
on its contrast, luminosity, etc. And I still think we should be able to
choose a different set of styles for printing purpose, as the
requirements are different (I would use backcolors much less, higher
contrast, etc.). I never worked on this, because actually don't print
much listings, even less in colors. And of course, an alternative set of
properties could be designed for printing purpose, and a simple script
could switch the .properties files before and after printing.
Often, actually each time I hand-edit my styles, I think I would make a
tool to ease the editing of Scintilla styles.
One way to do it would be to use Scintilla itself:
Load a file in the language of your choice, select a style in a list,
and use a color selector to change foreground and background colors, try
bold, italics, etc., use a font selector to change font and size, etc.
With instant feedback (perhaps changing color in text when moving a
slide), it would ease greatly editing.
If I ever make this tool, it wouldn't read/write directly SciTE
properties. First because I would want to make a generic Scintilla tool,
usable with any Scintilla based editor. Second because .properties files
are hard to read (althought I could reuse SciTE code) and even harder to
write (because of the use of pseudo-variables like $(colour.keyword)).
So user would have to retype found values, or copy/paste them.
Well, if I use Lua as storage format, I could use it to output data to
whatever format target editor uses.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --