Parse Markdown in Stack Overflow content

[ctjlewis]

This library is awesome, and the only use I have for my SO account is to link it here at this point, but the content is not so legible as it frequently contains embedded code:

Not super trivial though: triple caret blocks need to be coerced to inline and trimmed if they run over the limit (as in the second code block in the screenshot), then parsed. I would say that second code block could still be included, just with the ellipsis: interface myInterface { [key: strin....

Thoughts?

[lowlighter]

Thanks for your suggestion!

It should be possible 🙂

Recently marked.js was added for metrics insights to parse markdown so it could be handled quite easily I guess. As for text formatting, a few CSS rules from the activity plugin can be reused.

Answers are not really "trimmed" actually, it's handled through CSS through with text-overflow: ellipsis and a semi-dirty hack 😅. It should already cover the case you mention, though maybe it'll render with "interface myInterface { [key: strin..." instead (i.e. ellipsis outside of code block)

Code hightlighting may be possible too without being too tricky, since prismjs is already used on the website

As for triple backticks, I'm not sure whether they should be inlined or not 🤔
It may render well in case of single lines like in your example case, but maybe multi-line answers would be weird?

[lowlighter]

I've merged #237 which to be able to parse markdown and make code highlighting in it.

I had some trouble with special stackoverflow syntax as code blocks use html comments (<!-- language: lang-xxx -->) instead of triple backticks (mainly for runnable snippets).

Currently it'll look like this, which does look nicer.

There are still some display issues that needs to be addressed, such as:

• text ellipsis is gone when last line is a code snippet
• headers are rendered inline (looks weird)
• css for token highlighting is pretty basic and some colors does not blend well on dark modes

---

Example: Setting <p> blocks in this response to width: 40ch.

I didn't know about this unit, it's actually pretty cool!
It would be definitely be more optimized and would reduce SVG filesize but I can't find an easy way to extract innerText (to skip html tags), crop text, and "re-html" text as just cropping text would probably leave unclosed tags.

If it does not require too much work (and does not seems too hacky), we could switch to it instead of using line-clamp property

[ctjlewis]

Absolutely incredible work @lowlighter, seriously top-notch.

[lowlighter]

If you want, you can beta-test this feature by using @master branch instead of @latest in your workflow.
Don't hesitate to report any bugs you found if you end up switching to it 🙂

[ctjlewis]

It looks so good!

One thing I did catch is that it HTML-encoded => to => in answer 2 here:

[lowlighter]

Should be fixed with 1b7ff7e 👍