Don't split backtick-quoted strings in paragraphs

[flwyd]

Vim help syntax recognizes backtick-quoted strings as short code snippets. It doesn't show the backticks, and applies a highlight group. However, it appears to only recognize these quotes if they appear on a single line. Vimdoc's paragraph algorithm will reflow comment text without regard to backtick placement, which can lead a snippet to be awkwardly split across two lines, losing the special treatment in the help buffer.

Example:

""                                                                               
" @public                                                                        
" @dict Lexer                                                                    
" Attempts to read an identifier at the current position, returning a            
" @dict(Token) with `type = 'identifier'` if successful and an empty dict        
" otherwise.  By default, this calls                                             
" `self.ReadPatternAs('\v^\k+', 'identifier')`  Language-specific lexers may    
" set a different ReadIdentifier function property.
function! foo#ReadIdentifier() abort dict
  " ...
endfunction

Vimdoc turns this into

Lexer.ReadIdentifier()                                *Lexer.ReadIdentifier()*
  Attempts to read an identifier at the current position, returning a
  |foo.Token| with `type = 'identifier'` if successful and an empty dict
  otherwise.  By default, this calls `self.ReadPatternAs('\v^\k+',
  'identifier')`  Language-specific lexers may set a different ReadIdentifier
  function property.

[dbarnett]

Ooh, I didn't even realize backticks were supported syntax. Wish they had official help to document exactly which syntax was supported instead of just having to read through the syntax file!

Line wrapping is currently done using python textwrap library (https://docs.python.org/3/library/textwrap.html), which has no support for special syntax AFAICT. To wrap any more intelligently we'd probably just need to stop using textwrap, pre-chunk the text ourselves, and roll our own function to figure out reasonable formatting.

BTW, we also have related #111 to avoid wrapping text inside literal blocks.