https://bugs.kde.org/show_bug.cgi?id=386251
Friedrich W. H. Kossebau <kosse...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
--- Comment #1 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
Two separate challenges here:
first one is that the KParts plugin, which shows the current text document,
does not get a url pointing to the file on the storage system currently bound
to the loaded document (e.g. a path on the local filesystem). But, in case the
KParts plugin supports the KParts Push API, a custom url representing the
source of the data, which is the working memory model of the document (with all
its current data, which might be different from the version in the storage or
not even there yet).
Or it gets the url to a temporary file used as buffer to pass the data to
KParts plugin which do not support the Push API.
So any relative path in the document shown by the KParts plugin are on a wrong
base, the KParts plugin itself does not know this though (and the API does not
have support yet for instructing some url rewriting).
The second challenge, though related, is to add support for custom path
rewriting (or perhaps even auto-detection of such a need), so one could
instruct the KParts plugin somehow how to rewrite relative urls.
No idea yet.
Having said all that...
Possibly one would be better off by creating a custom Markdown editor
application, based on KTextEditor lib and all the Kate plugins, and instead of
relying on the preview plugin and the KMarkdownWebView KParts plugin and the
rather simple, generic API which they are limited to, rather write custom code
which then gives all kind of flexibility and access to internals to achieve the
desired goals.
Such a KMarkdownEdit app could have its own Markdown parser, perhaps based on
that lib also used by the Okular Markdown plugin, to generate a central
Markdown document model which then powers both the syntax highlighting, the
rendering and other things like TOC. And by also having control about fetching
external resources, like images, path/url rewriting would also be more easily
done.
A swiss army knife is nice and useful in general, but for cutting bread using a
dedicated knife is nicer :)
--
You are receiving this mail because:
You are watching all bug changes.
