override SciTE language properties
Dave Vick
customizing some of the fonts, syntax highlighting colors, and other
things. For the editor related things the change I make in the user
properties file seem to be fine, language specific ones however are
getting overridden by the language specific properties files.
Does anyone know how to avoid this? For example, I'd like all comments
in all languages to look the same in the editor, I dont really want to
have to update every language file to do this, but adding what looks
like the correct entries into the user file is not working.
Thanks for your help
Dave
Neil Hodgson
> Does anyone know how to avoid this? For example, I'd like all comments
> in all languages to look the same in the editor, I dont really want to
> have to update every language file to do this, but adding what looks
> like the correct entries into the user file is not working.
Post your user properties.
Neil
Dave Vick
it doesn't get overwritten on updates - is that correct?
as an example of what I'm referring to, I've got the style for
matching braces set to show a different fore color, and t his works
with some of the file types but not all. For example Ruby files do not
use the correct color, they have their own set in the ruby.properties
files. If I specifically set that in my user file (style.ruby.
34=fore:#EED73F,bold) it works. Why wont the wildcard (style.*.
34=fore:#EED73F,bold) one override all of them though? Or is there a
different file or style I need to do it in? I'd rather not have a
language specific line for every style I want to change.
By the way this happens on both Win XP (SciTE 1.75) and Ubuntu (SciTE
1.71).
Thanks for your help
#editor properties
position.width=-1
position.height=-1
are.you.sure=1
load.on.activate=1
are.you.sure.on.reload=1
check.if.already.open=1
strip.trailing.spaces=1
buffers=20
autocompleteword.automatic=1
tabsize=4
indent.size=4
line.margin.visible=1
line.margin.width=3+
#text Settings
if PLAT_GTK
font.comment=font:!Bitstream Vera Serif,size:9,italics
colour.code.comment.box=fore:#B700B7
colour.code.comment.line=fore:#B700B7
colour.code.comment.doc=fore:#B700B7
colour.text.comment=fore:#0000FF,back:#E6E6E6
colour.other.comment=fore:#B700B7
colour.embedded.comment=back:#E6E6E6
colour.embedded.js=back:#E6E6E6
colour.notused=back:#E6E6E6
colour.number=fore:#000000
colour.keyword=fore:#0000FF
colour.string=fore:#008000
colour.char=fore:#008000
colour.operator=fore:#000000
colour.preproc=fore:#7F7F00
colour.error=fore:#FFFF00,back:#E6E6E6
#default
style.*.32=$(font.base),back:#E6E6E6,fore:#000000
# Line number
style.*.33=fore:#FFFFFF,back:#808080,$(font.base)
# Brace highlight
style.*.34=fore:#EED73F,bold
# Brace incomplete highlight
style.*.35=fore:#FF0000,bold
# Indentation guides
style.*.37=fore:#FFFFFF,back:#E6E6E6
autocomplete.*.ignorecase=1
Neil Hodgson
> as an example of what I'm referring to, I've got the style for
> matching braces set to show a different fore color, and t his works
> with some of the file types but not all. For example Ruby files do not
> use the correct color, they have their own set in the ruby.properties
> files. If I specifically set that in my user file (style.ruby.
> 34=fore:#EED73F,bold) it works. Why wont the wildcard (style.*.
> 34=fore:#EED73F,bold) one override all of them though?
Because that would not allow you to specialize the settings for a
particular language. Generic settings are overridden by more specific
settings or there would be no point in changing the more specific
settings.
Neil
John Yeung
> > 34=fore:#EED73F,bold) one override all of them though?
>
> Because that would not allow you to specialize the settings for a
> particular language. Generic settings are overridden by more specific
> settings or there would be no point in changing the more specific
> settings.
earlier settings. I'm not saying this is better than specific always
overriding generic; only that Dave's notion isn't an utterly illogical
one.
John
Dave Vick
there was a way to achieve the same effect for all languages by just
making one change. Maybe some thing along the lines of having the user
properties always have precedence, so that any language specific
changes are made only in the language files and not in the user or
global files.
I guess I'll get in there now and update all my language files, at
least I'm not using 30 different languages :)
thanks for the replies Neil and John - I'm looking forward to working
with SciTE more.
Neil Hodgson
> Neil, what you said makes sense, and I understand it I was just hoping
> there was a way to achieve the same effect for all languages by just
> making one change. Maybe some thing along the lines of having the user
> properties always have precedence, so that any language specific
> changes are made only in the language files and not in the user or
> global files.
Users want to make changes to settings for individual languages.
These should be made in user properties so they survive
re-installation of SciTE. If you modify the individual language files
then it is much harder to upgrade your copy of SciTE.
Neil
Dave Vick
changes to the default language file. For example in the cpp file I
want to add additional keywords for javascript and change some of the
colors used. Can those also be done in the user file?
I asked this in another thread on the scintilla-interest board but
since it is related... is there a decent place to go to see how to
create a language file, there is a lot in them and I've been figuring
some things out by trial and error so far but it would be so much
faster if there were a tutorial :)
thanks again for everything
Dave Vick
in the other forum.
thanks for all your help - I'm sure I'll be back with more questions
eventually :)
Philippe Lhoste
> Never mind the tutorial question I just saw that you had answered it
> in the other forum.
After a long hiatus, I received again NNTP messages on
gmane.editors.scite.general. I sent a message then, but it was rejected.
I waited until today to take time to join to this new discussion group...
I still don't see messages on gmane.comp.lib.scintilla.devel, which
hasn't be updated since August.
It would be nice if it somebody restores the Gmane service for the
Scintilla ML as well. Thanks.
>> All right I understand that, but what if you want to make other
>> changes to the default language file. For example in the cpp file I
>> want to add additional keywords for javascript and change some of the
>> colors used. Can those also be done in the user file?
Personally, I change directly the language files, and I diff them to see
what have changed between releases... But I don't advise to do the same!
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Dave Vick
I was thinking of doing the same thing but I know I'd miss something
in the compare and end up cursing myself. I think my route now will be
to do everything in the user file - it is going to be a fairly large
file when I'm done with it, but all of my changes will be in one place
at least.
KHMan
> Thanks Philippe
>
> I was thinking of doing the same thing but I know I'd miss something
> in the compare and end up cursing myself. I think my route now will be
> to do everything in the user file - it is going to be a fairly large
> file when I'm done with it, but all of my changes will be in one place
> at least.
On the other hand, if you feel that some default colours are
really bad, you can offer a patch to the list... Some of us lexer
fixers don't have much opinion about colours, so I think we'd be
happy to hear from someone who care about having non-headache
inducing colours. For example, I keep some Perl styles which are
normally the same colours in different colours, so that any
failures are immediately visible, thus my user experience is
different from that of normal users.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia