| T O P I C R E V I E W |
| foxmuldr |
Posted - Oct 30 2014 : 07:57:39 AM
I have a block like this:
238: #ifndef _SOME_SYMBOL
239: // Code goes here
240: #endif
I have this somewhere in a header file:
18: //#define _SOME_SYMBOL
I would like a way to put my cursor on line 238's "_SOME_SYMBOL" to be able to use Alt+G to goto the commented symbol, because the mechanics of the #if-blocks indicate it may or may not be defined, but if it can be known that there is some location in source code where it is defined, but is commented out, that would be useful.
Best regards,
Rick C. Hodgin
|
| 15 L A T E S T R E P L I E S (Newest First) |
| foxmuldr |
Posted - Jul 11 2015 : 11:32:54 AM
quote:
Originally posted by accord
Ctrl+Shift+F is find in all files  It picks up the current word, so you don't even need to select it before.
Oops! I was referring to alt+shift+f. My mistake.
quote:
I am seeing why your argument is valid about commented-out defines, so I have put in a feature request for this:
case=90757
Awesome. And might I add, surprising. :-) LOL!
If you ever open source VA, then maybe we could help you with source code development. I think there are some of us who would be willing to sign an NDA to gain some of the features we request which are passed over currently, for example, and to help with others here and there when possible.
Best regards,
Rick C. Hodgin
|
| accord |
Posted - Jul 08 2015 : 9:40:18 PM
Ctrl+Shift+F is find in all files It picks up the current word, so you don't even need to select it before.
I am seeing why your argument is valid about commented-out defines, so I have put in a feature request for this:
case=90757
Hashtags aren't symbol either, are they? (alt+g works on them)
Thank you for the kind words, we are very happy that you like Visual Assist very much. 
Unfortunately we have enough on our plates supporting current Visual Studios (from VC6 to VS2015). |
| foxmuldr |
Posted - Jul 06 2015 : 09:22:40 AM
I'm very surprised Whole Tomato doesn't see this is a valid search feature augment.
I'm also surprised Whole Tomato doesn't target add-ons for Linux to do some of these amazing manipulations in some common editors. You could dominate the market. Not everything in Linux has to be open source. And your tools are one of the few products I pay for that are closed source. I do so because they are so powerful.
Best regards,
Rick C. Hodgin
|
| foxmuldr |
Posted - Jul 06 2015 : 09:07:55 AM
If the symbol's commented out, ctrl+shift+f doesn't work (because the symbol on a #ifdef xyz doesn't recognize xyz and it pops up the message "Find References is not available because the symbol is unrecognized").
Alt+g would be more straight-forward for what someone looking for a symbol is trying to do in this case.
This particular case is not like other source code. This is one case where valid source code (that's not-commented out) is specifically switching on the condition of other valid source code which may or may not be commented out. But both of those target conditions (the source symbol being either commented out, or not commented out) are valid, and expected, in normal source code. VA should be handling this condition appropriately.
The key for this is easy: If the first two characters of the line you're on are #if, then treat the symbol search in the special case condition. And when you're parsing source code, if the first non-comment characters on a source line are "#define", then add that symbol to the special case condition search list of finds so that it's known with alt+g on future #if-based searches.
Best regards,
Rick C. Hodgin
|
| accord |
Posted - Jul 05 2015 : 5:41:22 PM
It's already working when the #define is not commented out. When I wish to find the place/places when a macros might have been defined or was commented out I just press ctrl+shift+f, enter and finally f8. It will go to the first or only occurrence. |
| foxmuldr |
Posted - Jun 29 2015 : 1:52:56 PM
I would like to re-request this for #define statements. #define statements are used to turn things on and off. And their references will exist in source code even if they are not defined. I would very much like the ability to go to an #if defined(my_symbol) and have it go to where #define my_symbol is, or to where //#define my_symbol is.
It would only find the first non-comment thing on a single line.
Best regards,
Rick C. Hodgin
|
| feline |
Posted - Nov 05 2014 : 2:30:53 PM
Commenting out code is normal, yes, but once it is commented out it can no longer be safely considered code, which is why I am suggesting wrapping them in #if 0 #endif, which has the same effect, but is still something VA will parse and consider. |
| foxmuldr |
Posted - Nov 05 2014 : 07:40:52 AM
quote:
Originally posted by feline
Here you want Alt-g to know about these comments, so this would require an API that let you add new symbols to VA's symbol database, which then requires you write your own parser. This is quickly getting complex.
Plus exposing an API is another fixed point we have to preserve, since we cannot break things every time we need to change our database format or the information we collect on symbols.
:-(
I can see there is no interest in providing this ability even though #ifdef and #ifndef are basic language abilities and commenting out their symbols is common practice to make them undefined.
Withdrawn.
Best regards,
Rick C. Hodgin
|
| feline |
Posted - Nov 04 2014 : 10:17:12 PM
Have you considered doing a find across your solution for all // comments that match these rules? This would give you a sense of how many cases there are. Are you looking at 10? 500? 20,000? If it is a fairly small number, converting the comments to #if 0 #endif blocks might well be fairly quick and easy.
As for extensions, I have often suggested people use an IDE macro to solve problems, which is an existing technology. This very rarely results in much interest, which does not suggest an API would get much actual use either. Remember Microsoft removed IDE macros because the vast majority of people did not use them.
Here you want Alt-g to know about these comments, so this would require an API that let you add new symbols to VA's symbol database, which then requires you write your own parser. This is quickly getting complex.
Plus exposing an API is another fixed point we have to preserve, since we cannot break things every time we need to change our database format or the information we collect on symbols. |
| foxmuldr |
Posted - Nov 02 2014 : 1:23:45 PM
quote:
Originally posted by felineSo, are all of these lines commented out with // comments? What about /* */ comment blocks? You seem to be assuming that the only time #define will turn up in a comment block is when it is a valid #define statement that has been commented out.
This rule would be applied to all of your 3rd party library code, as well as all of your actual code. The first obvious edge case:
// remember to add a #define
It would only be //#define or // #define or something where there is // followed by optional whitespace followed by define. It would be easy enough to check left-justified lines in /*commented*/ blocks to see also if they have definitions. It would always be something that is left-most justified in a /*commented*/ block, or it could optionally be after // even in a /*commented*/ block.
quote:
Originally posted by felineSecondly, we would have to filter out secondary "definitions" that are found in comments:
// behavior changes when you #define TESTING_CASE with this class
these are both perfectly reasonable comments, but it is not what you are expecting us to see.
I would not include anything that was not explicitly left-justified after the comment characters and optional whitespaces.
quote:
Originally posted by felineRemember we have a lot of outstanding bug reports and feature requests, so sometimes I have to say no to interesting, but probably not widely used suggestions.
I agree. You should open source part of this project so we can contribute. I would code this ability myself if the source were available. We had this discussion back in 2006/2007 and again in 2012?? regarding plugins. You could have us write and test plugins for you that you then test and validate and incorporate into your own code. All you would need to do is expose a tiny API which lets us inquire of the facilities you would expose (open files, source code lines, search for tokens, etc.). We could do all of the hard work for you, and then you could incorporate it into your project if you like. And if not, we could just use the slower version which only operates through the API.
Best regards,
Rick C. Hodgin
|
| feline |
Posted - Nov 02 2014 : 11:32:05 AM
So, are all of these lines commented out with // comments? What about /* */ comment blocks? You seem to be assuming that the only time #define will turn up in a comment block is when it is a valid #define statement that has been commented out.
This rule would be applied to all of your 3rd party library code, as well as all of your actual code. The first obvious edge case:
// remember to add a #define
Secondly, we would have to filter out secondary "definitions" that are found in comments:
// behavior changes when you #define TESTING_CASE with this class
these are both perfectly reasonable comments, but it is not what you are expecting us to see.
Remember we have a lot of outstanding bug reports and feature requests, so sometimes I have to say no to interesting, but probably not widely used suggestions. |
| foxmuldr |
Posted - Nov 01 2014 : 01:39:45 AM
quote:
Originally posted by feline
If you want inactive text to be parsed and read as code, then why not simply use:
#if 0
#define _SOME_SYMBOL
#endif
instead. Saying that some comments are "special" and should be treated as code, even though they are comments, just opens a massive can of worms. Macros start with #define, so this special case gets us into parsing commented out macros.
I am not saying that finding #ifdef symbols is not important, I am saying that comments are not code, and we cannot make any assumptions about comments being valid code, even if they contain keywords.
That works fine for new code. It doesn't address legacy code.
I'm not understanding the issue you have with parsing this data out. For one thing, you already parse macros. In this case you only need to parse beyond comments to see if it is the #define statement, and then you only need to parse the token after that and put it into a list which is then searchable when a user presses Alt+G on a token in the form #ifdef token or #ifndef token, and it's not otherwise found with whatever search mechanism(s) you have.
You'd be adding logic to your parser to see if the thing after comments is a #define, and if so grab the token into a list. And you'd be adding logic to your Alt+G algorithm on failed token searches to then check that list before you return failure to find.
I don't see the can of worms. Nor even one worm.
Best regards,
Rick C. Hodgin
|
| feline |
Posted - Oct 31 2014 : 6:25:58 PM
If you want inactive text to be parsed and read as code, then why not simply use:
#if 0
#define _SOME_SYMBOL
#endif
instead. Saying that some comments are "special" and should be treated as code, even though they are comments, just opens a massive can of worms. Macros start with #define, so this special case gets us into parsing commented out macros.
I am not saying that finding #ifdef symbols is not important, I am saying that comments are not code, and we cannot make any assumptions about comments being valid code, even if they contain keywords. |
| foxmuldr |
Posted - Oct 31 2014 : 1:18:04 PM
quote:
Originally posted by feline
Use Ctrl-w to select the symbol, then do a find in files.
This is a comment. Yes, you have commented out code, but it is now a comment, and checking all comments just in case they might look like code is not something we are going to get into. Far to many problems with this idea, unfortunately.
Am very surprised by your reply as the #ifdef and #ifndef blocks relate exactly to this ability in source code, to comment out a #define for this express reason. That line being commented out is not like other lines of code which may have been commented out for __whatever__ reason ... those related to #if blocks are explicitly defined or not defined because they relate to conditional compilation, a fundamental feature of C/C++.
Best regards,
Rick C. Hodgin
|
| feline |
Posted - Oct 30 2014 : 12:50:49 PM
Use Ctrl-w to select the symbol, then do a find in files.
This is a comment. Yes, you have commented out code, but it is now a comment, and checking all comments just in case they might look like code is not something we are going to get into. Far to many problems with this idea, unfortunately. |
|
|
