| Summary: | Search occurs in random editor window instead of active editor window | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Aaron Williams <aaronw> |
| Component: | All editors | Assignee: | kdevelop-bugs-null |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aaronw, ekigwana, igorkuo, npomarede |
| Priority: | NOR | ||
| Version: | 5.11.230390 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Aaron Williams
2023-04-20 06:24:28 UTC
I have also noticed this bug recently. Not sure whether this is a recent regression or I grew to use split views more extensively. This bug could be related to Bug 377742. Maybe we should make the central find view bar location optional as requested in the other bug. Or perhaps this bug can be fixed in the central-location code, if the feature is to blame. This bug is so frequent with me as to make searching almost useless. It is extremely annoying. The only way I can search reliably is to type ^F, and type in what I want to search for. Since the result is usually in the wrong panel, I have to click again on the correct panel and then type F3. I usually have 4 editor panes open, left to right, often with several for the same file as I look at different sections of the file. The only other thing of note is I use focus follows mouse. I just debugged this bug for a while, but haven't found the root cause. Noticed that the bug may be absent for a while. When it starts happening, the same wrong split view is searched in repeatedly. And the searched text is the one that was last searched for in this wrong view, not the one displayed in the search bar (which belongs to the split view, in which the user last double-clicked). When the bug occurs in the steps to reproduce, the third step ^F activates the wrong view, because the "pattern" combobox of the wrong split view gets focus, which activates its parent view. But the correct view is then passed to KTextEditorIntegration::MainWindow::showViewBar(), hence the mismatch between the displayed text and the searched-for-in-the-wrong-view text.
> The only other thing of note is I use focus follows mouse.
This can exacerbate the problem and make the bug much more frequent, because KDevelop aims to search in the split view that currently has focus.
Kate's split views also share a search bar. I haven't been able to reproduce this bug in Kate. Can you reproduce it in Kate with "focus follows mouse"? I can confirm this bug as well. *** Bug 478292 has been marked as a duplicate of this bug. *** Just to confirm bug is present in plasma 6 too using kate. I'm using split view a lot and I have the feeling this search+focus issue appeared since I use plasma 6, I never saw it under plasma 5. Still present with kate 24.11.80 , under mageia cauldron version (In reply to Nicolas Pomarede from comment #7) > Just to confirm bug is present in plasma 6 too using kate. > I'm using split view a lot and I have the feeling this search+focus issue > appeared since I use plasma 6, I never saw it under plasma 5. > > Still present with kate 24.11.80 , under mageia cauldron version I cannot reproduce in Kate 24.08.3. Are you sure the Kate bug is exactly the same as described in the first comment here? Even if the bug looks the same, it could still be in separate Kate rather than common KTextEditor code, seeing as it appeared only since KF6. So perhaps log another bug against Kate and link it to this one? What I see is really similar to your comment in #3 : - at one point search stop working and only happens in bottom view - if I click 1st in top view and press F3, search keeps looking in the bottom view, there's no way I can search in the top split view In this case, this is when I do a horizontal split, with one view at the top and one view at the bottom. I know of two ways to notify KTextEditor and Kate developers about this bug: 1. Log another bug against Kate. 2. Change this bug's component from kdevelop to frameworks-ktexteditor. I am reluctant to change the component, because some of the information in comments is applicable only to KDevelop, we are not certain the bug is confined to KTextEditor code, and the KDevelop bug can remain even if there is a bug in KTextEditor and it gets fixed there. (In reply to Igor Kushnir from comment #10) > I know of two ways to notify KTextEditor and Kate developers about this bug: > 1. Log another bug against Kate. > 2. Change this bug's component from kdevelop to frameworks-ktexteditor. > > I am reluctant to change the component, because some of the information in > comments is applicable only to KDevelop, we are not certain the bug is > confined to KTextEditor code, and the KDevelop bug can remain even if there > is a bug in KTextEditor and it gets fixed there. Should I file a new bug and reference this one? I can easily reproduce this bug in KDevelop and find it extremely annoying since I hit this constantly since I tend to have multiple views into the same file. (In reply to Aaron Williams from comment #11) > Should I file a new bug and reference this one? Feel free to do so if you can reproduce the bug in Kate. Otherwise, let Nicolas Pomarede create a Kate bug. I will create a new BR next time the problem occurs for me in Kate. If you see the problem too and want to create a new BR, I will add my comment to this new BR |