On Nov 30, 2009, at 4:14 PM, Ricardo Signes wrote: > I'd like to extend this definition a bit. I would replace the second > paragraph > with: > > "=begin formatname" > "=begin formatname parameter" > This marks the following paragraphs (until the matching "=end > formatname") as being for some special kind of processing. Unless > "formatname" begins with a colon, the contained non‐command > paragraphs are data paragraphs. But if "formatname" does begin > with a colon, then non‐command paragraphs are ordinary paragraphs > or data paragraphs. This is discussed in detail in the section > "About Data Paragraphs and "=begin/=end" Regions". > > It is advised that formatnames match the regexp > "m/\A:?[−a−zA−Z0−9_]+\z/". Everything following whitespace after the > formatname is a parameter that may be used by the formatter when dealing > with this region. Implementors should anticipate future > expansion in the semantics and syntax of the first parameter to > "=begin"/"=end"/"=for". > > This allows for constructions like: > > =begin syntax javascript > > =end syntax > > ...or... > > =begin table width(10) height(9) > > =end table > > ...or... > > =begin dialect Pod6 > > =end dialect > > I believe several parsers already allow this implicitly.
Makes sense to me, but I think that you need to update the regex to include the (optional) parameter. Something like: C<m/\A:?[−a−zA−Z0−9_]+(?:\s+[−a−zA−Z0−9_]+)?\z/> Best, David
