Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Feature request for simpler syntax highlighting
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

SamHocevar
Junior Member

France
15 Posts

Posted - Jun 26 2009 :  06:05:54 AM  Show Profile  Visit SamHocevar's Homepage  Reply with Quote
The idea of adding more syntax highlighting features seems to be frowned upon. I fully support this position, as my eyes are unable to tell apart the many styles VAX already provides. However, I actually use very few styles in my colour scheme, yet I am in desperate need of more control.

The feature request I have is for a frustrating limitation in Visual Studio: it makes no difference between control flow keywords (for, while, break, return) and type specification keywords (int, long, const).

Let me explain using a screenshot of my personal Vim settings:



I am using purple for constants, strings and preprocessor macros, green for types, type modifiers (int, size_t, const, volatile...) and custom types and yellow for other language keywords. Nothing particularly fancy, but it lets me quickly recognise where variables are declared, and where the program flow is controlled.

Unfortunately there is no way to have a different colour for "for" and "int" in Visual Studio, even with Visual Assist X (which only seems to add colour to text that was not already coloured). Is there a chance VAX could help me here?

Alternatively, maybe someone can suggest a third-party plugin I can try. Thanks in advance!

SamHocevar
Junior Member

France
15 Posts

Posted - Jun 26 2009 :  10:31:37 AM  Show Profile  Visit SamHocevar's Homepage  Reply with Quote
Another problem I have that is slightly related is that Visual Studio 2008 believes "event", "interface" and a few others are C and C++ keywords (they're managed C++ keywords, which is not exactly the same). They are therefore skipped by Visual Assist X's own colour highlighting, whether they are variables, types, methods, or macros. Does anyone know of a way to prevent that?
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
14846 Posts

Posted - Jul 02 2009 :  4:49:08 PM  Show Profile  Reply with Quote
Your second point first, using a standard C++ file, .cpp, with VS2008, on a machine where VA has never been installed I added this code to a function:

	int interface;
	int event;

both "interface" and "event" are coloured as keywords by the IDE, blue for me. I would need to find one of my C++ books to double check the keywords list, but the code does not compile, there is an error on the "int interface" line, the IDE thinks I am trying to create a structure by the looks of the error message.


Your first point, some way of indicating the "flow" logic of the function is an interesting idea. The question is how best to do this. I have put in a feature request to see what our developers make of it:

case=29132

zen is the art of being at one with the two'ness
Go to Top of Page

SamHocevar
Junior Member

France
15 Posts

Posted - Jul 03 2009 :  05:05:23 AM  Show Profile  Visit SamHocevar's Homepage  Reply with Quote
quote:
Originally posted by feline

Your second point first, using a standard C++ file, .cpp, with VS2008, on a machine where VA has never been installed I added this code to a function:

	int interface;
	int event;

both "interface" and "event" are coloured as keywords by the IDE, blue for me. I would need to find one of my C++ books to double check the keywords list, but the code does not compile, there is an error on the "int interface" line, the IDE thinks I am trying to create a structure by the looks of the error message.

This is strange; maybe the IDE is somehow thinking that the project is a managed C++ or C++/CLI (CLR) application instead of a native application? C++/CLI does have these keywords, but then it's no longer C++ and requires a different parser (due to "^" and "^%", generics and a few other additions).
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
14846 Posts

Posted - Jul 03 2009 :  7:18:00 PM  Show Profile  Reply with Quote
A quick sanity check, a C++ CLR class added to my test cpp file does not compile, so the compiler does think this is a standard C++ file, and not a C++ CLR file.

zen is the art of being at one with the two'ness
Go to Top of Page

SamHocevar
Junior Member

France
15 Posts

Posted - Jul 06 2009 :  05:05:21 AM  Show Profile  Visit SamHocevar's Homepage  Reply with Quote
quote:
Originally posted by feline

A quick sanity check, a C++ CLR class added to my test cpp file does not compile, so the compiler does think this is a standard C++ file, and not a C++ CLR file.


Oh, then I guess you're including <windows.h> or some similar header. The Microsoft SDK's <BaseTyps.h> does the following monstrosity:
#define __STRUCT__ struct
#define interface __STRUCT__
It looks like this is the cause of your compilation error.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2017 Whole Tomato Software, Inc Go To Top Of Page
Snitz Forums 2000