The 1.0 code allows paragraph-based processing if $ParseParas?
is set to 1. --CliffordAdams
Some ideas for the markup processing code
Closing P tags
Idea: instead of processing for \n\n and inserting a <P> or </P><P>, look for blocks and enclose them.
- slice up the text into blocks, place in a @pagetext array and then process markup within each string
- more simply, create P tags with: $text =~ s[^(.*)(?=\n\n|[:*#;])] [<p>$1</p>]gm;
- instead of displaying external links in [single braces], just add a degree sign at the end of the last word in the link. I just think it looks nicer. STill use single braces for the formatting code though. See my home page at  for an example.
This approach could allow for increased subtlety in Wiki markup. For example, the * markup could be modified thus:
- A * at the start of the line marks the start of an OL block and the start of a child LI ...maybe I should use perl regexps and write it as ^*
- Subsequent ^* terminates the LI and starts a new one
- Close the block with \n\n
- No need for the double backslash patch to put line breaks inside list items -- a single \n can be processed into a BR, or child P blocks for that matter. This is easier on the writer and makes raw markup cleaner to read.
- Other elements like DL lists could be nested, though admittedly this may require perl contortions. Nice in theory but arg! at the practice.
- Need a double newline to break the LI block -- but most writers tend to do that anyway for clarity
- See also
- WikiPatches/TagBlankLines -- patch to handle paragraph markup processing