options.lineNumbers option

[andr2]

Added options.lineNumbers

marked('hello\n\nhello2', { lineNumbers: true })

Renders

<p>hello</p>
<span line-number="2"></span><p>hello2</p>

Also added lineNumber renderer

Renderer.prototype.lineNumber = function(line) {
  return '<span line-number="' + line + '"></span>';
};

WARNING: Degrading in performance in node.js due to Extract Method refactoring. From 3496ms to 4008ms.
Tests passed

[Feder1co5oave]

What possible use of this is there?
Also sorry, but output is awful:

### Spurious wakeups

The `pthread` documentation says

> Spurious wakeups from the `pthread_cond_wait()` function may occur. Since the return from `pthread_cond_wait()` does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.

When a "spurious wakeup" happens, a thread that is currently blocked on `pthread_cond_wait()` is awaken, even if no other thread has called `pthread_cond_signal()` on that condition. This means one must re-evaluate the condition every time the `pthread_cond_wait()` returns and, if needed, call it again.

A good rule of thumb is to always wait upon a condition variable within a loop which checks the condition every time:

```cpp
while (counts[my] < N_THREADS)
    pthread_cond_wait(&condition, &mutex);
\```

<h3 id="spurious-wakeups">Spurious wakeups</h3>
<span line-number="2"></span>
<p>The <code>pthread</code> documentation says</p>
<span line-number="4"></span>
<blockquote>
    <span line-number="6"></span>
    <p>Spurious wakeups from the <code>pthread_cond_wait()</code> function may occur. Since the return from <code>pthread_cond_wait()</code> does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.</p>
</blockquote>
<span line-number="6"></span>
<p>When a &quot;spurious wakeup&quot; happens, a thread that is currently blocked on <code>pthread_cond_wait()</code> is awaken, even if no other thread has called <code>pthread_cond_signal()</code> on that condition. This means one must re-evaluate the condition every time the <code>pthread_cond_wait()</code> returns and, if needed, call it again.</p>
<span line-number="8"></span>
<p>A good rule of thumb is to always wait upon a condition variable within a loop which checks the condition every time:</p>
<span line-number="10"></span>
<pre><code class="lang-cpp">while (counts[my] &lt; N_THREADS)
    pthread_cond_wait(&amp;condition, &amp;mutex);
</code></pre>

[andr2]

I use it my editor/preview control. I think it works smooth.

Also added a code snippet:

Preview synchonization

Markdown preview block

For markdown preview block on scroll event you can use the following code.
toLine - float row number (for accurate and smooth synchonization)

function getOffset(toLine) {
    var children = _.toArray(containerEl.childNodes);
    var prev = { ln: 0, dom: { offsetTop: 0 } }
    for (var i = 0; i < children.length; i++) {
        var dom = children[i];
        var ln = dom.getAttribute && +dom.getAttribute("line-number");
        if (ln) {
            if (toLine <= ln)
                break;
            prev.ln = ln;
            prev.dom = dom;
        }
    }
    return prev.dom.offsetTop + (dom.offsetTop - prev.dom.offsetTop) / (ln - prev.ln) * (toLine - prev.ln);
}

ctrl.events.scroll.push(toLine => containerEl.parentNode.scrollTop = getOffset(toLine));

Ace editor integration

session.on("changeScrollTop", () => {
    ctrl.scroll({ top: editor.renderer.getScrollTop() / editor.renderer.lineHeight })
});

[andr2]

@Feder1co5oave line-number inside a blockquote is a bug. I will fix it.

[andr2]

Fixed blockquote bug.
If performance is critical maybe it will be better to inline find function

[shd101wyy]

Hi, I think the line number doesn't work properly for "list".
It didn't add line number for each "li"
Could you please have a look?
Thank you

[andr2]

@shd101wyy Hello! Unfortunately it only works for top level blocks, because it requires more serious refinement otherwise.
You can scroll proportionally by top level blocks

[shd101wyy]

Thx!

[paulocheque]

@andr2 I am having the same issue to solve. Did you stay with that solution? How is the final performance to the end user?

ps: I am using percentage of the editor/preview scroll position to synchronise the other panel.

[andr2]

@paulocheque yes. For nested blocks I scroll proportionally (see code sample above).
Performance is OK

[joshbruce]

Closing as stale, do not believe targeted specs support this, merge conflicts, and missing tests (??).

[KnIfER]

Nice. what is From 3496ms to 4008ms.?