[Geany-devel] Deep editor customization....
enrico.troeger at xxxxx
Wed Apr 29 16:29:59 UTC 2009
On Tue, 28 Apr 2009 22:12:04 +0200, Jimmy wrote:
>> >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
>> >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
>they'll just add relevant stuff at the end...
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
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Devel