SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2016 v21 Beta Discussion => Topic started by: rowbearto on August 24, 2016, 03:43:48 PM
-
I am using the traditional find dialog. I have "Look in:" set to "Current Procedure". I have "LIst all occurrence" and "wrap at beginning/end" checked. Funny thing is that "wrap at beginning/end" is greyed out.
If I have the cursor in the middle of a C function and search for a local variable name, it is only finding the instances that are below the cursor location. I want to find all instances in the function, not just the ones below the current cursor location, but also above it until the function definition. I thought that was what "Wrap at beginning/end" is for? But I have "wrap at beginning/end" checked, but for some odd reason it is also greyed out. It seems to get ungreyed when I uncheck "List all occurrences".
I am using beta3 on linux
-
Wrap is disabled when using List all occurrences by design. Wrapping flags are not used for List all occurrences, it searches the entire range selected in the Look in field. The cursor location should not affect the results returned. I am not seeing any issues with beta 3 in my tests, could you provide more info?
-
The code is proprietary, I cannot share it. I've given all the info I can without sharing the code. I'll try to work on providing a test case if I have time.
Perhaps if I give you my configuration you could reproduce the issue? What can I do without sharing the code to get the issue reproduced by you?
-
Here is a screenshot of my find dialog, maybe it helps you to reproduce?
-
Here is another screenshot with a snippet of the code.
You can see that it missed finding the occurrences of dci_data_ptr on lines 1225 and 1231
-
I uploaded a file "test2.c" to support.slickedit.com
There are some settings in my configuration that you should also set.
First, I have macro variable, defs_ctags_flag set to 10. See https://community.slickedit.com/index.php/topic,13290.msg52650.html#msg52650 for more details about that.
Also, in my preprocessor configuration, I have the following 3 set as "undef":
HOST
LTE_FRAME_TYPE_2
METRO_2x2
To reproduce, go to line 399. Search for "dci_data_ptr" using "Look in:" as "Current Procedure", and check "List all occurrences"
You will see that only the instances after line 399 are found, others above it are not found.
SE does seem to know the function boundaries. If you go to line 1780 (closing brace of function), and press Ctrl+], then it correctly finds the start of the function.
-
Try this: from the same location in the file as you are searching, then Edit > Select > Procedure? Does the entire procedure get selected as expected? If the select-proc command fails, that might explain the results you are getting. Could be an issue with preprocessing that is causing the parser to fail to detect the procedure boundaries.
Thanks for the sample, I am able to replicate this in Beta 3 release. I did just test this with all the latest fixes for next build, and it appears to be fixed there once I added the preprocessing undef's you listed. There is a good chance this has already been addressed in one of the tagging fixes prepared for the next release.
-
Thanks. The select-proc command fails.
Does select-proc work with the latest fixes for next build?
Glad to hear it is fixed in next beta. Looking forward to getting it.
-
I am having this same issue on a different file, test3.c, in beta5. I have uploaded this file as part of a .zip to support.slickedit.com.
Go to line 4084, and search for "user_id" with "Look in:" as "<Current Procedure>", and choose "List all occurrences".
You will see that only the "user_id" after line 4084 are shown. Additionally, user_id after the end of the function (line 7298) are shown in the results, and they should not be there.
Running "select-proc" on line 4084 fails.
However, SE does seem to know the right function because in the toolbar and defs window, when I am on line 3689, it shows uls_crc_handling() - see screenshot 1 in the zip file
If I put the cursor on line 3688 (opening brace of uls_crc_handling()) and press Ctrl+[, it correctly finds the closing brace of the function on line 7298.
Finally, if cursor is on line 7319, toolbar and defs window correctly shows that I am inside uls_pusch_dtx_processing, see screenshot 2 in the .zip file.
As with previous posts, you need following preprocessor settings:
I have the following 3 set as "undef":
HOST
LTE_FRAME_TYPE_2
METRO_2x2
-
The current implementation of select-proc requires that the outer function braces match (Press Ctrl+] on start or end brace and it will fail). This is why your this function in test3.c doesn't work. We will see if we can do something about this limitation. Assuming we can fix this, it's hot fixable.
-
When I use Ctrl+], it passes and correctly finds the closing brace. Are you saying this is failing for you? It works for me.
-
When I go to line 3688 of test3.c, and press Ctrl+[, it correctly takes me to line 7298 where the closing brace is.
And from the screenshots I included, you can see that defs window and toolbar also are able to know when we are inside/outside the function.
Did you remember to set the preprocessor settings that I put into my previous post?
-
Definitely not working for me. If I try Ctrl+[ at the start, it says "Match not found". If I try Ctrl+] at the end, it goes to the wrong line (line 4047).
-
Did you configure your preprocessor?
-
Do you have the following 3 set as "undef":
HOST
LTE_FRAME_TYPE_2
METRO_2x2
-
If I remove the "undef" of those #defines, then I get the same issue with you for the Ctrl+[
But if you create the undefs in the preprocessor, you will be able to successfully do Ctrl+[
Again, make these undef in the preprocessor:
HOST
LTE_FRAME_TYPE_2
METRO_2x2
-
I'm doing Ctrl+[ on the function with the defines in it. Not preprocessor output. That's part of the limitation. It doesn't matter what preprocessing you've configured in SlickEdit.
-
Did you remember to check the box for "undef"?
Attached is a screenshot of my preprocessor settings.
With these preprocessor settings, Ctrl+[ works properly. Without these preprocessor settings (and checking "undef"), then I have the issue that you have.
-
I'm not doing this on preprocessor output either. What I meant is did you configure the preprocessor settings (my screenshot), to "undef" these 3 values?
-
I goofed. It's not Ctrl+[. It's Ctrl+] (find-matching-paren).
select-proc doesn't use your SlickEdit preprocessing settings to find the end brace of the function. Ctrl+] doesn't use your preprocessing settings either.
-
I've been using Ctrl+] the whole time, and it works well for me.
You claim that Ctrl+] doesn't look at preprocessor settings, but I am observing different behavior.
When I make the 3 defines as undef in the preprocessor settings, Ctrl+] (not [) IS working properly.
And when I don't make these 3 defines as undef in the preprocessor settings, I get the same behavior as you.
Did you try Ctrl+] (not [) with the preprocessor settings? Because when I try it, it works for me.
So I think Ctrl+] is using preprocessor settings, but select-proc is not?
-
Interesting. There is a little bit of smarts in find_matching_paren that is effected by your preprocessing settings. However, the function "c_select_proc_common" doesn't have any of that logic which does some syntax color matching.
In any case, this isn't the best way for select_proc to be implemented. The end location is actually stored in our tagging context information so there shouldn't be a need for us to use raw text searching to find the end brace of the function.
-
OK. Well it could be nice if you could fix the issues with searching in "Current Procedure" on this function, as it led me to changing some wrong code and wasting some time.
-
Worse case, we will have a hot fix for this very soon.
-
Thanks!
-
This will be fixed in RC 2
-
Excellent! Thanks!