News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Issues with File Associations and Syntax Highlighting

Started by VReality, April 24, 2006, 02:03:06 AM

Previous topic - Next topic

VReality

Issue 1:

How do I associate file extensions with syntax highlighting categories?  For instance, I have some common makefile components that are gathered into a file which gets included into various makefiles.  In order to allow such a file to be associated with things like editors, I give it an extension, like '.mak'.  Of course '.mak' is not associated with any syntax highlighting categories in Code::Blocks.  Is there a way for me to add it to one of the categories?  Issue 1b:  How about adding categories?


Issue 2:

Once I can associate file extensions with syntax highlighting categories, what about extensionless files?  I'd like to associate those ridiculously extensionless makefiles with a category.


Issue 3:

When I open an un-associated file in Code::Blocks, I get a bit of syntax highlighting weirdness.

The default text color setting appears to be black on white.  My C++ color scheme is of the grey on black variety.  I don't like 'current line' highlighting, so my current-line-background-color is black also.

Now when I open an un-associated file, I get black text on a white background (ack – I'm blinded!).  But when I click on the document, the current line seems to pick up my C++ current-line-background-color, which gives me...   black on black – the most illegible color scheme of them all.  This makes editing really annoying.

VReality

Regarding Issue 1 and 1b (maybe 2, and maybe even 3):

I just found (http://forums.next.codeblocks.org/index.php?topic=519.msg2989#msg2989) which explains how to tweak with this stuff behind the scenes.

Of course my original question was regarding the existing (or planned) interface of the Code::Blocks program.

This brings to mind another question.  Is there a published development plan?  I'm just thinking it would be good to have an idea what is planned before submitting requests and suggestions, willy-nilly, to the busy developers.