turndown

turndown copied to clipboard

It would be great to be able to set line-width for content. That is, if I want an 80-char line, the last whitespace before 80-chars turns into a \n. This is especially useful for <blockquote>.

This can be done at the moment

// a general fillColumn function

const fillColumn = function (width, s) {
  if (s.length <= width) {
    return s
  } else {
    const head = s.slice(0, width)
    const idx = head.lastIndexOf(' ') + 1
    return s.slice(0, idx) + '\n' + fillColumn(width, s.slice(idx))
  }
}

const options = {
  converters: [
    {
      filter: 'blockquote',
      replacement: function (content) {
        content = content.trim()
        content = content.replace(/\n{3,}/g, '\n\n')
        content = fillColumn(78, content)
        content = content.split('\n').map(e => '> ' + e).join('\n')
        // content = content.replace(/^/gm, '> ')
        return '\n\n' + content + '\n\n'
      }
    }
  ]
}
const tag = `<blockquote>Within that group of sufferers, however, the condition varies 
widely. For the vast majority, the problem is not so much 
about detecting a face. Prosopagnosics can see eyes, noses
 and mouths as clearly as anyone else. </blockquote>`
p(toMarkdown(tag, options))

// > Within that group of sufferers, however, the condition varies widely. For the 
// > vast majority, the problem is not so much about detecting a face. 
// > Prosopagnosics can see eyes, noses and mouths as clearly as anyone else.

I would recommend not to hardcode such set line-width function in this package. A general implementation could be provided in the doc as a hint to users.

One of the difficulties with setting a line-width is handling nested elements. For example, say you have some nested lists inside a blockquote. If every converter added a line break at 80 characters, then the eventual output would end up being longer than 80 characters because the list and block quote converters each add characters to the beginning of a line.

In order for this to work, a converter would need to "know" the element's context, and how far it has already been offset. It's not impossible, but would require some figuring out.

Then it might be best to do this in a post-processing step. But that would be a super-annoying post-processing with a requirement to know how to continue each style of line.

But that would be a super-annoying post-processing with a requirement to know how to continue each style of line.

Exactly 😫