On Thu, Jul 24, 2003 at 10:55:42AM -0600, Nick Pinckernell wrote:
> I agree with the first three items right out of
> http://dev.perl.org/rfc/5.pod
> 1. IT'S NOT INTUITIVE
"Intuitive" is one of those meaningless buzzwords like "maintainable".
It sounds good, but it's meaningless. See MJD's ta
On Fri, Jan 11, 2002 at 04:07:22PM -0700, Sean M. Burke wrote:
> [...verbatim sections...formatting sequences...]
While on the topic of verbatim sections, here is something I thinked
with my mind in a city far, far away in another country that uses
loons for money.
Verbatim sections are fundemen
On Fri, Jan 11, 2002 at 05:52:10PM -0700, Sean M. Burke wrote:
> So. Saying that Pod's canonical "normalization" is as XML begs the
> question of what the XML will look like.
> One point on which I am of two winds is this:
>
> Consider this input:
>
> =head2 Turn-Ons
>
> I like harpsichord mus
On Fri, Jan 04, 2002 at 11:29:20AM -0700, Sean M. Burke wrote:
> At 11:13 2002-01-04 -0500, Adam Turoff wrote:
> >[...]
> >Like many XML folks, I trust James implicitly when it comes to markup
> >languages; if he says that adding a macro facility such as =equate is a
&g
On Fri, Jan 04, 2002 at 01:19:24PM -0500, Adam Turoff wrote:
> On Fri, Jan 04, 2002 at 10:57:06AM -0700, Sean M. Burke wrote:
> > I'd like to read what he said.
>
> I'd say it's a flaw in pod that you can't import a policy
> like that with some
On Fri, Jan 04, 2002 at 10:57:06AM -0700, Sean M. Burke wrote:
> At 11:13 2002-01-04 -0500, Adam Turoff wrote:
> >The best idea Larry has blessed so far is the =use clause that
> >optionally makes Pod behave differently.
>
> Where was that discussed?
A perl6 list, probab
Sorry this is so long. This idea comes up every so often, and I don't
remember the last it was possible to lay all the issues on the table in
a single message.
On Thu, Jan 03, 2002 at 02:03:48PM -0700, Sean M. Burke wrote:
> So I've been thinking many Deep Thoughts lately about Pod.
>
> I have
On Sun, Dec 09, 2001 at 11:29:08PM -0700, Sean M. Burke wrote:
> The solution that most appeals to me currently, is to make this
> hypothetical module take Pod as input, and spit out XML as output, which
> the author of a Pod processor would then direct to whatever Pod parser he
> prefers.
Whil
