Closed bagage closed 7 years ago
crazy bug.
fixed this, inserted tag local links tables by default and also try render blockquotes somewhat okayish
Thanks for reporting.
let me know if ok for you
Almost - there is still an extra space after the URL, eg it looks like:
provided by [some links](https://github.com/) which is blablabla #input
provided by some links① which is blablabla #output
Plus another issue when there is some trailing spaces before a new line, where a < br/>
tag is applied:
More information: <-- there are trailing spaces here
https://github.com/axiros/terminal_markdown_viewer/
More information:<br />https://github.com/axiros/terminal_markdown_viewer/
Apart of that everything works great (nice use of ①, ② in multiple links sections 👍 ).
hi, can you paste a non working markdown source example here in a fenced code block, so that I can have it rendered and see the error? I do insert a space after the ① since in many fonts it would overlap the next character.
You can use this:
provided by [some links](https://github.com/) which is blablabla
More information:
https://github.com/axiros/terminal_markdown_viewer/
It looks like this:
strange don't have that
can u give me your -H output?
~/GitHub/terminal_markdown_viewer/tests $ ../mdv/markdownviewer.py -H links2.md
Here it is:
<p>provided by <a href="https://github.com/">some links</a> which is blablabla</p>
<p>More information: <br />
https://github.com/axiros/terminal_markdown_viewer/</p>
crazy, I don't have it.
~/GitHub/terminal_markdown_viewer/tests $ ../mdv/markdownviewer.py -H links2.md
<p>provided by <a href="https://github.com/">some links</a> which is blablabla</p>
<p>More information:
https://github.com/axiros/terminal_markdown_viewer</p>
~/GitHub/terminal_markdown_viewer/tests $
2 Possibilities:
a) Did you create the source on windows, i.e. with \r\n lineseps? So that the markdown.py creates the
but not with linux/mac \n ?
b) ~/GitHub/terminal_markdown_viewer/tests $ pip show markdown difference?
Mine is
~/GitHub/terminal_markdown_viewer/tests $ pip show markdown
Metadata-Version: 2.0 Name: Markdown Version: 2.6.7 Summary: Python implementation of Markdown. Home-page: https://pythonhosted.org/Markdown/ Author: Waylan Limberg Author-email: waylan.limberg [at] icloud.com Installer: pip License: BSD License Location: /XC/lib/python2.7/site-packages Requires: Classifiers: Development Status :: 5 - Production/Stable License :: OSI Approved :: BSD License Operating System :: OS Independent Programming Language :: Python Programming Language :: Python :: 2 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3 Programming Language :: Python :: 3.2 Programming Language :: Python :: 3.3 Programming Language :: Python :: 3.4 Topic :: Communications :: Email :: Filters Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI Tools/Libraries Topic :: Internet :: WWW/HTTP :: Site Management Topic :: Software Development :: Documentation Topic :: Software Development :: Libraries :: Python Modules Topic :: Text Processing :: Filters Topic :: Text Processing :: Markup :: HTML You are using pip version 8.1.2, however version 9.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command.
In any case I'll try filter the <br/> and make a \n out of them.
https://github.com/axiros/terminal_markdown_viewer/commit/a2464013ad5c53f4fe24c3b690fce3b0ee0a7bda should be able to deal with pain <br/>
in the md source.
Here's the output for pip show markdown
:
Name: Markdown Version: 2.6.7 Summary: Python implementation of Markdown. Home-page: https://pythonhosted.org/Markdown/ Author: Waylan Limberg Author-email: waylan.limberg [at] icloud.com License: BSD License Location: /home/gautier/.local/lib/python2.7/site-packages Requires:
For info I'm running pip
version pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)
Did you create the source on windows, i.e. with \r\n lineseps? So that the markdown.py creates the but not with linux/mac \n ?
No, I'm running Debian and created the file directly from the terminal.
a246401 should be able to deal with pain \
in the md source.
Hm, I actually does not on my side. The output is actually exactly the same as previous.
last try (sorry for bugging you so much).
https://github.com/axiros/terminal_markdown_viewer/commit/f048338a4283e55f07a71bce38871530252032a0
could you...?
Still the same :/. I'll investigate it on my own and let you know, at least I can say that it is reproducible on another Debian machine so it might be environment specific.
hey, thanks for the try on another debian box - did the same and ... BUM. got the br.
then...looking deeper I begin to understand a subtelty(?) of markdown, using a normal md to html editor (macdown):
foo:
bar
as soon as you insert a SECOND space behind the colon - the 'bar' is on the next line, due to a <br/>
generated. With no space or One space -> bar is on the same line.
real fun. Have to think how I do this, blindly replacing <br />
would break code insertions.
fun.
aah, damn I'm stupid, this is the forced line break feature of md. I totally forgot about it... now its all clear.
just trying here: no space
next one space after next
next
two spaces after next
hrmpf, ok github always breaks the line when the source has a line break. did the same with mdv. but the markdown.py does not. macdown also not. Aah and macdown has this option: render line break literally....
Really really have to go to common mark - thats a real spec.
OK now it definitively works and it works AWESOME! 🍾 Thanks for investigating this issue so much!
Thank you. Far away from awesome imho but at least the basics should work and this was a basic.
I see 2 different (and wrong?) behaviors when a file contains some markdown links.
First case: file starting by a link
Expected output
Actual output
Eg. all texts are being stripped but the links. Adding
-L
option shows the links as expected.Second case: the rest of the world
Expected output
Actual output
There, some HTML tags are inserted, even if option
-L
is NOT provided, which makes the readme less readable in my opinion. Plus many terminals already handle URI schemes well and make them clickable, so maybe these tags could be removed (if this is not a bug)?