SUMMARY With a Markdown file open in the Preview panel, I am unable to add spaces to the file being edited. All other characters may be entered. STEPS TO REPRODUCE 1. Create a file called test.md with any contents. 2. Close and reopen Kate with the preview window open. 3. Open the test.md file. Ensure a preview is displayed. If so, adding spaces should be disabled. OBSERVED RESULT Spaces are not entered. Soft tabs with size 4 only enter 3 spaces. EXPECTED RESULT Spaces are entered. Soft tabs with size 4 should enter 4 spaces. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 30 (available in About System) KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.1 Kernel Version: 5.0.16-300.fc30.x86_64 ADDITIONAL INFORMATION The files I tested were in a Git repository, but I don't think that should have an effect on this behavior.
This is due to the Okular KPart being used in the preview, which is eating the Space key events and uses it for scrolling, despite not having the focus. While there is a principle issue with shortcuts from used KParts plugins conflictiing with app shortcuts, see bug 386265, this here though is a special variant, as the Space key usually is not a shortcut, so this is IMHO some overly aggressive behaviour of the Okular KParts plugin which should get in conflict in more embedding scenarios. So moving to Okular, so they can consider to improve this in their KParts plugin to restrict stealing the space key event only to when the view has focus. Some work-around for Kate and Markdown preview: use kmarkdownwebview KParts plugin, select in SystemSettings > Applications > File Associations > text/markdown > Embedded > Move kmarkdownwebviewkpart to top in order, press Apply. Still has the other shortcut conflict issues. But normal editing and previewing at least can be done as one expects :)
you can pass "ViewerWidget" as arg to the part to get the "less aggressive" viewer.
or this would probably make sense in okular diff --git a/part.cpp b/part.cpp index c831f8793..229ff7fcb 100644 --- a/part.cpp +++ b/part.cpp @@ -576,7 +576,7 @@ m_cliPresentation(false), m_cliPrint(false), m_cliPrintAndExit(false), m_embedMo setupViewerActions(); - if ( m_embedMode != ViewerWidgetMode ) + if ( m_embedMode != ViewerWidgetMode && m_embedMode != UnknownEmbedMode ) { setupActions(); } if anyone feels like testing
I have just looked at PageView event handling. It implements several scrolling commands trough the event system, and not trough action shortcuts. That is why you can still type all the letters, although PageView uses them as scrolling shortcuts. Only Page Down and Page Up are action shortcuts (and Shift+Down/Up for auto scrolling). This means only Space, Shift+Space, Shift+Down, and Shift+Up will be stolen, because these are action shortcuts. (Only scrolling.) Just for info. What happens when you trigger Save As trough Ctrl+Shift+S? Does it always save the Markdown preview instead of your document?
*** Bug 422203 has been marked as a duplicate of this bug. ***
*** Bug 416267 has been marked as a duplicate of this bug. ***
I just realized this was partially waiting on my input. Sorry about that. I've been using the kmarkdownwebview plugin for a while, but switching back to Okular, I can confirm this issue is still present in Fedora 32. Ctrl+Shift+S gives me a popup dialog: "The key sequence 'Ctrl+Shift+S' is ambiguous. Use 'Configure Shortcuts' from the 'Settings' menu to solve the ambiguity. No action will be triggered."
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kate/-/merge_requests/419
I marked this bug in the above Kate MR, although it's flagged as Okular bug. In my opinion the issue is either related to Kate or to KXMLGUI. The latter (or QMainWindow) seems to be responsible for handling shortcuts in the main menu bar.
Git commit 40ec8280266a89052612cef289a24caf172690bd by Christoph Cullmann, on behalf of Christoph Roick. Committed on 29/05/2021 at 12:11. Pushed by cullmann into branch 'master'. Work around conflicting shortcuts in preview plugin Do not let shortcuts issued within a preview widget propagate to the application's shortcut event handler. Instead handle the event while it's still a ShortcutOverride event to prevent the detection of seemingly ambiguous shortcuts. Also do not let actions defined inside the preview KPart capture shortcuts that are handled on the application level. Related: bug 386265 M +26 -0 addons/preview/kpartview.cpp M +4 -0 addons/preview/kpartview.h https://invent.kde.org/utilities/kate/commit/40ec8280266a89052612cef289a24caf172690bd