News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

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.