MARKDOWN Class for Xojo™ - now available

Sorry… I tried doing that once… but it was way too much effort to get it working, figuring out how Linux worked etc… But that is why I compiled it for Linux, to allow anyone who is a Linux Fan to try it. There is nothing OS dependent, so I really don’t see there being an issue. The class is 100% Xojo code, and uses standard agnostic coding practices.

LOL! That was a test, and you passed :slight_smile:

I have thought for a while that Xojo could help development for Linux when developing in other platforms by providing a single-click VM that can be easily used to just run the apps without bothering with the set-up.

I imagine providing such an image in a couple of popular formats (Parallels, VMWare, VirtualBox, QEmu, etc.) would be appreciated for Mac or Windows developers (and wouldn’t be a problem like releasing one with Windows or MacOS). Bonus points if it already has Xojo remote debugger in it and running :slight_smile:

There’s a bug in your demo app Dave. For some reason it is inserting an unordered list into a code fence. Here’s an example:

[code]Javascript code:

/*
 * This comment will be incorrectly converted to a HTML list!
 */
console.log("Bug!");
```[/code]

Outputs:

[code]<p>Javascript code:</p>
<pre class='codeblock'><code class='language-javascript'>
/*
<ul style='padding-top:10px'>
<li>This comment will be converted to an HTML list!
</ul>
</ul>
*/
console.log("Bug!");
`

[/code]

Expected output:

[code]

Javascript code:


/*
 * This comment will be converted to an HTML list!
 */
console.log("Bug!");
`
```
[/code]

As you can see, there are several issues with your class' output:
1. For some reason it's generating an unordered list within a [code]
```
[/code] block. This shouldn't happen.
2. In the (incorrect) [code]
    [/code] block it's not closing the [code]
  • [/code] tag 3. The [code]`[/code] tag is not correctly closed at the end. Also, why is the class injecting inline CSS to the [code]
      ?[/code] This isn't part of the specs and should be left up to the end user to style with a CSS stylesheet.

Thanks for pointing this out.
I have already corrected these items… it turns out it was an unforeseen side effect of changes last month

I will post an updated demo later today

your markdown example [with a list added]

Javascript code:
```javascript
/*
 * This comment will be incorrectly converted to a HTML list!
 */
console.log("Bug!");
```
* test
* test 2

now results in this

<p>Javascript code:</p>
<pre class='codeblock'><code class='language-javascript'>
/*
 * This comment will be converted to an HTML list!
 */
console.log("Bug!");
`
```

<ul class=list_top_pad>
<li>test
<li>test 2
</ul>

note : list_top_pad is part of CSS now

Interesting. I’ve never personally seen a closed

  • tag

  • Updated version of the demo is now available

    macOS
    Windows
    Linux

    Thanks for the quick patch. I still think there’s an issue though. It strips the newline characters from within a code block.

    This:

    [code]```javascript
    console(1);

    console(2);

    
    Outputs:
    
    [code]<pre class='codeblock'><code class='language-javascript'>
    console(1);
    console(2);
    `
    

    [/code]

    But I believe it should be:

    [code]


    console(1);

    console(2);
    `

    [/code]
    
    By stripping out the newlines, it hampers the ability to demonstrate well formatted code snippets.
    
    [quote=425347:@Jeff Tullin]Interesting. I've never personally seen a closed <LI> tag[/quote]
    It's optional except for XHTML compliance. In other words - there's no good reason to leave it out: [url=https://stackoverflow.com/a/20550925]StackOverflow [/url].

    ok… that is now fixed… and with a new option to the syntax. The ability to add line numbers. This is not part of the “Standard”, but has been implemented in various ways by many other engines.

    ```javascript linenum
    console(1);
    
    console(2);
    ```

    And Garry… I’m gonna give you a few more hours to find something else :slight_smile: then I’ll post this update

    be careful for what you wish for. :slight_smile:

    Rather he found something now, then an hour after I recompile it all :slight_smile:

    I was trying to make a bad scarcastic remark. it failed.

    I couldn’t resist digging…

    Haven’t found anything else yet though :slight_smile:

    https://www.w3schools.com/html/html_lists.asp

    And I already saw (many times) the </LI> tag…

    I hate to do this Dave but there’s another bug:

    This input:

    ### <a name="tith"></a>This is the Heading

    Produces this output:

    <h3><a name="tith"></a>This is the Heading</h3>

    It should be:

    <h3><a name="tith"></a>This is the Heading</h3>

    Currently, there is no way with your parser to include an inline anchor in a header.

    Reference parser:

    Garry… rather find bugs and fix them, them let them proliferate :slight_smile:
    Actually it kinda does handle that kind of situation… just not correctly it seems :frowning:

    First it does find certain HTML tags and keep them intact… but here wasn’t one of them… for example use

    in your example and the results are totally different. still wrong, but the HTML stayed intact.

    What it tries to do is insert a code fence for HTML. The problem is this inserts an extra line feed which screws up the ### in your example. but works for “most” situations

    The problem is determining what inside <> is HTML and what is just “stuff” that should be made “safe”

    Let me work on this… I have some ideas :slight_smile:

    Ok… I think I got it!
    Any text entity the starts with a “<” followed by a legit HTML tag and ends with “>” will be considered to be HTML and will be injected AS-IS. Any “<” or “>” not meeting these criteria will be converted to < and >. You can force this by escaping using \< or \>

    What a legit HTML tag is comes from https://developer.mozilla.org/en-US/docs/Web/HTML/Element

    thanks @Garry Pettet and @Dave S for find/fixing the bugs in this code so quickly. I know in the past I found an issue and let Dave know about it, stating that I was going to look at the source code later. Before I could get to the computer to look at the source code, he had it patched. the turn around on “hey I found an issue” to “hey its patched” is amazingly fast. thank you both!

    Appreciate the comments… OCD I guess :slight_smile:

    I’m going to update the example Markdown document, clean up some stuff… “test” it a bit more then give Garry a chance to break it again

    I can’t decide if I like this developing reputation I have for breaking things. I guess everyone needs a super power :slight_smile:

    Thanks for the great work Dave.