[perl6/specs] c2d66a: Try to fix pod

v6d.pod Log Message: --- Try to fix pod

[perl6/specs] 030df4: Fix POD error

v6d.pod Log Message: --- Fix POD error

[perl6/specs] 845eb7: Typos and POD fixes in S02

-bits.pod Log Message: --- Typos and POD fixes in S02

[perl6/specs] d8869f: Pod would be an IO::Handle, not an IO::Path

: M S02-bits.pod Log Message: --- Pod would be an IO::Handle, not an IO::Path Commit: a5df488e95515f034982d7a5d844a0c322c5afa2 https://github.com/perl6/specs/commit/a5df488e95515f034982d7a5d844a0c322c5afa2 Author: Elizabeth Mattijsen Date: 2014-10-05 (Sun, 05 Oct 2014

[perl6/specs] ceebcf: Add "splat"; Fix some POD errors and long lines.

S99-glossary.pod Log Message: --- Add "splat"; Fix some POD errors and long lines.

[perl6/specs] 5aed9c: Fix some minor POD errors

S17-concurrency.pod M S28-special-names.pod M S32-setting-library/IO.pod M S99-glossary.pod Log Message: --- Fix some minor POD errors Stops perldoc complaining about missing encodings and parser confusion. Commit: 03abe1fd328c8547968c38e160c9931887e9df47 https

[perl6/specs] 8c901d: Refer to .content method for Pod blocks rather tha...

-documentation.pod Log Message: --- Refer to .content method for Pod blocks rather than .contents

[perl6/specs] 64799d: Fixing pod errors in S05

-regex.pod Log Message: --- Fixing pod errors in S05 nested lists were messed up around line 2270

[perl6/specs] 1446a9: Remove some more pod-based authoritative info

: M S11-modules.pod Log Message: --- Remove some more pod-based authoritative info

[perl6/specs] 800d9f: Remove pod tags as a source of meta-information

: M S19-commandline.pod Log Message: --- Remove pod tags as a source of meta-information Meta-information of a compilation unit will need to be specified in the (currently being specced) META.info file of a distribution.

[perl6/specs] 3e8a4d: Use pod compunit credentials as defaults only

: M S11-modules.pod Log Message: --- Use pod compunit credentials as defaults only Leave all the nitty gritty to the actual implementation on the "install" interface.

[perl6/specs] 6af26e: s/Pod6::/Pod::/g to match Rakudo and Niecza

S26-documentation.pod Log Message: --- s/Pod6::/Pod::/g to match Rakudo and Niecza

[perl6/specs] f6636e: [S21] Fixed some POD formatting errors.

-foreign-code.pod Log Message: --- [S21] Fixed some POD formatting errors. The errors were mainly problems with item lists and missing whitespace around directives.

[perl6/specs] a95049: [S02] fix POD error

-bits.pod Log Message: --- [S02] fix POD error

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

> Thank you damian, i will apply that patch, Much appreciated, Herbert! Damian

[perl6/specs] 46a599: removing "antiquities" regarding Pod, applying pat...

S02-bits.pod Log Message: --- removing "antiquities" regarding Pod, applying patch by damian Commit: a65c854a075054fedb5524b8897d11ecd0936333 https://github.com/perl6/specs/commit/a65c854a075054fedb5524b8897d11ecd0936333 Author: Herbert Breunung Date: 2012-

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

> So we changed them to what the syntax and semantics were telling us they > should be: lower-case. > > But this change broke the one-to-one mapping between Pod sections and > Pod-access variables. Previously it was: > > =pod<-> $=pod > =UserD

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

for built-ins (should be lower-case, but aren't) and the semantics of upper-case (should be semantic blocks, but aren't). So we changed them to what the syntax and semantics were telling us they should be: lower-case. But this change broke the one-to-one mapping between Pod sections and P

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

l-names.pod > > Log Message: > --- > pod vars are now lowercase as seen in > 3e1a9a5a576b90e9eeabdb7083d16431513513f2 > > >

[perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

S28-special-names.pod Log Message: --- pod vars are now lowercase as seen in 3e1a9a5a576b90e9eeabdb7083d16431513513f2

[perl6/specs] 3ac109: Disallow Pod blocks inside of Formatting Codes.

S26-documentation.pod Log Message: --- Disallow Pod blocks inside of Formatting Codes. Commit: bf64672f51ab45faa3059eb428532551bcb4ea74 https://github.com/perl6/specs/commit/bf64672f51ab45faa3059eb428532551bcb4ea74 Author: Tadeusz Sośnierz Date: 2011-08-21 (Sun, 21

[perl6/specs] a68bbb: [S19] break up unintentional pod formatting code

Log Message: --- [S19] break up unintentional pod formatting code Commit: e144eacb2967f40a782e439d527a65cc0a577f8e https://github.com/perl6/specs/commit/e144eacb2967f40a782e439d527a65cc0a577f8e Author: Fitz Elliott Date: 2011-01-29 (Sat, 29 Jan 2011) Changed paths: M S32

Re: How are unrecognized options to built-in pod block types treated?

Darren (>): > Read what I said again.  I was proposing that the namespace comprised of > names matching a pattern like this: > >  /^ <[A..Z]>+ | <[a..z]>+ $/ /^ [<[A..Z]>+ | <[a..z]>+] $/ // Carl

Re: How are unrecognized options to built-in pod block types treated?

a more robust and modern namespace system, however. Using it would seem wise. > > Explicit versioning is your friend. > > > > Can I get some support for this? > > Not from me. ;-) > > I think it's a dreadful prospect to allow people to > write documentation th

Re: How are unrecognized options to built-in pod block types treated?

On 2010-08-04, at 7:43 pm, Darren Duncan wrote: > A parallel solution would be that POD can declare a version, similarly to how > Perl code can declare a Perl version, whose spec it is expected to be > interpreted according to. I thought that was more or less how it worked anyway. You

Re: How are unrecognized options to built-in pod block types treated?

Brandon S Allbery KF8NH wrote: On 8/4/10 21:26 , Darren Duncan wrote: jerry gay wrote: are there codepoints in unicode that may be either upper-case or lower-case, depending on the charset? if so, then there's ambiguity here, depending on the user's locale. i suspect not, but languages are st

Re: How are unrecognized options to built-in pod block types treated?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/4/10 21:26 , Darren Duncan wrote: > jerry gay wrote: >> are there codepoints in unicode that may be either upper-case or >> lower-case, depending on the charset? if so, then there's ambiguity >> here, depending on the user's locale. i suspect no

Re: How are unrecognized options to built-in pod block types treated?

l have to rewrite when the Pod spec gets updated. Or, alternatively, to require all Pod parsers to be infinitely backwards compatible across all versions. :-( Damian

Re: How are unrecognized options to built-in pod block types treated?

sumed to be there by default. This is somewhat analogous to the main:: namespace for Perl code. A parallel solution would be that POD can declare a version, similarly to how Perl code can declare a Perl version, whose spec it is expected to be interpreted according to. If POD declares that

Re: How are unrecognized options to built-in pod block types treated?

Aaron wrote: > I dislike "reserved" in this context, but understand why the namespace has > to be shared. For config options, I'd say anything should go, but people > inventing their own config options should be aware that across N release > cycles, new options may be introduced. ...which means t

Re: How are unrecognized options to built-in pod block types treated?

when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. are there codepoints in unicode

Re: How are unrecognized options to built-in pod block types treated?

ot. Is this allowed? > S26 only tells me this about config options: > > "Pod predefines a small number of standard configuration options that > can be applied uniformly to any built-in block type." > > To me, "predefines" could mean either "we made these for

Re: How are unrecognized options to built-in pod block types treated?

ognized reserved config options generate > at least a warning when they are parsed. Mixed-case config options > should be freely available to users and the parser should simply > accept them without complaint and include them in the internal data > structure it builds, whereupon they will

Re: How are unrecognized options to built-in pod block types treated?

available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian

How are unrecognized options to built-in pod block types treated?

Straight to an example: =for head1 :image Steaming hot C loops As far as parsing goes, that's valid Perl 6 Pod. You're perhaps more used to seeing it as '=head1', but S26 asserts the equivalence of these two forms. The reason I'm using the paragraph bl

POD classes -- a suggestion

I'd really like to be able to assign a class to POD documentation. Here's an example of why: class Widget is Bauble #= A widget is a kind of bauble that can do stuff { has $.things; #= a collection of other stuff #==XXX{ This variable needs to be replaced for politic

Re: More flexible POD

Being on holidays, it is not easy to follow threads closely, so if I repeat things other people have said already, I apologize beforehand. My responses may b late as well. Two years ago, I discussed various options, which compared POD to features in to other languages and suggested various

Fwd: More flexible POD

Woops - forgot to reply all (I'm on an irritating mixture of lists which set reply-to and don't, and I never remember which is which). Sorry! -- Forwarded message -- From: Matthew Walton Date: Tue, Aug 11, 2009 at 7:10 AM Subject: Re: More flexible POD To: Jon Lang

More flexible POD

Masak's Journal[1] identifies a couple of problems involving the interaction of POD with block-form classes - one in the article itself, and another in the comments that follow. The first is that a mixture of indented block-form classes and non-indented POD is visually very ugly. The seco

Re: pod variables?

On Fri, 27 Feb 2009, Darren Duncan wrote: Jon Lang wrote: Under the section about twigils in S02, "$=var" is described as a "pod variable". I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wonderin

Re: pod variables?

Jon Lang wrote: Under the section about twigils in S02, "$=var" is described as a "pod variable". I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil; if they aren'

pod variables?

Under the section about twigils in S02, "$=var" is described as a "pod variable". I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil; if they aren't, I'd expec

Re: Perl 6 pod processor in Perl 5

* Gabor Szabo (szab...@gmail.com) [090212 06:44]: > As an experiment to check how we could reuse CPAN to distribute Perl 6 > packages. > > Not surprisingly neither of them can handle the perl pod. > I contacted both maintainers asking to look into it suggesting > to use Perl6:

Perl 6 pod processor in Perl 5

Perl6-Conf/ http://kobesearch.cpan.org/dist/Perl6-Conf Not surprisingly neither of them can handle the perl pod. I contacted both maintainers asking to look into it suggesting to use Perl6::Perldoc of Damian but it is quite old. Is there any other module written in Perl 5 that could parse a p

S*.pod edits submissions

I have changed files at waiting for someone in authority to merge.

Re: POD in the test suite

On Fri, Jan 18, 2008 at 10:54:11AM +0100, Moritz Lenz wrote: : I noticed that many test files contain "old" POD like this: : : =pod : : some description here : : =cut : : : Should that all be replaced by the new POD? : : =begin description : : text here : : =end description Jah,

POD in the test suite

I noticed that many test files contain "old" POD like this: =pod some description here =cut Should that all be replaced by the new POD? =begin description text here =end description -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Descriptio

Re: Some Things I'd Like To Do With Pod

On 22/06/07, brian d foy <[EMAIL PROTECTED]> wrote: ===Per class documentation, not per file documentation Related to the one above, I'd like to have NAME, SYNOPSIS, etc. for each class, not just per file. Well, what I really want is the Smalltalk class and method browsers, but I know I'm no

Some Things I'd Like To Do With Pod

I have a feeling we've sorta assumed some use cases for whatever Pod design we're advocating, so I thought I'd write down what I'd like to do with Pod. At this level, I don't care how it gets done, which model it uses, or anything else. This isn't a fantasy wishli

Re: Pod 6: ease of implementation vs easy of use

* Damian Conway ([EMAIL PROTECTED]) [070616 23:21]: > I will, however, take a moment to answer the accusation that I appear to > have redesigned Pod the way I did in order to make implementation > easier... The opposit: your work is known to seek the corners of the language which hurt

Pod 6: ease of implementation vs easy of use

I'm not going to argue about the design of Pod 6 any more. As both Mark and brian have pointed out, this really comes down to philosophical differences that no amount of discussion is going to resolve. In any case, I'm sure that Larry now has plenty of "grist" from w

Re: POD <-> Code entanglement

=requires bar is the barstest parameter Which is close to how OODoc is extending POD for Perl5. IMO We can (should) do better for Perl6. -- MarkOv Mark Overmeer MSc

Re: POD <-> Code entanglement

;s a horror! And if you really like above syntax, why not define =method the method synopsis goes here =option foo is the fooiest parameter =default foo 10 =requires bar is the barstest parameter Which is close to how OODoc is extending POD for Perl5. IMO We c

Re: POD <-> Code entanglement

Thomas Wittek wrote: > Moritz Lenz: >> =begin pod >> >> =head3 C >> [..] >> =end pod >> >> method from_string(Str $s){ >> # implementation of that method here >> } >> >> Since method signatures are very expressive in

Re: POD <-> Code entanglement

Thomas Wittek wrote: > I mean POD uses constructs like headlines, lists, blocks, italic etc. > which all describe _how it looks like_ and not _what it is_. I think Damian would take exception to that statement. He worked quite hard to make sure that POD describes _meaning_ rathe

Re: POD <-> Code entanglement

Mark Overmeer schreef: > The nicest thing would be that the semantic docs become part of the > parse tree, which then (using standard introspection) can be used to > generate manual pages, natively into POD, roff, HTML, whatever. I like to call them: lexical comments. -- Groet, Ruud

Re: POD <-> Code entanglement

On 6/14/07, Thomas Wittek <[EMAIL PROTECTED]> wrote: It's a bit like HTML<->XML, where the former lacks most of the semantics and makes the information processing - not to speak about a consistent look over several documents - a lot harder. Actually, that's incorrect. HTML is a markup language

Re: POD <-> Code entanglement

{ ... } The backtick is rather cute and saves a lot of typing. It's like a comment (#), but ends up as *external* documentation. That's nice. > Semantics are very useful in documentation, why throw them away? Why not have both? With normal POD as suggested by Damian, you cou

Re: POD <-> Code entanglement

f a method. I love the power of CSS. > I could imagine a semantic documentation in Perl6, that could be > translated to XML/HTML+CSS or to POD(6) for formatting it. The nicest thing would be that the semantic docs become part of the parse tree, which then (using standard introspection) can

Re: POD <-> Code entanglement

Moritz Lenz: > =begin pod > > =head3 C > [..] > =end pod > > method from_string(Str $s){ > # implementation of that method here > } > > Since method signatures are very expressive in Perl 6, there should be a > way of accessing them in the POD witho

POD <-> Code entanglement (was: Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn)

t copied & pasted the signature of method to the pod: =begin pod =head3 C initialize the Sudoku from a string C<$s>, with a 0 denoting an empty cell and a number between 1 and 9 a clue. Note that there is currently no way to use this function for sizes bigger than 9x9 overall

Re: multi-line comments, C macros, & Pod abuse

I think this is not even a metaprogramming issue so much as a programming environment one. I mean, if your editor doesn't make it easy to stick a # at the beginning of a bunch of lines with one action, and likewise remove them later, you need to get a new editor. :) On 8/21/06, Joshua Hoblitt <[

Re: multi-line comments, C macros, & Pod abuse

On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote: > On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote: > > > Why would you care about introducing a new lexical scope? You would > > care about that if you used a variable you declared in the commented > > code in the code b

Re: multi-line comments, C macros, & Pod abuse

On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote: > >The important question here is this one: > > > > - when 'uncommented', is it a no-op? > > > >Which isn't true for #{}/{}, because {} introduces new lexical > >scope. > Why would you care about introducing a new lexical scope? You wou

Re: multi-line comments, C macros, & Pod abuse

On 8/20/06, Luke Palmer <[EMAIL PROTECTED]> wrote: Well, I think you are being too picky. [snip snarky sarcastic rant] Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded me of those rediculously long, whiny threads. Anyway, that was un-called-for. Luke

Re: multi-line comments, C macros, & Pod abuse

sted sub is invoked? > - will the optimizer spend time on this block? The important question here is this one: - when 'uncommented', is it a no-op? Which isn't true for #{}/{}, because {} introduces new lexical scope. It's still a pretty good idea, but it's not as

Re: multi-line comments, C macros, & Pod abuse

On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote: : On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: : > On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote: : > >You don't actually need a macro in that case: : > > : > >if 0 { q< : > >... : > >> } : > : > Wh

Re: multi-line comments, C macros, & Pod abuse

ime on this block? The important question here is this one: - when 'uncommented', is it a no-op? Which isn't true for #{}/{}, because {} introduces new lexical scope. It's still a pretty good idea, but it's not as good as the C preprocessor. if (0) has the same problem. P

Re: multi-line comments, C macros, & Pod abuse

On 8/20/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: This is exactly the type of construct that I had in mind. A couple of questions. Is code inside of a #{}: - parsed and required to be syntacticly correct? No. It's a comment. # followed by one or more open bracket characters creates a

Re: multi-line comments, C macros, & Pod abuse

On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: > On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote: > >You don't actually need a macro in that case: > > > >if 0 { q< > >... > >> } > > Which, of course, eliminates the original desire to have a > code-commenting constru

Re: multi-line comments, C macros, & Pod abuse

> "Stuart Cook" schreef: > > Larry Wall: > > >> if 0 { > >> ... > >> } > > > > The one disadvantage of that approach is that it will break if the > > "commented-out" code temporarily fails to compile. > > How frequent does that happen? All the time. I often comment out bits of code wh

Re: multi-line comments, C macros, & Pod abuse

"Stuart Cook" schreef: > Larry Wall: >> if 0 { >> ... >> } > > The one disadvantage of that approach is that it will break if the > "commented-out" code temporarily fails to compile. How frequent does that happen? And in that case s/if 0/\#/, as Luke mentioned. And if the compile fai

Re: multi-line comments, C macros, & Pod abuse

On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: > On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote: > >You don't actually need a macro in that case: > > > >if 0 { q< > >... > >> } > > Which, of course, eliminates the original desire to have a > code-commenting constru

Re: multi-line comments, C macros, & Pod abuse

On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote: You don't actually need a macro in that case: if 0 { q< ... > } Which, of course, eliminates the original desire to have a code-commenting construct where "you just change the 0 to a 1". After all, we already have #{}. Incide

Re: multi-line comments, C macros, & Pod abuse

Stuart Cook writes: > On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote: > >if 0 { > >... > >} > > The one disadvantage of that approach is that it will break if the > "commented-out" code temporarily fails to compile. If that's a > problem, though, you could always write your own macr

Re: multi-line comments, C macros, & Pod abuse

On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote: if 0 { ... } The one disadvantage of that approach is that it will break if the "commented-out" code temporarily fails to compile. If that's a problem, though, you could always write your own macro. Stuart Cook

Re: multi-line comments, C macros, & Pod abuse

On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote: : It occurred to me that other day that in our "in house" C code we : somewhat frequently use an idiom that's not easily translated into Perl : 5. Our rule is that if your commenting out more then 1 or 2 lines of : code that you wrap

multi-line comments, C macros, & Pod abuse

o 1 to re-enable the code. E.g. #if 1 (magic now happens)... #endif The best equivalent I've been able to come up with in Perl 5 is: =for off ... =cut & #=for off (magic now happens)... =cut Except that now this requires all sorts of weird voodoo to

Re: Linking Synopses to corresponding pod-files?

On 5/4/06, Juerd <[EMAIL PROTECTED]> wrote: Markus Laire skribis 2006-05-04 14:55 (+0300): > When reading Synopses, I sometimes notice some mistakes or typos, > which I'd like to submit a patch for, but it's not easy to do so as I > don't know where to get the sour

Re: Linking Synopses to corresponding pod-files?

Markus Laire skribis 2006-05-04 14:55 (+0300): > When reading Synopses, I sometimes notice some mistakes or typos, > which I'd like to submit a patch for, but it's not easy to do so as I > don't know where to get the source. Have you tried s/html/pod/? :) Juerd -

Linking Synopses to corresponding pod-files?

When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Could each Synopsis include a link to the corresponding .pod (if it's available in Internet, that is)

Re: S05.pod

In a message dated Mon, 17 Apr 2006, Sean Sieger writes: from There are no C or C modifiers (changes to the meta-characters replace them - see below). to There are no C or C modifiers (change to the meta-characters that replace them - see below). I don't think so There are no meta-char

S05.pod

from There are no C or C modifiers (changes to the meta-characters replace them - see below). to There are no C or C modifiers (change to the meta-characters that replace them - see below).

Re: [PATCH] Re: apo/A06.pod: spelling error(s)?

On Wed, Apr 20, 2005 at 08:13:20PM +0200, Steven Philip Schubiger wrote: > On 20 Apr, Luke Palmer wrote: > : Steven Philip Schubiger writes: > :> In > :> macro circumfix:(*...*) () is parsed(/.*?/ { "" } > :> > :> is the second enclosing part of the "parsed" parentheses omitted > :> by intenti

[PATCH] Re: apo/A06.pod: spelling error(s)?

tch. : : Fixed. Thanks. : : Luke You missed some. Steven --- perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:03:19 2005 +++ perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:05:32 2005 @@ -3004,12 +3004,12 @@ interpolated with a special C< ... > marker, which is considered part of the nam

Re: apo/A06.pod: spelling error(s)?

Steven Philip Schubiger writes: > In > macro circumfix:(*...*) () is parsed(/.*?/ { "" } > > is the second enclosing part of the "parsed" parentheses omitted > by intention? If not, I'd volunteer to provide a patch. Fixed. Thanks. Luke

apo/A06.pod: spelling error(s)?

In macro circumfix:(*...*) () is parsed(/.*?/ { "" } is the second enclosing part of the "parsed" parentheses omitted by intention? If not, I'd volunteer to provide a patch. Steven

Re: [PATCH] apo/A06.pod: spelling error(s)

On Sun, Apr 17, 2005 at 02:52:27PM +0200, Steven Philip Schubiger wrote: > A spelling mistake and a word, that supposedly has been forgotten. > > Steven Applied, thanks! Pm > --- apo/A06.pod Sun Apr 17 14:34:16 2005 > +++ apo/A06.pod Sun Apr 1

[PATCH] apo/A06.pod: spelling error(s)

A spelling mistake and a word, that supposedly has been forgotten. Steven --- apo/A06.pod Sun Apr 17 14:34:16 2005 +++ apo/A06.pod Sun Apr 17 14:42:37 2005 @@ -2021,7 +2021,7 @@ All blocks are considered closures in Perl 6, even the blocks that declare modules or classes

Re: [PATCH] apo/A05.pod: spelling error

On Thu, Apr 07, 2005 at 11:13:42PM +0200, Steven Schubiger wrote: > Attached is a patch that fixes a minor spelling error > in apocalypse 5. Applied, thanks! Pm

[PATCH] apo/A05.pod: spelling error

Attached is a patch that fixes a minor spelling error in apocalypse 5. Steven --- A05.pod.origThu Apr 7 22:59:16 2005 +++ A05.pod Thu Apr 7 22:59:56 2005 @@ -2179,7 +2179,7 @@ tree of objects. Matching against such boundaries or metadata would not be possible -unless

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

Damian Conway wrote: [No, I'm not back; I'm just passing by. But I feel that I need to comment on this whole issue] Thanks! This message has lots of useful information that I would have otherwise probably missed. It seems that the basic premise of the POD document object model gels

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

Oh, and I forgot to mention: In the contents of any block, any line with '=' in column zero and a whitespace character in column 1, has those two characters removed when the contents are extracted. So you can write: =begin data POSSIBLE_POD_DIRECTIVES = = =doh -- Oh, dear! Oh frikking dear! = =r

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

ht be well suited to Perl 6. At least...as a second allowable syntax. And, in my view, Kwid kicks Markdown's butt in terms of its suitability for Perl documentation. POD itself is brilliant and we should certainly not abandon it, but it's critical to remember that POD is just an *inter

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

On Thu, Mar 17, 2005 at 05:04:53PM -0500, Aaron Sherman wrote: > On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: > > > The interesting thing to me is that all 3 syntaxes map over the same > > data model and thus are easily interchangable. > > It is, however, contrary

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz <[EMAIL PROTECTED]> wrote: Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: >By the way, I think I've seen a few people suggest some sort of >syntax-switching mechanism for "Pod6". The day people have t

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

Aaron Sherman wrote: Sam "mugwump" Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or "AST" that these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant mark

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

On Thu, 2005-03-17 at 17:07, Brent 'Dax' Royal-Gordon wrote: > Aaron Sherman <[EMAIL PROTECTED]> wrote: > > and the hacks in > > pod syntax (e.g. C<< < >>) to get around this are glaring anti- > > huffmanisms. > > Whatever bracketing ch

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

Aaron Sherman <[EMAIL PROTECTED]> wrote: > > Specifically, I like the use of angle brackets in Pod. Angle brackets > > are simple, distinctive shapes; they remain wide in variable-width > > This is aesthetic preference. I could cite the reasons that I have an > aesthet

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

proper. If any of the above was news to you, then I suggest you take another look at why POD (and more generally, any abstract markup language) exists. If any of the above were NOT true, it would be contrary to the entire point of an abstract, layout-neutral markup language. It is, however, con

  1   2   3   >