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 
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
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 2now 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
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 
then I’ll post this update
be careful for what you wish for.
Rather he found something now, then an hour after I recompile it all
I was trying to make a bad scarcastic remark. it failed.
I couldn’t resist digging…
Haven’t found anything else yet though
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 HeadingProduces 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.
Garry… rather find bugs and fix them, them let them proliferate
Actually it kinda does handle that kind of situation… just not correctly it seems 
First it does find certain HTML tags and keep them intact… but here wasn’t one of them… for example use
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
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
Thanks for the great work Dave.