Recommended change for ButtonBar code section of PerformMarkdown

montana123

Okay I was going to give a long winded explanation of why buttonbar should be changed only to discover that you Vanilla devs must have changed it but not put it on the Addons server! Viewing page source shows version 1.2.4..

In the currently available 1.1 version of this addon, clicking on the "C" or code button inserts back ticks around multiple lines of code when really back ticks are for the rare use case of code inside a line.

With version 1.1 it inserts back ticks around the code which then get converted to <code> tags (looks like cr*p):

if (x=y) {
apple=orange;
}


With leading spaces it looks good:

    if (x=y) {
      apple=orange; 
      }

BUT, you have to remember to have a blank line before code or else it looks like:
if (x=y) {
apple=orange;
}

With <pre class="prettyprint"> it also looks good AND still works without needing a blank line:

        if (x=y) {
          apple=orange; 
          }

In the not yet released 1.2.4 version, it appears you have updated the code to insert 4 spaces in front of whatever is selected, which markdown will then convert to add <pre> and <code> tags around.

I would suggest to you that you might consider doing things slightly differently and instead insert a

<pre class="prettyprint">
</pre>

with no <code> tags at all.

It does the same job and if you have it installed, works with google's syntax highlighter as well.. It doesn't get screwed up if you happen to remove the blank line ahead of the code block. It isn't perfect though since it will be messed up by &'s and <'s in the code. But to less informed users it is obvious to them that it worked when they click on the "C" button they see the obvious text being added.

case 'code':
               var thisOpts = $.extend(markdownOpts, {
                  prefix:'',
                  opentag:'<pre class="prettyprint">',
                  closetag:'</pre>',
                  opener:'',
                  closer:''
               });
               $(TextArea).insertRoundTag('',thisOpts);
               // originally was: $(TextArea).insertRoundTag('`',markdownOpts);
               break;

Same code with spaces in front does have the advantage that you do NOT have to change < to &lt;. I had to make that change above with the <pre> method but did not have to make the change below with the leading space method since markdown.php handles that for us.

case 'code':
               var thisOpts = $.extend(markdownOpts, {
                  prefix:'',
                  opentag:'<pre class="prettyprint">',
                  closetag:'</pre>',
                  opener:'',
                  closer:''
               });
               $(TextArea).insertRoundTag('',thisOpts);
               // originally was: $(TextArea).insertRoundTag('`',markdownOpts);
               break;

In the end, I guess it is a coin flip. I like the visual indication of the <pre> but I don't like having to change < to &lt;.

Got me thinking: Why hasn't the markdown.php guys thought of this... Turns out they have!

An even better solution may be to use the new fenced code block feature of the new "extra" version of markdown.php:

http://michelf.ca/projects/php-markdown/extra/#fenced-code-blocks

Although it still seems to have the blank line requirement but at least there is a visual indication.

P.S. It would be great if you guys could post your latest ButtonBar and GooglePrettify to the Addons section.

peregrine

great ideas montana123

It would also be nice on this forum to get the buttonbar back when you **edit ** a message. I think somehow that may have been changed also.

It seems that bold B - is a hit or miss thing sometimes it converts it makes it bold as one would expect, but sometimes not.