Home → Problems →

Marked not previewing Block Code properly

• Edit

Cookie Bonanza

26 Apr, 2012 03:19 AM

Hi.

I noticed that the display of Markdown Block Code appears to have a problem.

Attached is a screen grab showing Markdown code in Mou, the same code previewed in Mou, and the same code previewed in Marked.

Two main problems: in a set of three indented lines, Marked doesn't notice the first line and in the other two lines doesn't keep words together - they get broken up arbitrarily.

See the screen grab for the example.

Thanks.

• block-code-preview.gif 143 KB

1. Support Staff 1 Posted by Brett on 26 Apr, 2012 04:25 AM

   

   Please attach a section of the file containing the text in question for testing.

   • Edit

2. 2 Posted by Cookie Bonanza on 30 Apr, 2012 10:10 PM

   

   Here's the file in question (see attached .zip file).

   I've edited the file since I posted this support request, so I tried Dropbox's versioning to go back - I think this is the same version as the screen grab is from.

   Anything else I can do to help?

   • problem.md.zip 2.99 KB
   • Edit

3. Support Staff 3 Posted by Brett on 30 Apr, 2012 10:38 PM

   

   What app are you editing this file in? The line endings are not consistently UNIX/Mac line endings, and the Markdown processor (any that I tried) is choking on them. Right before "Details have been…" for example, there's no newline, just a carriage return. This isn't obvious in an editor like Byword or Mou, but in something like TextMate or Sublime Text it becomes apparent. So… I can't really work around what the processor sees as a line break, but I'm curious what you're editing with as I might be able to provide an external solution.

   • Edit

4. 4 Posted by Cookie Bonanza on 30 Apr, 2012 11:04 PM

   

   I am in fact using Mou.

   Well, primarily Mou. Sometimes I use BBEdit or Textwrangler or (on iOS) Writing Kit or WriteRoom.

   In this particular case, I think I wrote the whole thing in Mou, because there was a lot of cut'n'pasting going on, so I doubt if I did it on the iPad.

   But here's a thing: sometimes after a paragraph Mou will insert two lines when I hit [return]. Could that be the source of the problem? It puts in a CR then a CR/LF or something?

   Anything else I can help with?

   --
   Cookie Bonanza
   Cookie's Bonanza Hour • http://cookie.calepin.co •
   Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

   • Edit

5. 5 Posted by Cookie Bonanza on 01 May, 2012 12:38 AM

   

   Hmm.

   I downloaded Sublime Text and took a look at the file.

   I can definitely see the problem: some things that display in Mou as a double paragraph return are only single ones in Sublime Text. Whoa! It's even worse in BBEdit!! The whole post is interpreted as 13 lines vs. the 48 lines Sublime sees.

   I have no idea what's going on here.

   I've just opened all my posts to date in Marked, and several of them show similar problems.

   Man, this is weird. I wonder if this is related to Mou's using Lion's auto-save method?

   • Mou seems to display the code correctly. Whatever the CR/LF/?? problem is, Mou skims right over in displaying the code and previewing it too. Mou has some preview problems (footnote display) but they're unrelated to this.
   • BBEdit opens the files, but doesn’t handle them well; a lot of the para returns are interpreted as an extra space so multiple paragraphs just become one long one - hence 48 lines becoming 13.
   • Sublime Text opens them better than BBEdit, but misses some double-para returns.
   • And Scriptogr.am seems to interpret and render these messed-up files just fine!

   I'm baffled.

   • Edit

6. Support Staff 6 Posted by Brett on 01 May, 2012 01:45 AM

   

   It's a matter of UNIX vs. DOS line endings, as far as I can tell. Some apps interpret any \r (return) as a newline, whereas most Mac apps will require a \n or \r\n to recognize it as a line break.

   I don't see any settings in Mou for controlling this, and I'm not sure what Mou is using to interpret for the preview that would recognize the output it's creating. I'll do some more testing with Marked's processor to see if I can make it work both ways, but you might want to drop a question to the Mou devs in the meantime and ask if they know anything about it.

   • Edit

7. 7 Posted by Cookie Bonanza on 01 May, 2012 01:57 AM

   

   It's definitely Mou.

   I just wrote a new post using my normal flow of write-edit-write-add-links-write some more.

   As long as it's straight start-at-the-top-and-keep-going it's fine, but once you go back and start adding paragraphs etc. Mou screws up. Opening the file in BBEdit and turning on "Show Invisibles" what Mou is doing instead of creating returns is something... else.

   BBEdit represents the characters as (excuse me, I don't know the unicode for these symbols):

   (upside-down-question-mark)(upper-right-corner-of-a-square)

   Eh, lemme see if Keyboard will show me what I need.

   Here we go. BBEdit shows these invisibles as ¿¬

   I think the ¬ is BBEdit's symbol for LF, but I don't know what the ¿ represents.

   And fwiw the proper description of those symbols is apparently:

   (Inverted Question Mark)(Not Sign)

   • Edit

8. Support Staff 8 Posted by Brett on 01 May, 2012 02:03 AM

   

   I actually don't know what the inverted question mark is, but that would probably be the issue. I'll see if I can replicate it and find a workaround.

   • Edit

9. 9 Posted by Cookie Bonanza on 01 May, 2012 02:24 AM

   

   I've dropped a note to the Mou developer. We'll see what he says.

   --
   @CookieBonanza • Cookie's Bonanza Hour • http://scriptogr.am/cookie/

   • Edit

10. 10 Posted by Cookie Bonanza on 03 May, 2012 02:02 AM

    

    Hold off on "fixing" Marked (at least for this).

    It turned out to be a settings mismatch in BBEdit. I had "translate line breaks" turned on, and the default set to Unix (LF). So when I opened a Classic Mac (CR) file (which is what Mou outputs) things would go sideways. I guess BBEdit is smart about that stuff with .txt files, but not so much .md ones.

    So it's my problem, not yours. All I have to do is figure out how to fix all the markdown files I've managed to screw up so far.

    You may still want to devise a workaround for the future: it seems that as you pointed out there are programs that ignore the difference between CR and LF and render these mangled files just fine: it's just that Marked is not one of them.

    In the meantime, having finished a support thread at Mou, and now finishing this one at Marked, I'm off to start one up over at BBEdit.

    *sigh* All I wanted to do was write a blog.

    Thanks for your help.

    • Edit

11. Support Staff 11 Posted by Brett on 03 May, 2012 02:07 AM

    

    A simple regular expression should be able to clear up the issue for you. I think BBEdit even has some line-ending translation commands available. Worth looking into, anyway. Thanks much for the update.

    -Brett (on iPhone)

    • Edit

12. 12 Posted by Antonio Piccolb... on 19 Jun, 2012 07:31 PM

    

    Not sure it's the same problem, but all my fenced code blocks appear as one line. Editing with RStudio. Html source looks fine, in the browser it looks fine.

    • introduction-to-vectorized-API.md 7.57 KB
    • Edit

13. Support Staff 13 Posted by Brett on 19 Jun, 2012 07:37 PM

    

    Please check your behavior preferences and make sure that "Handle Fenced Code Blocks" is turned on.

    • Edit

14. 14 Posted by Antonio Piccolb... on 19 Jun, 2012 07:46 PM

    

    If one checks that, Marked goes unresponsive with 100% CPU usage even on restart.

    • Edit

15. Support Staff 15 Posted by Brett on 24 Jun, 2012 02:16 AM

    

    The issue with multiple fenced code blocks (CPU maxing out) is fixed for version 1.5.

    • Edit