Closed
Description
Expected behaviour
Markdown should render as below does using the code snippet:
Text line one.
Text line two.
Text line three.
Text line one.
Text line two.
Text line three.
Actual behaviour
Only the last line appears on a new line due to line two in the snippet having two spaces at the end. A carriage return should optionally(by default?) imply two spaces.
I'm not sure if this will cause breakage in certain desired rendering of markdown, but a settings option to render as Github does without having to add the two spaces would be nice(or perhaps having the enter key add two spaces?
Steps to reproduce
Text line one.
Text line two.
Text line three.
Metadata
Metadata
Assignees
Labels
No labels
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
pbek commentedon Mar 31, 2017
I'm sorry, https://github.com/hoedown/hoedown is used for converting the markdown to html and the markdown spec says that only two spaces trigger a newline.
Changing this would cause irritation for many users...
polarathene commentedon Mar 31, 2017
@pbek Would there be harm in having enter key add two spaces to satisfy the spec? (As a checkbox setting to enable). Github and a few other Markdown editors seem to differ from that spec.
Had a quick look around, hoedown has not had much dev activity(nothing in 2016?), there has been talk about following the CommonMark spec here. CommonMark seems like the better spec to support, it has some notable devs behind hailing from Github, Reddit and StackExchange among others.
Google has published a parser that conforms to the CommonMark spec in Rust and outputs HTML: pulldown-cmark, Rust has switched from hoedown to this parser for their documentation as discussed here.
The spec also identifies the issue I raised here with:
pulldown-cmark has an example on their ReadMe of the small snippet to treat soft line breaks as hard line breaks. This was also discussed on forums for CommonMark spec here. Github has also recently switched to using CommonMark, so that might indicate it being a fairly safe move, along with better performance/memory?
Would you be open to switching from hoedown to pulldown-cmark?
pbek commentedon Mar 31, 2017
I think automatically adding two spaces will do more harm than good in many cases where no spaces should be added...
pulldown-cmark is written in Rust, not C/C++...
polarathene commentedon Mar 31, 2017
@pbek Rust can be called from C via FFI(foreign function interface), should be possible to use :)
Fair point with automatically adding the spaces, if switching to pulldown-cmark is an option, you should be able to just pass on a boolean setting for treating soft line breaks as hard provided from QOwnNotes settings.
If you need any help on the Rust side I can give it a shot :) not too familiar with C or your codebase.
pbek commentedon Mar 31, 2017
I'm not sure if I want Rust code in a Qt project that should run on all platforms... 😸
polarathene commentedon Mar 31, 2017
@pbek Far as I know it should run on all platforms? Rust compiles to Linux/Windows/macOS. I don't know if I'll find the time for a while, but if you'd rather I give it a shot myself and send in a PR for review that's fine? :)
pbek commentedon Mar 31, 2017
Sure you can if it doesn't break any current feature of the preview, doesn't have any external dependencies, works with cmake and qmake and builds and runs on Linux (there are lots of distros), Mac and Windows. ;)
polarathene commentedon Mar 31, 2017
Is it ok to supply binary for each platform or does the rust source need to be compiled with everything else to be built by user? That would require rust compiler to be invoked, not familiar with cmake/qmake, but uhh rustc to compile the code would be an external dependency I guess?
pbek commentedon Mar 31, 2017
sorry, source code only. there are platforms that compile QOwnNotes theirself
yes :/
polarathene commentedon Mar 31, 2017
If having another compiler is an unacceptable dependency then there isn't a way to include Rust without supplying binaries far as I know :\
There seems to be two CommonMark parsers/renderers in C. I'm unable to assist with these but both seem to supply an option for converting soft line breaks into hard line breaks. cmark, md4c.
pbek commentedon Mar 31, 2017
Thank you for your research, but integrating such libraries is always a bit of a pain. I cannot promise that I take on that endeavor without pressing needs to do so....
pbek commentedon Apr 1, 2017
But if you really want to use an other markdown to html converter very badly you could write a script with the help of
notetomarkdownhtmlhookand use your own one.see:
http://docs.qownnotes.org/en/develop/scripting/README.html#notetomarkdownhtmlhook.
polarathene commentedon Apr 2, 2017
@pbek thanks I might give that a try :)
Out of curiousity what is the benefits from using Qt widgets in the preview pane over a webview? With a webview they'd be better styling options as well as fixes for a styling bug(Qt bug with lists from memory), however I'm guessing that'd lose features like note link integration?
pbek commentedon Apr 2, 2017
plenty of reasons: speed, memory consumption, size of the packages (when libraries are included), the webview that was present in qt 5.3 is now deprecated, but qt 5.3 compatibility is still needed for debian...