Can't navigate to definition in .cc file from .hh file in beta2

[Clark]

When you retag ike that, the old tags immediately disappear.

[rowbearto]

Ok, well I don’t know what was going on in my real project where I first noticed this and tried to repro it with something shareable. I wasn’t retagging there.

[rowbearto]

When it happens in the hh file, are you able to ctrl dot in the cc and go to hh, but not from hh to cc? This was my first observation that made me suspect a bug.

[Clark]

It seems to work the same way. Once the tagging finishes (or sometimes before), then go to tag works.

[rowbearto]

I'm starting to think there may be a bug, here's why. I recall that in previous releases if I did "go to definition" and tagging was not finished yet, that the tagging going on in the background would move to the foreground and I would have to wait for tagging to finish. Now the cursor just moves to the beginning of the line, so I don't know what is going on. It would be nice to get a dialog that says something like "tagging isn't finished yet, would you like to tag in the foreground, or go back to your work and try again later?" If the tagging is not working when I think it should, it is tempting to start a retag thinking tag file is corrupted, but in this case that would be counterproductive. So it would be good to get some kind of indication why the tagging is not working **yet**.

I've also gone back to my original project to see what happens when I reproduce this. So my workspace was loaded overnight (so tagging must be completed) and goto definition does work when I press ctrl+dot in the hh file, it goes to the cc file. But if I close and reopen the workspace, if I do ctrl+dot immediately, it goes to the beginning of the line. But after a few seconds if I try again, it works.

Additionally, if I modify the file and save it, then if I do the ctrl+dot immediately after saving, it goes to beginning of the line. But if I wait a few seconds, it does go to the cc file. Here I'm not telling it to retag the project, I'm just saving the file so SE needs to retag just this file, and it takes a few seconds.

When I first noticed this problem, it was not going away in a few seconds, it lasted for minutes. Maybe a background tagging was ongoing, I don't remember, and I wasn't aware enough to look for that - I will now if I see something like this happening again. A full tag of my workspace takes about 8 minutes. But I don't remember telling it to retag at all when I first noticed this issue, but I will look out for that now if this occurs again.

It would be nice to give the user some sort of indication in situations like this that tagging is not completed yet, if you try goto definition or find references while tagging is ongoing. Also, I think something like this existed in the past, tagging would move from background to foreground in cases like this.

[rowbearto]

Another observation with my real project. gotodef was working, then I got a phone call and was away for 7 minutes. When I came back and tried it, then it went to the beginning of the line. When I tried it again right after this failure, it worked.

[rowbearto]

Just tried another experiment with my real project (not the sample).

Initial condition: the gotodef was working (tagging was completed). Then, I modified the hh file (added a comment), saved it, then I waited about 1 minute, then did Ctrl+dot in the hh file (from the same place as always), and it goes to the beginning of the line, not to the cc file. When I move the cursor back in the hh file to the right place, and do Ctrl+dot again, it works.

If I modify and save, and do the Ctrl+dot right away it also fails. But then try again immediately and it works. So after waiting 1 second, get the immediate failure, then try again immediately and it works, so working after 2 seconds. But if wait 1 minute to do the first gotodef, that fails. So first gotodef seems to always fail no matter how long the wait.

So it seems that right after a save, whether waiting 1 minute or 1 second, the initial ctrl+dot doesn't work. But then next attempt right after, it does work.

I try the same thing with the sample project and I can't reproduce it there. I can only do it with my real project, that I can't share. My real project has a workspace with 2 C++ projects of 15K files each, a 3rd C++ project with boost (9835 files), a 4th C++ project with 3350 files, and a python project with 47 files. All of these files are on NFS network mounts. However the vtg file is on the local hard disk.

[Clark]

Sounds like your workspace has about 44,000 files total. If you do a clean retag of the workspace, how long does it take. The reason I ask is that we may need to be able to reproduce similar performance conditions in order to reproduce this problem. Right now, when I add a comment/save, and quickly do a goto tag (sometimes <1 second later), it just always works.

It does seem very odd that if you want a minute after the save, it still doesn't work for you. Makes me think there might be something else going on.

Also, modifying the current file (the .hh file) and doing a goto def shouldn't be dependent on the current file being retagged first (at least I think that's the case).

[rowbearto]

It takes 13 minutes to retag my workspace and it has 43,837 files total in it. 47 files are python, the rest are C++.

Thanks for trying to recreate this!

[rowbearto]

Clark: Besides the one minute issue and trying to reproduce, what do you think of my first comment from today:

I'm starting to think there may be a bug, here's why. I recall that in previous releases if I did "go to definition" and tagging was not finished yet, that the tagging going on in the background would move to the foreground and I would have to wait for tagging to finish. Now the cursor just moves to the beginning of the line, so I don't know what is going on. It would be nice to get a dialog that says something like "tagging isn't finished yet, would you like to tag in the foreground, or go back to your work and try again later?" If the tagging is not working when I think it should, it is tempting to start a retag thinking tag file is corrupted, but in this case that would be counterproductive. So it would be good to get some kind of indication why the tagging is not working **yet**.

I think you are able to reproduce this one already, where it goes to the beginning of the line while it is still tagging, instead of bringing tagging out of the background to the foreground like previous releases?

[Clark]

I don't think SlickEdit used to wait for tagging of the workspace to finish. However, SlickEdit will sometimes wait for auto-tagging of libraries under certain conditions. That was happening to me with your test case because I have some compilers installed on my system that initially weren't auto-tagged.

It's a bad idea to wait for the workspace to be tagged since this can take way too long (many files and/or the source can be on slow networked devices).

[rowbearto]

Well it would be nice to at least know that the goto def is not found because tagging isn't finished - maybe a message in the status bar? Otherwise I might think tag file is corrupted and try to retag.

I may have confused waiting for auto-tagging of libraries vs. waiting for workspace tagging, but still I'd like to know if goto def failed because tagging is not complete instead of just going to the beginning of the line.

[Clark]

To determine if workspace tagging is in progress, click the clock-like icon in the status area. I've attached a picture of what I see when I click on it.

The clock-like icon is disabled (or not visible) if there are no background tasks running.

[jc44]

> The clock-like icon is disabled (or not visible) if there are no background tasks running.
Seems to be there all the time for me and if I click it then it pops up a box saying "There are no active background processes" (Win10, B3)

[Clark]

> The clock-like icon is disabled (or not visible) if there are no background tasks running.
Seems to be there all the time for me and if I click it then it pops up a box saying "There are no active background processes" (Win10, B3)

The clock-like icon is typically only enabled for a while when retagging your workspace from scratch. Doing a workspace update finishes pretty quick (less than 1 second for me but I've got an SSD and local source code). An update of the workspace occurs when you switch between another application and SlickEdit.