| Author |
 Topic  |
|
|
jjcjrcpa
New Member
USA
3 Posts |
 Posted - Nov 04 2004 : 10:39:55 PM
|
I'd like to see more syntax highlighting options in VA. One in particular would be to highlight Events in a different color.
John |
|
|
msew
Ketchup Master
94 Posts |
Posted - Nov 14 2004 : 11:22:22 AM
|
It would be nice to do what xemacs does as a default (at least)
some quick examples:
0)
<typeModifier> <returnType> <namespace>::<class>::<function>( <typeModifier> <namespace>::<type> <passedInParamName> ) <typeModifier>
const someType* someNameSpace::SomeClass::someFunction( const anotherNameSpace::type& passedInVar ) const {}
VS
const someType* someNameSpace::SomeClass::someFunction( const anotherNameSpace::type& passedInVar ) const {}
so it would be nice to be able to colorize each:
<typeModifier>
<returnType>
<namespace>
<class>
<anotherClass>
<function>
<passedInParamName>
1)
<typeModifier> <type> <varNameFirstOccurrence> = <value>
<varName> = <value>
const int myConstInt = 11;
int myInt = 10;
...blah blah other code tons of stuff and then we are going to touch myInt again...
myInt = 66;
for Xemacs it makes the FIRST occurrrence (when it is defined) of a var be a diferent color than default text.
so the first occurence of myInt is some defined color. This makes it REALLY easy to look for that color to see where a variable is first defined.
2)
<type> <var> = new <type>
Foo* foo = new Foo()
new should be a seperate color. Allocating is important enough to have it's own color so you SEE that color and are like. Ahh allocation! Instead of probably just skimming over it as it is colored the same as default class name / namespace etc.
3)
delete <var>
delete foo;
delete should be a seperate color. De-allocating is important enough to have it's own color so you SEE that color and are like. Ahh allocation! Instead of probably just skimming over it as it is colored the same as default class name / namespace etc.
NOTE: more than likely this color should be the same for all allocation/deallocation keywords
NOTE: clearly one could choose colors that worked better for them. I just picked ones from the limited choices here :-)
|
Edited by - msew on Nov 14 2004 11:53:14 AM |
 |
|
|
Ruskialt
Junior Member
Denmark
22 Posts |
Posted - Nov 15 2004 : 02:06:24 AM
|
| 0 sounds nice. Don't know about 1-3. Usually I don't use enhanced syntax coloring, but with this system I'd give it another try. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 15 2004 : 5:20:55 PM
|
this has been asked for, and disussed before. i dont know about emacs syntax highlighting, but i do know about VIM syntax highlighting.
in VIM all you are doing in assigning a specific colour to a given keyword. in VAX it is a lot more complex, since the syntax highlighting is responding to the context of the word, and its meaning. |
zen is the art of being at one with the two'ness |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Nov 17 2004 : 09:48:45 AM
|
So when are are we getting it? ^^ :-)
and btw: emacs > vi *cackle* |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Nov 17 2004 : 10:26:40 AM
|
In emacs it's all just regexp matching as well, I think.
new and delete could easily be a different colour in VAX, I assume, but I'm not sure how many different colours I want to have to configure. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Nov 17 2004 : 11:58:41 AM
|
> but I'm not sure how many different colours I want to have to configure.
right but you could just leave them as default and let everything be blue or what not.
Better to have more options and good defaults.
I use both visual studio and xemacs. And going from the nice colorific world of xemacs and then into visual studio with VAX is painful. Bring forth more colors I say! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 17 2004 : 5:53:05 PM
|
you want painful? try visual studio without VAX! 
i can certainly put in a feature request for this. personally i like more colours, but to be honest it isn't likely to be a high priority task for WT.
new + delete seem like a reasonable grouping to add, since as you say, they are important.
what other groupings do you want me to specify in the case? going for full regex support to pick your own tokens is probably asking to much for now, especially when you consider how this is going to overlap with the syntax parsing VAX does.
of course, if you want this now, you can always do your coding in emacs  i know there is a plug-in to control the IDE from windows vim, so i wouldn't be surprised if emacs has the same ability  i used to do all of my windows programming in vim, since the basic IDE editor is so frustrating, so this is certainly an option .
as for emacs vs vim, i am a vim power user who has never used emacs, so i am staying neutral |
zen is the art of being at one with the two'ness |
|
|
|
Qwertie
Junior Member
Canada
17 Posts |
Posted - Nov 25 2004 : 3:57:22 PM
|
My two cents.
Personally I just love lots of colors... I would like to see a whole page just on colors (and styles... making some things bold and/or italic and/or um, drop shadowed). I'd like to see so many options you'd need a tree of options of manage them all :)
Seeing scope would be really nice because I'm a lazy guy who doesn't like to bother with m_. I'd like to see a color for local variables, a color for member variables, and another for globals. And maybe a color for static varaibles. Etc.
Of course, not everyone would want so many choices, so as is done now, check boxes could be used to disable options the user doesn't want. |
|
|
|
Qwertie
Junior Member
Canada
17 Posts |
Posted - Nov 25 2004 : 4:07:13 PM
|
| Oh and by the way, those options for "Local symbols in bold" and "Stable symbols in Italic" are nice, but I am using a font that only looks good in Bold, so all my syntax is Bold anyway. So the first option doesn't do anything and the second is sadly un-bold. Maybe these options should TOGGLE the style instead of SETTING the style. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
|
|
Qwertie
Junior Member
Canada
17 Posts |
|
|
Qwertie
Junior Member
Canada
17 Posts |
Posted - Dec 02 2004 : 6:30:05 PM
|
| But, er, I don't want a one pixel wide font, so I *never* use Courier. Previous to Vera Sans Mono, used either Fixedsys or Terminal, but Vera is really better than either of those. The only problem is that the number "1" looks the same as a lowecase "l" in most _other_ fonts. |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Dec 05 2004 : 02:55:31 AM
|
>what other groupings do you want me to specify in the case? going for full regex support to pick your own tokens is probably asking to much for now, especially when you consider how this is going to overlap with the syntax parsing VAX does.
well can you give us some more info on how VAX does its groupsing so we can "choose" what we want :-)
I guess the "pie in the sky" would be regex / xemacs coloring. It seems that if VAX is doing coloring it should be able to color any word / set of words in the file. Right?
|
Edited by - msew on Dec 05 2004 02:56:01 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Dec 05 2004 : 3:04:48 PM
|
msew, i cannot tell you the technical details since i don't know them.
i am going to make the wild assumption that EMACS syntax highlighting is based around the same idea as VIM syntax highlighting. basically:
"this string is this colour"
you can then use either a specific string, or a regex. compare this with what VAX is doing in the IDE. the basic IDE picks out keywords (a fixed list), operators (another fixed list) and comments (a simple regex).
in contrast VAX bases its syntax highlighting on the "meaning" of a given word, which is worked out by parsing the code. this is somewhat at odds with a simple regex.
currently there is no conflict, since keywords, operators and comments cannot be used as function names, local variables, macro's, etc. well, not in normal code anyway 
as soon as VAX allows the user to add their own keywords (regardless of the method) then you are going to get conflicts between the user words and VAX's understanding.
lets assume you have the function "count()" and the variable "int count" in a C++ file. VAX will highlight different instances of the letters "count" as either a function or a variable, perhaps even making "count" bold to show it is a local variable. all is fine until you, the user, decide you want to make "count" bright pink. now who wins? what about the function calls?
so what do you want? asking for a feature that is likely to clash horribly with something VAX already does means we need to say "this is what to do when there is a clash", at the bare minimum.
however if you wanted to highlight "new" and "delete" differently, which are already keywords, then there is no clash. |
zen is the art of being at one with the two'ness |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Dec 05 2004 : 6:42:49 PM
|
well in the example above:
-most are c++ keywords.
-the others seem to be exactly what VAX is doing. Parsig the code and choosing the first instance of the var. Or seeing that the var is in the function declaration and coloring it.
I think it would be slick to do this:
Way 0)
a) VAX "style" parsing and grouping sets of words into categories. (i.e. the current categories are: classes, structures, typedefs / variables / preprocssor macros / methods )
to start, add:
<typeModifier>
<returnType>
<namespace>
<class>
<anotherClass> (for use in function defintions/declarations) (c.f. above)
<function>
<passedInParamName>
b) Ability to choose what font/color/style to set things in a function defition and function declaration
c) vax parsing where you have first occurence of variable as a different color
Way 1)
a) ALL c++ keywords are able to have their font/color/style (e.g. bold/italics) set
Way 2)
A) simple regex. you put in what ever regex you want and VAX colors the words that way
So now you are given a CHOICE of which order do to the parsing.
TEXT -> Way 1+0 -> Way 2 (so the user's regex over writes any conflicts with the VAX coloring)
TEXT -> Way 2 -> Way 1+0 (so the VAX regex overwrites any conflicts with the regex coloring)
NOTE: I think it is Way 1+0 as the VAX GROUPING code should probabl override the colors of indiv text. But this should probably be left to the user also :-)
That would be a huge step forward.
After that we can see what is still missing.
I guess maybe my confusion comes from that:
<typeModifier>
<returnType>
<namespace>
<class>
<anotherClass>
<function>
<passedInParamName>
seem to be very "VAX" like things. They code is parsed and then it figures out which text goes into which category. And then a category has font/color/style properties.
Give us as many categories as possible so we can custimise! :-)
|
Edited by - msew on Dec 05 2004 6:50:09 PM |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Dec 09 2004 : 2:07:08 PM
|
We generally tend toward a product that plugs into the IDE and goes. We shy away from too many options, despite the reasonable requests for "give us more and let us decide."
feline is correct in that VA X uses color for meaning -- something very different from regex algorithms.
Color and attributes are used to display two meanings at once, e.g. local method.
Long ago, we tried shades of color to describe meaning. For example, light brown for local methods, medium brown for those in the project, and dark brown for those in a system library. We did nothing but create a mess. Hence, we migrated back to a more simple setup. |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Dec 09 2004 : 5:06:25 PM
|
>We generally tend toward a product that plugs into the IDE and goes. We shy away from too many options, despite the reasonable requests for "give us more and let us decide."
imo lots of options provided means that there must be good defaults for the the "install and go" requirement to be satisfied. VAX has good defaults. I am pretty confident that you all will be able to either a) create good new defaults or b) propogate the current defaults into the new varied options :-)
>feline is correct in that VA X uses color for meaning -- something very different from regex algorithms.
I think some of the suggestions are exactly this.
1)
<typeModifier> <type> <varNameFirstOccurrence> = <value>
<varName> = <value>
const int myConstInt = 11;
int myInt = 10;
...blah blah other code tons of stuff and then we are going to touch myInt again...
myInt = 66;
is all about meaning :-) The declaration of the variable is a very important thing. Something that deserves a color :-)
And the same goes for the function declaration and definition. Mostly blue doesn't really help the eye parse out important keywords (e.g. if it is const, what the return type is, etc. )
and new and delete being colors are pretty much exactly what keeps being put forward; VAX parses for the meaning and context of words.
|
|
|
| |
Topic |
|
Topic Locked
