On Tue, 28 Apr 2009 22:12:04 +0200, Jimmy wrote:
Hey,
I always somehow missed the possibility of defining different fonts/size for different styles...
I personally hate this as it makes it all inconsistent and especially different font sizes confuses me a lot. But that's just me, I guess there are other people around who will like it.
Oh yeah, this is a love/hate stuff...the graphic designer in me likes to play around with fonts... As you long as you stick with Monospace fonts (fixed width), you can still get a clean code that aligns properly and all...
No doubt on that. I personally just don't like it but who cares what I like :).
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
Nope. But if have the sources in a Mercurial repository, just create a patch and send it to the list. Me or anyone else probably will be able to apply it to a current SVN version.
A few questions which came to my mind: How to represent fonts+sizes in filetypes.*?
- By adding two additional fields for font name + size to all
existing styles of all existing filetypes? -> that would probably break any existing colour scheme or at least cause lots of work for theme authors
- Make the two additional fields optional?
-> so everything works as by now but interested users can extend it on their own? This would require good documentation and advertisement of that feature.
Second is best yes probably...that wouldn't be handy to oblige everyone to edit their themes to use a new version... if people fancy changing some fonts, instead of having word;#colorfg;#colofbg;false;false they'll just add relevant stuff at the end... word;#colorfg;#colofbg;false;false;!Monaco, 10
Yo, this would be fine.
In another post you mentioned something like "filetype.toto.extended". While I think at some point it might make sense to split the current filetype.* definition files into settings and style-related, yet another set of files for whatever settings seems to much overhead and make things more complicated than necessary, IMO.
I agree...I just see this as a solution that would cause the least disturbances to the code...
Hmm, not sure how this would affect the code less. Just let's agree on not doing this.
The scintilla doc is quite dry, there's not some much nice detailed examples floating around...
It's more or less just a matter of practise reading the Scintilla docs :).
Regards, Enrico