|T O P I C R E V I E W
||Posted - Mar 08 2017 : 5:07:03 PM
Kind of following up with my semantic syntax highlighting request it would be great if Visual Assist improves its support in general for syntax highlighting.
I've been using the extension for 2 years and that part did not really changed. We're still at the same level of setup. We have basically 4 options to select the colors of "classes, structs, interfaces, namespaces, typedefs", "variables", "enums, macros" and "functions, methods".
As I was looking at https://www.jetbrains.com/resharper-cpp/documentation/resharper_cpp_vs_visual_assist.html
They support 20 identifier types that you can highlight differently.
For example you can select different colors for local variables, parameters, ....
It would be great if we get more freedom, after all I'm sure VAssist already have all the information types.
|24 L A T E S T R E P L I E S (Newest First)
||Posted - Jun 21 2022 : 07:53:44 AM
As soon as you have a way of defining N groups, someone is going to have a reason to need N+1 groups. But there are enough C++ keywords that letting you set the colour for each individual keyword is more messy.
So this only makes sense if we let you create groups as you need them.
The original idea in case=29132 was to set the colour for a few keywords, so actually this would solve the original request rather neatly, if done. So I have updated the case with this idea.
||Posted - Jun 20 2022 : 5:06:59 PM
for the list of keywords, why 2 lists?
I did not want to set that there should be only 2 groups. I mean, eg. the user could create 1, 2, 3, 4, etc... groups of keywords. Each group is associated with a given custom color.
||Posted - Jun 20 2022 : 07:39:45 AM
The idea of giving the "return" keyword its own individual colour has come up before:
the idea of colouring function parameters is still one we are considering:
for the list of keywords, why 2 lists? How would this overlap with the colouring of "return"? In a sense what I am wondering is if 2 lists is enough? We don't want the number of options getting totally crazy here, but you are slowly working towards wanting to say "this symbol always has this colour", just limiting it to keywords for now.
||Posted - Jun 20 2022 : 03:57:54 AM
I agree that VA syntax highlighting is kind of antique. When you think about it, this is the thing we have under our eyes all the time!
In addition to the original request (from which I want to highlight the need to have function parameters with specific colors).
I wish certain keywords to have a specific color.
eg. I consider the C++ "return" keyword to stand apart from all the rest, and I wish to assign a specific exclusive color for it.
The needed generalized feature would be to set:
"I want this list of keywords to have this color" and "I want this other list of keywords to have this other color"
||Posted - Mar 29 2022 : 12:06:48 PM
Ah, Goto menu... never used that before, I have CTRL-G mapped to goto line.
You can search for files with several terms, separated by a space, but you cannot use minus to exclude items from your search.
What advantage would there be to trying to merge VA's search into this search? Everything would be in one place, but we we just use the same search rules this dialog already uses what is VA adding?
||Posted - Mar 25 2022 : 1:10:50 PM
File parsing speed is somehow surprising, but I guess that's not worth to discuss without seeing the underlying code. But still, after the files have been parsed, its all a matter of organization and access and that should have been resolved by now, as obviously VS itself does a pretty good job at knowing the details of each symbol (Roslyn, which I guess VA doesnt use still).
Quick Actions exist since VS2015, not sure how many people actually use older VS versions.
And, I am talking about the Ctrl+G dialog (Go to), which does a reasonably good job a live filtering.
||Posted - Mar 25 2022 : 11:49:36 AM
For point 1, it partly depends on solution size. There is already a small but noticeable delay in VA colouring with our fast colouring parser.
For more complete parsing, I don't know how balanced supports point of view is, but from support I see plenty of problem reports where VA parsing is to slow, and too resource intensive. And by slow I mean hours waiting for VA to finish parsing. None of which is to say that improving colouring isn't important, and isn't something we want to do, but its not always a major priority either.
Point 2, adding VA commands to the IDE quick action menu is an interesting idea. This menu / command is recent, it isn't in the older IDE's, so you still need to use a different command there, but it is interesting, I have put in a feature request to see what our developers make of this:
Point 3, not colouring region names as code is in our list of bugs to fix:
that screen shot shows what a mess that can become. You can right click in VA Outline to filter out regions, but I suspect that would cause more problems than it fixes, given how many regions are being used.
Point 4, are you talking about the IDE's CTRL-F dialog, which sits in the top corner of the window and offers very few options? Or are you talking about something else? Also remember that filtering the dialog as you type is rather important for Open File and Find Symbol, unless you know the exact item you are searching for.
Point 6, that makes sense, I have put in a feature request to see what our developers make of this. How easy the IDE makes this would obviously be a factor:
Tooltips are tricky when you have to balance very long lines, as you have here, but also you can have very tall tooltips when you have a large comment block to display. Sometimes you get both problems at once, which is really messy.
||Posted - Mar 22 2022 : 09:31:44 AM
1) Lets see, according to Moores law processor speed has now increased about +200x since VA was released in 2005 and we are still talking about speed for parsing code? Not buying it anymore.
2) yes they are, but why they dont appear in the quick action menu? Ctrl+. since they are doing the same thing? Why do I need another shortcut?
3) now that you mentioned it, yes it was off. And turning it back on, reminded me why i turned it off in the first place:
4) Find references, Find Symbol, kinda fits into the VS find, which includes just about anything from lines to symbols to filenames. Doesnt mean the results have to be included.
5) this falls into the 1) category - stability and consistency (yes, I know VS isnt either, and has a million ways to display tooltips)
6) I can search for a setting and its about having all in one place, with the same interface.
7) while many features and options apply equally to C# and C++, I suppose the underlying engine has millions of decision trees for each language, having to care for only one language might gain speed and simplify logic, at the expense of having two code bases to maintain.
Here a tooltip from the VA outline window, had to scale it down as it required a full screen capture, but you get the picture about tooltip formatting, and this is not even the largest one.
||Posted - Mar 22 2022 : 08:38:20 AM
1) one of the core problems we run into here is a trade off between speed and accuracy. Having colouring code keep up or having colouring code take more time, but be more accurate. We do try to improve accuracy here, but its tricky.
2) The top two entries in the IDE context menu in the editor offer VA refactoring and snippets, at least for me.
3) Are you saying VA Outline isn't getting syntax colouring? It definitely should, assuming you have turned On:
VA Options -> Coloring and Attributes -> Apply coloring to -> Views
For more details, you can include / exclude certain types of entries via the right click menu in VA Outline.
What easier navigation do you want? I tend to collapse the chunks I am not using, but the more complex the file, the more complex the outline.
4) the main find feature we have is Find References, which isn't actually doing a text search, its doing a code search, so I am wary of trying to merge two different concepts together. Or are you thinking of something else?
5) again, syntax colouring of VA Windows should already be happening, assuming you turned this on in VA options. Tooltips not being coloured is a known bug. This used to work, and an OS change broke it:
6) I am just wondering how this would help. I already tend to loose options in the IDE settings dialog, since it covers so much ground, but the up side would be everything in one big place.
7) some code complexity in VA comes from handling different versions of the IDE. Then you have different language versions, with different features, in both C++ and C#. Most VA options apply equally to both C# and C++.
||Posted - Mar 22 2022 : 08:11:12 AM
As a long time user (guess one of the longest) my few cents on this:
1) Code coloring
Easily the most important feature of VA, would be nice to have a few more options, but even more so to have the existing ones stable and consistent.
Very useful, but with VS 2019/2022 I would prefer to have this integrated into the VS features like Quick Actions, intellisense, etc. No need to have extra menus and shortcuts.
3) VA Outline
Useful, but incomplete. Needs applied code coloring, more details, easier navigation.
Also integration of the various Find options into the VS find dialog (or integrate the VS find into VA)
5) integrate code coloring to all the VA windows, makes it easier to identify methods and members (and make an intelligent algorithm to word-wrap long method definitions in tooltips as its doing with paths already)
6) integrate VA options into the VS settings dialog
7) A better separation of features relevant to C# and C++, maybe even different editions of VA? Should also make the code behind easier and more stable.
||Posted - Feb 24 2022 : 06:11:25 AM
This is still in our list of features to look at, but we have a lot of different feature requests and bug reports to balance and prioritize. This isn't a feature request that comes up that often, so most of our users are not that interested in this.
Code Inspection is designed to directly help to improve your code.
How you balance these different features isn't always obvious, or easy, but the level of interest from our users is one consideration, so it is good to know that this is something you are interested in and looking for.
||Posted - Feb 24 2022 : 04:05:46 AM
Now 5 years (!) later this is still not adressed...
It's just a shame.
IntelliSence is still not working with bigger projects and is damn slow too.
You are implementing Code analysis beta functions but not this, which is much more important.
Why you just not implement it and leave the option to the user if he wants to sacrifice performance or not??
We are adult people who can make decisions...
||Posted - Mar 29 2017 : 09:01:34 AM
This is something we are considering, and aware of, but unfortunately I don't currently have an estimate for when this might be done.
||Posted - Mar 28 2017 : 11:16:35 AM
I see, Ive tried what you suggested and yah the ide's color options are real nice, the only problem is that it appears to require intellisense to be enabled. I had it disabled since I preferred VA's intellisense, so having them both turned on is pretty slow. I think because of this VA should just provide the same colorization options as the ide that way we can keep the ide's intellisense disabled.
edit: playing with it some more.. yah the ide's stuff is not use-able, since it relies on Microsoft's intellisense it is just as broken as that, giving very inconsistent results and not able to parse many files.
Anyways if VA can support the same variable colorization options (param, field, local, etc) that alone will be swell.
||Posted - Mar 28 2017 : 07:49:15 AM
I have added a note to the case about this, to say that you are also interested. This is an option we are still considering, but it is not currently a major focus.
If you are really interested in experimenting with this now, you could try turning Off:
VA Options -> Coloring and Attributes -> Apply coloring to -> Text Editors
and then setting the various C++ colouring options the IDE already offers, in VS2015 and above, perhaps starting with:
IDE tools menu -> Options -> Environment -> Fonts and Colors -> Display items = C++ Local Variables
IDE tools menu -> Options -> Environment -> Fonts and Colors -> Display items = C++ Parameters
||Posted - Mar 27 2017 : 3:40:44 PM
Id also like to see this feature set expanded. Colorizing function parameters independently from other vars in particular sounds very nice.
||Posted - Mar 27 2017 : 10:05:21 AM
++ for this feature. I want that too.
You can see an example here: https://www.youtube.com/watch?v=8WRH59PQ5Dk
||Posted - Mar 27 2017 : 09:31:03 AM
We often have an idea of the type information, but not in all cases. What we know is shown in the VA context and navigation fields, normally shown at the top of the editor.
But there is also the question of speed. If colouring is to run at editing / scrolling speed, which is our aim and goal, we cannot spend long working out what colour to use where. This places some further restrictions on what we can sensibly achieve. So you can have something fairly accurate now, or something very accurate at some indeterminate point in the future.
||Posted - Mar 26 2017 : 11:16:15 PM
AFAIU, VA has all the type information it needs from expression trees, doesn't it?
||Posted - Mar 14 2017 : 08:32:17 AM
We are considering, as a longer term plan, allowing you to set a specific colour for function parameters, so I have added a note to this case about these other types as well, to see what our developers make of this. I do understand the appeal, but please realise this is not as easy as it sounds, and is not currently a major focus:
||Posted - Mar 14 2017 : 06:11:54 AM
I wholeheartedly agree that it's time to VA to split the catch-all "Classes, structs, interfaces, namespaces, typedefs" into more varied categories. Especially in C# - classes, enums, interfaces should be distinctly highlighted.
||Posted - Mar 10 2017 : 12:50:56 PM
Do you mean function when you right "fct"? I am guessing you do, but I am not used to this abbreviation.
The problem with colouring is that we want and need the colouring code to run very quickly, so you are not regularly waiting for the colouring to be applied to the code you are viewing, scrolling through, and editing. This imposes some limits on the depth of the analysis that we can run.
Also you have to work out the current scope, and scope of these symbols, to work out "which" symbol is which. There are often duplicate symbol names in code, its not uncommon to have the same name for both a parameter and a class member variable, which is one simple case which can confuse anyone not running a deeper, and slower, analysis.
This is something we are keeping an eye on, but it's not currently an area we are focussing on.
||Posted - Mar 10 2017 : 12:06:47 PM
I'm aware of these features. I use them. Thanks.
For example one suggestion could be to have different colors for fct parameters, member variables (defined in the class) and local variables (define in the body fct). This is easily possible with a basic static analysis (just like VA is doing with local symbol in bold).
||Posted - Mar 09 2017 : 12:26:31 PM
Have you tried using some of the built in C++ colouring options, in the IDE options dialog?
VA often has the information, but since we are running around behind the IDE's back, we can get confused by symbols with the same name, but different types and meanings.
You can also turn on:
VA Options -> Coloring and Attributes -> Show local symbols in bold
VA Options -> Coloring and Attributes -> Show stable symbols in italics
to add a bit more separation to the variables in your code.