[kate] [Bug 491890] New: Button `Expand results` doesn't expand results
https://bugs.kde.org/show_bug.cgi?id=491890 Bug ID: 491890 Summary: Button `Expand results` doesn't expand results Classification: Applications Product: kate Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: kwrite-bugs-n...@kde.org Reporter: i...@markus-pister.de Target Milestone: --- SUMMARY I was used to use the button `Expand results` in the search plugin to both collapse and expand the result list. I just noticed that the button now only collapses the results, no expansion happens anymore when again hitting the button. Found in branch 'master' (current HEAD: commit 41e0a495). STEPS TO REPRODUCE 1. Perform some search with the search plugin that has results 2. Hit button `Expand results` multiple times OBSERVED RESULT Results are collapsed (if state was expanded before), but no expansion happens anymore. EXPECTED RESULT Hitting the button previously toggled expanded and collapsed state of the result list. Would be nice to have that behavior back. SOFTWARE/OS VERSIONS Linux/KDE Plasma: EndeavourOS KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 491890] Button `Expand results` doesn't expand results
https://bugs.kde.org/show_bug.cgi?id=491890 Markus Pister changed: What|Removed |Added Resolution|WAITINGFORINFO |NOT A BUG Status|NEEDSINFO |RESOLVED --- Comment #2 from Markus Pister --- Indeed, my search had matches in > 300 files, actually. Thanks for explaining. Just rechecked with a different search and there, the button works as expected. I agree that probably nobody checks soo many matches in the result list. My intention was to open the list and do a very fast scroll over if the matches look reasonable to me. >From my point of view, no need to relax that limit. I was just surprised cause I was not aware of the limit. >From that perspective, the bug report is invalid. I switch the status to "not a bug". Thanks again for the fast reply. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 474129] New: Restore previously selected side bar when closing git history view
https://bugs.kde.org/show_bug.cgi?id=474129 Bug ID: 474129 Summary: Restore previously selected side bar when closing git history view Classification: Applications Product: kate Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: i...@markus-pister.de Target Milestone: --- SUMMARY When closing the git history view of a file, the left sidebar is closed. Usually (at least in my workflow), there was a selected sidebar opened before starting to look at the git history, e.g. the project view from which the git history view was opened. It would be very convenient, to restore the sidebar used before the git history view got opened. STEPS TO REPRODUCE 1. Open project view sidebar 2. Use context menu "Show Git History" on an arbitrary file 3. Hit close button of displayed git history sidebar OBSERVED RESULT No left sidebar is displayed, all are closed. EXPECTED RESULT The sidebar is opened that was used before hitting the "Show Git History" context menu entry. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Endeavour OS using KDE/Plasma (wayland) KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 474129] Restore previously selected side bar when closing git history view
https://bugs.kde.org/show_bug.cgi?id=474129 Markus Pister changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Markus Pister --- Just checked the implemented behavior on a fresh master build. Works perfectly. Thanks for implementing this. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 444167] New: Not asking for openvpn private key password
https://bugs.kde.org/show_bug.cgi?id=444167 Bug ID: 444167 Summary: Not asking for openvpn private key password Product: plasma-nm Version: 5.23.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: applet Assignee: jgrul...@redhat.com Reporter: i...@markus-pister.de Target Milestone: --- SUMMARY When activating an openvpn connection (type Password with certificates (TLS)), the password field for the openvpn private key is missing although both passwords (private key and password) are configured to be prompted every time in the connection settings. Issue started to appear in plasma-nm-5.23.1-1-x86_64.pkg.tar.zst on my Arch installation. The previous package (plasma-nm-5.22.5-1-x86_64.pkg.tar.zst) works fine. STEPS TO REPRODUCE 1. Create an openvpn connection 1.1 Enter valid gateway server 1.2 type: "Password with certificates (TLS)" 1.3 Configured CA certificate, User certificate and private key files 1.4 Configure "Private Key Password" to be prompted every time 1.5 Configure "Password" to be prompted every time 1.6 Leave "Username" empty 2. Activate created connection OBSERVED RESULT A dialog appears that asks for "Provide the secrets for the VPN connection '...'" with a single password field. EXPECTED RESULT A dialog appears that asks for both the password and the private key password. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The openvpn connection works fine when storing the passwords in the settings dialog. So, the issue is only about not prompting for the private key password. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 444167] Not asking for openvpn private key password
https://bugs.kde.org/show_bug.cgi?id=444167 --- Comment #1 from Markus Pister --- I could deduce the commit which introduced the reported behavior change: 3213592ca5180a3ac61b72a2d0e473b258ae9115 is the first bad commit commit 3213592ca5180a3ac61b72a2d0e473b258ae9115 Author: Jan Grulich Date: Wed Jul 21 11:18:59 2021 +0200 OpenVPN: support hints and simplify logic in the auth dialog vpn/openvpn/openvpnauth.cpp | 112 ++-- vpn/openvpn/openvpnauth.h | 2 + 2 files changed, 68 insertions(+), 46 deletions(-) Current master (HEAD: b03c7e8f) still only asks for one password. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 444167] Not asking for openvpn private key password
https://bugs.kde.org/show_bug.cgi?id=444167 --- Comment #2 from Markus Pister --- Created attachment 143372 --> https://bugs.kde.org/attachment.cgi?id=143372&action=edit Screenshot of password dialog only asking for one password -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 444167] Not asking for openvpn private key password
https://bugs.kde.org/show_bug.cgi?id=444167 --- Comment #3 from Markus Pister --- Created attachment 143373 --> https://bugs.kde.org/attachment.cgi?id=143373&action=edit Expected password dialog as shown in 5.22.5 version -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 444167] Not asking for openvpn private key password
https://bugs.kde.org/show_bug.cgi?id=444167 Markus Pister changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #6 from Markus Pister --- (In reply to Jan Grulich from comment #4) > Hi, this should be (hopefully) fixed in Plasma 5.23.3 with > https://invent.kde.org/plasma/plasma-nm/-/commit/ > 48fad4ac77520d673414ef957e6dedc4d151eb73. Can you verify? Yes, I just tested the newest Arch package build containing 5.23.3 from yesterday. This fixes the reported issue. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 458554] New: LSP plugin quickfix action has no effect anymore
https://bugs.kde.org/show_bug.cgi?id=458554
Bug ID: 458554
Summary: LSP plugin quickfix action has no effect anymore
Product: kate
Version: Git
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: application
Assignee: kwrite-bugs-n...@kde.org
Reporter: i...@markus-pister.de
Target Milestone: ---
SUMMARY
Double-clicking an [quickfix] action item in the LSP Diagnostics view has no
effect anymore.
STEPS TO REPRODUCE
1. Consider the following sample C++ code with activated LSP plugin
int main()
{
std::string someString { "foo" };
return 0;
}
2. Open the LSP diagnostics view
The view should show the following content:
[clang] (undeclared_var_use) Use of undeclared identifier 'std' (fix available)
-> [quickfix] Include for symbol std::string
3. Double-click on the line entry [quickfix]
OBSERVED RESULT
Nothing happens.
EXPECTED RESULT
The quickfix should be executed, i.e. the appropriate include statement should
be inserted.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
ADDITIONAL INFORMATION
Kate has been compiled with HEAD == e1b4bc5c
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 458554] LSP plugin quickfix action has no effect anymore
https://bugs.kde.org/show_bug.cgi?id=458554
--- Comment #1 from Markus Pister ---
To help in identifying the issue cause in the code, I bisected kate with the
following result:
bccf9a58ab1bb6f435eb942b46a2931dd9aedd0d is the first bad commit
commit bccf9a58ab1bb6f435eb942b46a2931dd9aedd0d
Author: Mark Nauwelaerts
Date: Wed Feb 9 21:47:26 2022 +0100
lspclient: use multiple items for a diagnostic item with embedded newlines
addons/lspclient/lspclientpluginview.cpp | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
Funnily, my proposed test code did not exhibit a quickfix action anymore, so I
worked on the following test code (put into test.cpp):
int sensor;
int main()
{
senSor = 0;
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 458554] LSP plugin quickfix action has no effect anymore
https://bugs.kde.org/show_bug.cgi?id=458554 --- Comment #2 from Markus Pister --- Created attachment 151777 --> https://bugs.kde.org/attachment.cgi?id=151777&action=edit Experimental patch that solves the reported issue The attached patch solves the issue for me locally. However, I'm not sure whether the patch is correct in call cases. If the only code actions that can be triggered are such quickfix actions, it might be okay. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 458554] LSP plugin quickfix action has no effect anymore
https://bugs.kde.org/show_bug.cgi?id=458554 Markus Pister changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #5 from Markus Pister --- Thanks for integrating the patch. Checked again with a compile of current master (565b1004). Works as expected. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 413306] New: Build Plugin: wrong effective working directory if kate working dir is not path of .kateproject file
https://bugs.kde.org/show_bug.cgi?id=413306 Bug ID: 413306 Summary: Build Plugin: wrong effective working directory if kate working dir is not path of .kateproject file Product: kate Version: Git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: i...@markus-pister.de Target Milestone: --- SUMMARY When using target settings imported from the kate project specification, the kate working directory seems to be used instead of the one specified in the project specification. In my setup, the make file is located in the same folder as the .kateproject file. Thus I specified "directory": "." in the build section of the kate project file. Trying to build fails because the make file is not found. Patching the build command to print $PWD shows that kate's working dir is used. STEPS TO REPRODUCE 1. Prepare kate build directory as described in https://kate-editor.org/build-it/ 2. Open kate such that its working dir is not the git clone's top-level dir (e.g. using krunner or the main KDE menu) 3. Open an arbitrary file from the kate git clone 4. Try to build using build plugin OBSERVED RESULT The build fails and the build output window shows the following content: > make: *** No targets specified and no makefile found. Stop. EXPECTED RESULT The build process starts and succeeds. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed 20190814 KDE Plasma Version: KDE Frameworks Version: 5.60.0 Qt Version: Qt 5.13.0 (built against 5.13.0) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 413306] Build Plugin: wrong effective working directory if kate working dir is not path of .kateproject file
https://bugs.kde.org/show_bug.cgi?id=413306 Markus Pister changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #5 from Markus Pister --- Just tried it out with the current master version. Works perfect, thx for the fix! -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 360195] Feature Request: Expand/Collapse all actions for items in the documents list
https://bugs.kde.org/show_bug.cgi?id=360195 Markus Pister changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #2 from Markus Pister --- Checked, works as expected ;-) Thx for merging the patch! -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 360195] New: Feature Request: Expand/Collapse all actions for items in the documents list
https://bugs.kde.org/show_bug.cgi?id=360195 Bug ID: 360195 Summary: Feature Request: Expand/Collapse all actions for items in the documents list Product: kate Version: Git Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: i...@markus-pister.de The documents list currently does not feature actions for expanding or collapsing the complete sub tree of an item. Having a lot of open files in different sub folders, such a feature would become handy. Especially when opening a saved session because then, the folder view in the documents list is collapsed by default. Ideally, the feature could be available in all tree views, e.g., the project plugin view. Reproducible: Always Steps to Reproduce: 1. Open files in different folders 2. Right-click on a folder entry in the documents list Actual Results: There is no action for "expand/collapse all". Expected Results: Display context menu entries for expanding/collapsing the complete sub tree of the currently selected folder entry. -- You are receiving this mail because: You are watching all bug changes.
