data-noescape and data-trim cannot be added to code blocks in markdown

[languitar]

I am unable to add marks to parts of highlighted source code in markdown slides.

One the one hand, the missing attributes data-noescape and possibly data-trim cannot be added to the code blocks from markdown using the <!-- .element... syntax.
On the other hand, inline html doesn't work correctly in case the code fragment contains newlines. In that case, the markdown parser breaks and separates the code fragment into multiple ones.

[denisrosca]

@languitar Did you manage to somehow get around this issue? I'm having the same problem.
It seems that empty attributes are completely ignored...

[languitar]

I haven't found a solution so far.

[DenizThatMenace]

Following are some observations and partial solutions, that sadly does not lead to a fix for this issue:

---

I realized, that boolean attributes (like data-noescape and data-trim, which do not have a value) are not considered by the plugin/markdown/markdown.js script, when parsing the <!-- .element... syntax.

I managed to patch that script, so that at least boolean data-... attributes are successfully parsed and added to the former html elements.

--- plugin/markdown/markdown.js
+++ plugin/markdown/markdown.js
@@ -307,7 +307,7 @@
 	function addAttributeInElement( node, elementTarget, separator ) {
 
 		var mardownClassesInElementsRegex = new RegExp( separator, 'mg' );
-		var mardownClassRegex = new RegExp( "([^\"= ]+?)=\"([^\"=]+?)\"", 'mg' );
+		var mardownClassRegex = new RegExp( "([^\"= ]+?)=\"([^\"=]+?)\"|(data-[^\"= ]+?)(?=[\" ])", 'mg' );
 		var nodeValue = node.nodeValue;
 		if( matches = mardownClassesInElementsRegex.exec( nodeValue ) ) {
 
@@ -315,7 +315,11 @@
 			nodeValue = nodeValue.substring( 0, matches.index ) + nodeValue.substring( mardownClassesInElementsRegex.lastIndex );
 			node.nodeValue = nodeValue;
 			while( matchesClass = mardownClassRegex.exec( classes ) ) {
-				elementTarget.setAttribute( matchesClass[1], matchesClass[2] );
+				if( matchesClass[2] ) {
+					elementTarget.setAttribute( matchesClass[1], matchesClass[2] );
+				} else {
+					elementTarget.setAttribute( matchesClass[3], "" );
+				}
 			}
 			return true;
 		}

However, this sadly does not solve this specific issue. Code-blocks in markdown are translated into <pre><code>... html tags, but the attributes are only inserted into the <pre> block, while they should be in the <code> block instead.

The following function does allow to copy boolean attributes from <pre> blocks to their inner <code> blocks and could theoretically be called afterwards.

// Copies the given boolean data-attribute from <pre> blocks to enclosed <code>
// blocks.
function addBoolAttrToPreCodeBlocks( boolAttr ) {
	// For any <pre> blocks in the current slide with given attribute.
	var nodes = document.querySelectorAll( '[' + boolAttr + ']');

	for( var i = 0, len = nodes.length; i < len; i++ ) {

		var node = nodes[i];

		if (node.nodeName == "PRE") {
			// Check if a <code> block is the only, single child.
			if (node.hasChildNodes() && node.childNodes.length == 1 &&
			    node.firstChild.tagName == "CODE") {
				// Check if <code> has attribute not already applied.
				var codeNode = node.firstChild;
				if (! codeNode.hasAttribute( boolAttr )) {
					codeNode.setAttribute( boolAttr, "");
				}
			}
		}
	}
}

However, the main problem regarding this issue is, that some of these attributes, like e.g. data-noescape, have no effect, because they would have needed to be attached before plugin/markdown/marked.js script is even called, which translates markdown into html/javascript.

So, the real problem is to somehow tell plugin/markdown/marked.js that some code-blocks in markdown need to be parsed differently, but I do not know how.
(The specific parse-function takes a boolean escaped parameter, which determines if the code should be escaped. But I have no clue how to set this value to false for some code-blocks.)

[gnzlbg]

Any chance of fixing this any time soon? Or any hints about how to fix this for those interested in doing so?

Not being able to use <mark></mark> tags in Markdown mode is a pretty big downside of the current implementation.

cc @hakimel