The file outline navigation widget does not function reliably. Even if it shows all functions provided in a (C++) source file, using it to jump to a function implementation may in fact open the implementation in a different document. This is very counterproductive as most of the time one doesn't notice the change in open document, esp. if the document was already open (for reference). Reproducible: Always Steps to Reproduce: 1. open a project that provides different implementations of a given class, e.g. for different supported platforms as is relatively common in the KF5 frameworks source. 2. open the source file for one of the implementations 3. use the outline navigator to jump to a given function implementation Example the KDE4libs sources (sorry...) which provide platform specific implementations in kdeui/kernel/util/kwallet.cpp and kdeui/kernel/util/kwallet_mac.cpp . Actual Results: In the above example, using the outline to jump to an implementation in kwallet_mac.cpp opens the implementation from kwallet.cpp instead. Expected Results: A document-specific outline navigator does not jump to a different file unless this is explicitly clear, like when jumping to a declaration in a header file. Developing/expanding the outline entry does show that the reference in fact points to a different file, but most of the time one will execute the jump by a double-click on the entry. The expected result seems self-evident, but in a more general context, the ctags feature sh/could use data from the project importer to exclude files that will not be built (and it wouldn't hurt to distinguish files based on that criterium in the project view).
wtf, bugzilla clearly edited the wrong bug report here... what was the old title of this report?
(In reply to Milian Wolff from comment #1) > wtf, bugzilla clearly edited the wrong bug report here... what was the old > title of this report? According to the changelog I got after the first of your 3 changes, it was "outline dropdown widget ".
Reverted the title
I'm also affected by this. This is not a regression, at least not a recent one, it was like that for years (at least 3) I must say, it's quite inconvenient at the very least :)
Created attachment 101248 [details] Test case with multiple source files implementing same function This testcase contains 2 source files, both of which implement the same symbol - process(). They compile into separate modules, so this is absolutely valid case. This is minimized from darktable's iop - https://github.com/darktable-org/darktable/blob/master/src/iop/CMakeLists.txt Try switching to this process() symbol. Sometimes it switches to the currently selected source file, sometimes not. It seems to depend on which file was opened first.
Same here on Version 5.0.3. The outline navigation seems to behave incorrectly for the files indexed first. Creating a new file with a function with the same name (fairly easy in C files with static functions) makes the outline navigation jump to that new file. But when looking at the advanced info from the outline the correct file and function are shown in the Code Browser. The jump from there is also allways correct. Just the index for the current file for each navigation entry seems to get overwritten...
I have a similar issue with navigation using the tooltips for functions. My usecase is slightly different. I have separate worktrees for different branches of a project (so that switching branches doesn't lead to long recompiles). I have each worktree open as a separate kdevelop project. And often, when using the navigation links (goto definition/declaration) in the tooltips, I get sent from a file in one project to a file in a different project. Unfortunately, since they are often the exact same files, just in different locations, this is very hard to notice and it already led me to changing the wrong file.
(In reply to Jonathan Verner from comment #7) > My usecase is slightly different. I have separate worktrees for different > branches of a project (so that switching branches doesn't lead to long > recompiles). I have each worktree open as a separate kdevelop project. If KDevelop cannot reliably distinguish between the worktrees, a workaround is to open each worktree in a separate KDevelop session and window.
Sure, and if you run it on different machines you remove a few other potential possibilities for unexpected or at least unwanted interaction. IOW, it (partly) defeats the purpose of being able to open several projects in a single session, esp. if you have the habit like I do to "bundle" related projects in dedicated sessions. The Quick Open widget is aware of similarly named files in different projects; would it be so difficult to graft the underlying implementation onto the implementation of the outline widget?