On October 16th Damian Conway wrote:
> If the contents are not a number, they are interpreted as an upper-case
> Unicode character name, or as a lower-case XHTML entity. For example:
One more problem: not all XHTML entities are lower-case. For example:
Ð Þ É Θ
For a complete list, see:
ht
Smylers pointed out (and Danny Brian confirmed):
The default entities are C<<>, C<>>, C<&>, C<'>, and
C<">.
I *knew* there was a good reason I shun XML! ;-)
Clearly five entities is I going to suffice. The synposis now reads:
To include named Unicode or XHTML entities, use the C> code.
On Oct 16, 2006, at 2:51 PM, Smylers wrote:
...
Perl 6 makes considerable use of E and E.
I think the only standard XML entities are C<<>, C<>>, and
C<&>. Particular XML languages can define further entities which
use that syntax, but they aren't included by default.
The default entiti
On October 7th Damian Conway wrote:
> Before Christmas, as promised!
>
> [DRAFT] Synopsis 26 - Documentation
Thank you for that, Damian! Apologies for taking a while to respond,
but I wanted to leave reading the document until I had a sufficient
chunk of time to do it justice. And I was very i
Brent wrote:
I've probably been hanging around Web standards nazis for too long,
but can we get a separate code to mark the title of a document that
can't be linked to (say, a book) along the lines of HTML's tag?
Hmm. Maybe. Care to nominate a letter for that? C<>, I<>, T<>, and E<> are
On 10/7/06, Damian Conway <[EMAIL PROTECTED]> wrote:
The C> formatting code specifies that the contained text is
to be set in an I
I've probably been hanging around Web standards nazis for too long,
but can we get a separate code to mark the title of a document that
can't be linked to (say, a b
Jonathan Lang wrote:
If I understand you correctly, the pain to which you're referring
would come from the possibility of a name that's reserved by the newer
version of Pod, but not by the older version. Wouldn't the simplest
solution be to let a Pod document announce its own version, much like
Tim Bunce wrote:
> That's going to cause pain when people using older parsers try to read
> docs written for newer ones. Would a loud warning plus some best-efforts
> fail-safe parsing be possible?
Indeed. And that's a important use-case.
But best-effort is difficult when you're talking about f
On Thu, Oct 12, 2006 at 03:57:01PM -0700, Jonathan Lang wrote:
> Tim Bunce wrote:
> >Damian Conway wrote:
> >> Dave Whipp wrote:
> >> >I'm not a great fan of this concept of "reservation" when there is no
> >> >mechanism for its enforcement (and this is perl...).
> >>
> >> What makes you assume the
Tim Bunce wrote:
Damian Conway wrote:
> Dave Whipp wrote:
> >I'm not a great fan of this concept of "reservation" when there is no
> >mechanism for its enforcement (and this is perl...).
>
> What makes you assume there will be no mechanism for enforcement? The
> standard Pod parser (of which I ha
On Thu, Oct 12, 2006 at 02:55:57PM +1000, Damian Conway wrote:
> Dave Whipp wrote:
>
> >I'm not a great fan of this concept of "reservation" when there is no
> >mechanism for its enforcement (and this is perl...).
>
> What makes you assume there will be no mechanism for enforcement? The
> stand
Dave Whipp wrote:
I'm not a great fan of this concept of "reservation" when there is no
mechanism for its enforcement (and this is perl...).
What makes you assume there will be no mechanism for enforcement? The standard
Pod parser (of which I have a 95% complete Perl 5 implementation) will
c
Jonathan Lang wrote:
The only thing that I'd like to see changed would be to allow a more
flexible syntax for formatting codes - in particular, I'd rather use
something analogous to the 'embedded comments' described in S02,
replacing the leading # with an appropriate capital letter (as defined
b
Damian Conway wrote:
> Delimited blocks are bounded by C<=begin> and C<=end> markers...
> ...Typenames that are entirely lowercase (for example: C<=begin
> head1>) or entirely uppercase (for example: C<=begin SYNOPSIS>)
> are reserved.
I'm not a great fan of this concept of "reservation" when the
The only thing that I'd like to see changed would be to allow a more
flexible syntax for formatting codes - in particular, I'd rather use
something analogous to the 'embedded comments' described in S02,
replacing the leading # with an appropriate capital letter (as defined
by Unicode) and insistin
I liked it. Just one nit, near the end:
>You can also preconfigure L, by
>naming them with a pair of angles as a suffix. For example:
>
> =comment Always allow E<> codes in any (implicit or explicit) V<>
> code... =config V<> :allow
>
> =comment All code to be italiciized...
Before Christmas, as promised!
I have a 95% complete Perl 5 implementation of a parser for this, but it is
too large to fit in the margin. I may release the beta of that next week, once
I'm home from my travels.
Damian
-cut--cut--cut--cut--cut-
=for c
17 matches
Mail list logo
