It's painful to propose this, as I had invested quite some time into it, also by tuning some kparts plugins for optimized usage or even writing a new one, kmarkdownwebview, just for the preview purpose, and then doing some blog posts.
But after the initial proud-developer-and-testing phase I found myself in normal user life too often avoid using the plugin, due to the annoying shortcut issue. And then there are some minor papercuts as well which still are unsolved (mimetype changes, new document unknown mimetype, etc).

I never got lots of feedback, so have no idea how large any userbase of the plugin is and how much they rely on it now. There surely are some who at least tried it, and found it worthwhile to file some bug reports, cmp. https://bugs.kde.org/buglist.cgi?component=plugin-preview&product=kate&resolution=---

The feature itself surely is something very wanted still.

I would like to give a -1 for removing the plugin I think that the feature is really something that has potential to be great!

That said I have also disabled the plugin because of the shortcut problems, but I do think that it would be great if we could get changes in KParts that would allow us to embed a read-only-no-shortcuts part.

Would the needed changes in KPart be big?

Maybe we could just put a disclaimer that the plugin is a technology preview at the moment?

A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.

FWIW I have heard this idea several times over the last years from different directions, and I think a lot of applications would profit from having something like that.

In D16668#354093, @sars wrote:

I would like to give a -1 for removing the plugin I think that the feature is really something that has potential to be great!

We surely all agree about the feature in theory. It's the current implementation which sucks (too much) and which thus I propose to withdraw.

Would the needed changes in KPart be big?

From the short looks I had, this might need some more work (at least for me who is not that much into KXmlGui, where I suspect the real work is needed to reach flexibility with the app-global shortcuts registered for actions & Co). So far do not even have a rough idea how this could be approached
In short: No idea ;)

In D16668#354185, @brauch wrote:

A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.

FWIW I have heard this idea several times over the last years from different directions, and I think a lot of applications would profit from having something like that.

Chance is you also heard it often from me this year in multiple channels, every time when I was frustrated about having no instant idea how to fix it :P
(e.g. also for the wanted-to-have shortcuts in the documentation toolview of KDevelop)

-1. I would prefer if this plugin could stay until an alternative is implemented.
I use it like this: the tool view is collapsed most of the time. When I would like to check how my markdown would look like if it is rendered, I open the tool view and then close it (because of the hijacked shortcuts).

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

@gregormi @sars Is there a chance I could transfer the in-official maintainership of this plugin to you then?
Truth is I have lost my love for this plugin and do not care as much as would be good. D12131 e.g. had me passive besides helping to fix the related crashes in kdevelop. Any time I look at this plugin I rather start to think about fixing kxmlgui, but never with the needed amount of resources, so resultless.

In D16668#354713, @gregormi wrote:

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

The KParts plugin is chosen which is system/user globally selected as preferred one for embedded view. This selection though is only possible to edit with Plasma SystemSettings -> Applications -> File Associations -> text/markdown -> Embedded. The plan would have been to a) give a shortcut to open these settings from the plugin b) add a custom variant to the Kate Settings to allow overwriting those system/user global settings. But motivation to do that sadly also blocked by the key shortcuts issue.
Does changing the order in the settings work for you? If not, please tell, I would be still eager enough to fix that at least.

In D16668#357951, @kossebau wrote:

@gregormi @sars Is there a chance I could transfer the in-official maintainership of this plugin to you then?
Truth is I have lost my love for this plugin and do not care as much as would be good. D12131 e.g. had me passive besides helping to fix the related crashes in kdevelop. Any time I look at this plugin I rather start to think about fixing kxmlgui, but never with the needed amount of resources, so resultless.

You said the plugin as it is now, has no future. But the shortcut issue could be solved by removing all shortcut settings from the plugin, couldn't it?

In D16668#354713, @gregormi wrote:

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

The KParts plugin is chosen which is system/user globally selected as preferred one for embedded view. This selection though is only possible to edit with Plasma SystemSettings -> Applications -> File Associations -> text/markdown -> Embedded. The plan would have been to a) give a shortcut to open these settings from the plugin b) add a custom variant to the Kate Settings to allow overwriting those system/user global settings. But motivation to do that sadly also blocked by the key shortcuts issue.
Does changing the order in the settings work for you? If not, please tell, I would be still eager enough to fix that at least.

a) and b) sound like good ideas. Yes, changing the order in "File Associations -> text/markdown -> Embedded" works - thanks for this hint - I didn't know that this setting exist! But nothing to fix for you, then ;-)

In D16668#358000, @gregormi wrote:

You said the plugin as it is now, has no future. But the shortcut issue could be solved by removing all shortcut settings from the plugin, couldn't it?

The shortcuts are coming from the KParts plugins, not from the preview plugin itself. And removing the shortcuts from the respetive KParts plugins is not something that would be favoured by people, given those plugins are also used in other places where the key shortcuts are very wanted (because there the KParts plugins are used for the main document view). So IMHO not really a solution to explore more.

Yes, changing the order in "File Associations -> text/markdown -> Embedded" works - thanks for this hint - I didn't know that this setting exist! But nothing to fix for you, then ;-)

Good. Preferred outcome :)

I think one should not let perfect be the enemy of good.
You are right that the plugin has issues. But on the other side, it provides value for "many" users.
Given it is not on per default and people seem to use it, I would tend to keep it.
If there is a better replacement, one can phase it out.

Hi - this isn't a proposal for a fix, but as a keen user of the preview plug-in, I thought I'd mention my workaround - which is good enough to make it usable, which is what I want to be able to avoid having to switch tools for text creation/editing.

• assign CTRL+ALT+P to open/close preview in Kate shortcuts (CTRL+SHIFT+P conflicts with 'start presentation').

Maybe a small interim kludge would be to include this (or similar non-conflicting) assignment in the default - not pretty but makes the work so far not wasted. HTH