Bold/italic not highlighted across linebreaks

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create or enter a vimwiki file
2. Enter italic text, some of which spans multiple lines, e.g.,
<pre>
_one line_
_two
lines_
</pre>

What is the expected output? What do you see instead?
Both groups of text should be in italics, but only the first is.

What version of the product are you using? On what operating system?
The latest vimwiki from github (v2.0.1), on Debian.

Please provide any additional information below.
As a suggestion, I added the following two lines to the file 
`~/.vim/after/syntax/vimwiki.vim`:
{{{
syntax region italicTest start='\v<_\w' end='\v\w_>' skip='\v\\_'
highlight link italicTest Comment
}}}
When this file is present at the stated location, both single-line and 
multi-line italic regions are highlighted in the same way (here, as comments).

I don't intend this to solve the problem, merely to hint at how the bold/italic 
highlighting might be modified.

Original issue reported on code.google.com by charles....@gmail.com on 31 Aug 2012 at 5:26

[GoogleCodeExporter]

Is there no syntax highlighting for issues?  Man, that's ugly... sorry!

Original comment by charles....@gmail.com on 31 Aug 2012 at 5:28

[GoogleCodeExporter]

Is this solution still working fine?  What about html generation - does it 
still work?  Anyone else tested this?

Original comment by stu.andrews on 31 Dec 2012 at 4:32

[GoogleCodeExporter]

Just tried it, and it doesn't generate italic on the html for the two line "_", 
only for the single line. Also, on vim itself, instead of italic, highlighting 
is shown. So as the O.P. said, this doesn't solve the issue, only point in a 
possible direction...

Original comment by dkhorn...@gmail.com on 31 Dec 2012 at 7:21

[GoogleCodeExporter]

I expect that this would add a significant amount of complexity to the code, in 
addition to slowing it down.

As an alternative, multi-line italicized text can be achieved with an HTML 
block environment , e.g. with div tags

Original comment by stu.andrews on 31 Dec 2012 at 10:14

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

My example highlights code instead of italicizing it just for illustration 
purposes.  If you want it to italicize text, try this:

syntax region italicTest start='\v<_\w' end='\v\w_>' skip='\v\\_'
highlight link italicTest VimwikiItalic

It should be fairly straightforward to make a similar fix for multiline bolded 
regions.

The reason I say it's not a final solution is because one has to consider 
issues such as syntax regions contained in other regions, interaction between 
bold and italic, etc.  I think the software maintainers are better suited to 
handle these complexities.

Original comment by ch...@google.com on 4 Jan 2013 at 10:45

[GoogleCodeExporter]

The design decision to keep most of emphasis-like markup as inline-only is very 
sound. It limits the possible scope of those environments, which

* prevents the runaway environment breakage --- type {{{ on a new line in the 
middle of a wiki file to see it in action: everything after that line is 
suddenly "wrong", until you explicitly limit the scope by closing with }}}

* allows one to use _ * ` etc. for their literal values (provided you do not 
pair them up on the same line) - this is what makes wikis so simple to use, 
instead of having to learn some special escaping rules like in programming or 
other formal languages, just to be able to write a common character (e.g. "<" 
in HTML)

In essence, you are proposing to break a lot of things, and the only benefit is 
to be able to "more easily" italicize a larger portion of text - something that 
is almost never done by professional designers of books...  Besides, there is 
no limit on the line length in vim, so the one-line-only restriction for inline 
environments really does not prevent you from emphasizing an entire paragraph 
of text.

Original comment by tpospi...@gmail.com on 24 Feb 2013 at 5:03

• Changed state: WontFix

[GoogleCodeExporter]

I disagree with your reasoning, but I respect your design decision, and have 
decided not to pursue the matter.

Original comment by ch...@google.com on 6 Mar 2013 at 5:43