mdless not showing code blocks at all

[ttscoff]

mdless not showing code blocks at all

[ttscoff]

Ok, I'm getting this behavior on macOS Mojave as well now, I'll look into it.

[ttscoff]

Ok, v0.0.14 should solve most problems, please try it out and let me know.

[BenKettlewell]

I'm getting the following stack trace as well whenever the markdown has a code block. It works fine as long as there's no code.
I'm also using mdless 0.0.12 but a standard Ubuntu shell.

Traceback (most recent call last):
        8: from /usr/local/bin/mdless:23:in `<main>'
        7: from /usr/local/bin/mdless:23:in `load'
        6: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/bin/mdless:17:in `<top (required)>'
        5: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/bin/mdless:17:in `new'
        4: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:133:in `initialize'
        3: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:437:in `convert_markdown'
        2: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:437:in `gsub!'
        1: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:457:in `block in convert_markdown'
/var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:324:in `hiliteCode': undefined method `split' for nil:NilClass (NoMethodError)

[ttscoff]

I'm not experiencing this with 0.0.12 on my Mac, wondering if it's OS specific.

…

On 16 Jul 2019, at 16:24, BenKettlewell wrote: I'm getting the following stack trace as well whenever the markdown has a code block. It works fine as long as there's no code. I'm also using mdless 0.0.12 but a standard Ubuntu shell. ``` Traceback (most recent call last): 8: from /usr/local/bin/mdless:23:in `<main>' 7: from /usr/local/bin/mdless:23:in `load' 6: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/bin/mdless:17:in `<top (required)>' 5: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/bin/mdless:17:in `new' 4: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:133:in `initialize' 3: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:437:in `convert_markdown' 2: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:437:in `gsub!' 1: from /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:457:in `block in convert_markdown' /var/lib/gems/2.5.0/gems/mdless-0.0.12/lib/mdless/converter.rb:324:in `hiliteCode': undefined method `split' for nil:NilClass (NoMethodError) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #31 (comment)

[ronangaillard]

I'm using OSX also

[JaviCerveraIngram]

Same problem here on Linux Mint 19.1 (based on Ubuntu 18.04).

[kscz]

I have the same issue, Ubuntu 18.04 -

• ruby 2.5.1p57 (installed from ubuntu repositories)
• mdless 0.0.12

I don't see any errors or useful messages when running with -d4

I tried installing pygmentize, but the behavior was unchanged. Please let me know if there's something I can do to help debug this issue!

[ttscoff]

Ok, pushed gem for 0.0.13, and source is updated in code and releases page. Give it a whirl and let me know if it doesn't solve the issue for you.

[kscz]

Seems to have fixed the missing code issue! Thanks!

There's some other weirdness in my output which confuses me...

It looks like slightly malformed markdown mdless doesn't like: https://github.com/vector-im/riot-web/blob/develop/README.md#setting-up-a-dev-environment - the first section has"``` bash" as the opening of the codeblock (note the space between the triple backtick and "bash"), which mdless emits as:

--[  ]--------------------------------------------------------------------------------------------

--[ END  ]----------------------------------------------------------------------------------------

It also looks like bare codeblocks with no type hints get garbled: https://github.com/espressif/esp-idf/blob/master/examples/protocols/sockets/tcp_client/README.md#tcp-server-using-netcat

Renders like this for me:

--[ CODE ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[0;30m~ [0;37;40m nc[0;37;40m -l[0;37;40m 192.168.0.167[0;37;40m -p[0;37;40m 3333[0;37;40m                                                                                                                                                                                    [0;37m
--[ END CODE ]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Despite the broken escape sequences, some of the escaped output is being consumed. If I run mdless README.md -P | less -R you can see some of the escape sequences are being consumed but not others:

--[ CODE ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[39;49;00m[0;30m~ [39;49;00m[0;37;40m nc[39;49;00m[0;37;40m -l[39;49;00m[0;37;40m 192.168.0.167[39;49;00m[0;37;40m -p[39;49;00m[0;37;40m 3333[39;49;00m[0;37;40m                                                                                                                                                                                    [39;49;00m[0;37m
--[ END CODE ]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Adding in bash gives nicely rendered output:

--[ BASH ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
nc -l 192.168.0.167 -p 3333
--[ END BASH ]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

It is colorized in some code blocks when there's no type hint, but interspersed with garbled escape sequences. I don't know what the extra escape sequences in the bare version come from.

I can pop these open as separate issues if you would prefer. Thanks again for the help!

[ttscoff]

Yeah, I was seeing the broken escapes occasionally but thought I had fixed it. It seems to be an error in pygments caused by passing an invalid lexer to it, which is derived from the language on the code block (or falls back to a hashbang if it exists). I might just need to have it ensure a valid lexer and default to letting pygments guess if it doesn't have one. I'll update as soon as I'm able. Thanks, Brett

…

On 11 Sep 2019, at 15:42, Kit Sczudlo wrote: Seems to have fixed the missing code issue! Thanks! There's some other weirdness in my output which confuses me... It looks like slightly malformed markdown mdless doesn't like: https://github.com/vector-im/riot-web/blob/develop/README.md#setting-up-a-dev-environment - the first section has"\`\`\` bash" as the opening of the codeblock (note the space between the triple backtick and "bash"), which `mdless` emits as: ``` --[ ]-------------------------------------------------------------------------------------------- --[ END ]---------------------------------------------------------------------------------------- ``` It also looks like bare codeblocks with no type hints get garbled: https://github.com/espressif/esp-idf/blob/master/examples/protocols/sockets/tcp_client/README.md#tcp-server-using-netcat Renders like this for me: ``` --[ CODE ]-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [0;30m~ [0;37;40m nc[0;37;40m -l[0;37;40m 192.168.0.167[0;37;40m -p[0;37;40m 3333[0;37;40m [0;37m --[ END CODE ]---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ``` Despite the broken escape sequences, some of the escaped output is being consumed. If I run `mdless README.md -P | less -R` you can see some of the escape sequences are being consumed but not others: ``` --[ CODE ]-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [39;49;00m[0;30m~ [39;49;00m[0;37;40m nc[39;49;00m[0;37;40m -l[39;49;00m[0;37;40m 192.168.0.167[39;49;00m[0;37;40m -p[39;49;00m[0;37;40m 3333[39;49;00m[0;37;40m [39;49;00m[0;37m --[ END CODE ]---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ``` Adding in `bash` gives nicely rendered output: ``` --[ BASH ]-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nc -l 192.168.0.167 -p 3333 --[ END BASH ]---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ``` It is colorized in some code blocks when there's no type hint, but interspersed with garbled escape sequences. I don't know what the extra escape sequences in the bare version come from. I can pop these open as separate issues if you would prefer. Thanks again for the help! -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #31 (comment)

[BenKettlewell]

Confirmed that .14 fixed it for me.

Thanks for the update! <3
I had started using the MarkdownPreview vim extension but I much prefer being able to view it directly in the terminal!

[kscz]

Thanks for the prompt updates! 0.14 seems to have resolved all the issues for me. The only remaining oddity is a character indicating a newline which appears in codeblocks with no type, but that's not really an issue.

[ttscoff]

That ¬ character is intentional. I found that with the way I changed some of the highlighting, it was helpful to see where wrapped lines actually ended. I plan to make it customizable/optional in an upcoming release.