Mailing List Archive

PSC #117 2023-09-21
Two of us again, here's the summary of our meeting:

* While implementing PPC 0013, it turned out it was vague in some
places, so further discussions and refinements to the PPC document
are needed
* POD extensions - do we keep stealing features from Markdown (like
tables, images, language markers)? Do we switch to Markdown?
Neither are easy.
* We’ve disabled the Wiki and enabled Issues on the PPCs repository,
to better separate discussions on the form and substance of PPCs
* PPC 0022 will soon be merged, and moved to “Exploratory” status

--
Philippe Bruhat (BooK)

Only a fool follows orders without knowing why.
(Moral from Groo The Wanderer #86 (Epic))
Re: PSC #117 2023-09-21 [ In reply to ]
I'm curious how "switch to Markdown" would even work?

I love Markdown, it's used in a ton of places. I'd love to see Perl
support it... but I have no idea how an implementation would even look.

On 9/23/2023 7:59 AM, Philippe Bruhat (BooK) wrote:
> Two of us again, here's the summary of our meeting:
>
> * While implementing PPC 0013, it turned out it was vague in some
> places, so further discussions and refinements to the PPC document
> are needed
> * POD extensions - do we keep stealing features from Markdown (like
> tables, images, language markers)? Do we switch to Markdown?
> Neither are easy.
> * We’ve disabled the Wiki and enabled Issues on the PPCs repository,
> to better separate discussions on the form and substance of PPCs
> * PPC 0022 will soon be merged, and moved to “Exploratory” status
>
Re: PSC #117 2023-09-21 [ In reply to ]
On Sat, 23 Sep 2023 16:59:46 +0200
"Philippe Bruhat (BooK)" <book@cpan.org> wrote:

> * POD extensions - do we keep stealing features from Markdown (like
> tables, images, language markers)? Do we switch to Markdown?
> Neither are easy.

Transition to a different markup language would take many years and I'm
not sure it would actually gain us anything. And fragmentation is never
a good thing.
Re: PSC #117 2023-09-21 [ In reply to ]
On Sat, 23 Sep 2023 10:02:18 -0700
Scott Baker <scott@perturb.org> wrote:

> I'm curious how "switch to Markdown" would even work?

It prettymuch wouldn't. There's too many moving parts everywhere.

But we discussed it anyway just to come to that conclusion, and be
prepared to explain it to the folks that inevitably will say "drop POD
in favour of Markdown rather than keep stealing its features".

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: PSC #117 2023-09-21 [ In reply to ]
For what I want, I already switched to Markdown wholesale everywhere I had
previously been using POD as a general documentation format.

I found them reasonably comparable but that Markdown was a lot less verbose.
Certain things Markdown seemed to fall short of POD such as the cleanliness of
navigation links. And I'm speaking of standard Markdown that works everywhere
not extensions that only work in some places.

I'm currently naive as to what if any support there is in Perl or its toolchain
for Markdown now, but I feel it would be valuable if Markdown was supported by
both or especially the toolchain as an official alternative to POD.

The simpler scenario is that Markdown files could be supported in the same way
as standalone POD-only .pod files are supported now, and the toolchain would
handle either in the same way.

A more complicated scenario would be somehow supporting embedding Markdown
inside Perl source files .pl, .pm etc if that is useful. This would be required
for it to be an eventual full replacement for POD everywhere if one wanted to do
that.

However, while embedding POD in Perl source files is a very useful feature in
principle and I can see benefits of it, particularly for interleaving docs with
what routines etc they document, I found in practice that when I wrote POD it
actually worked best for me to have it in wholly separate files.

See https://metacpan.org/dist/Set-Relation for an example of my preferred POD
practice, where Perl source files don't have any POD in them, the POD is separate.

A key reason I find separate files are better is that the optimal structure for
documentation is not the same order as the optimal structure for code, and
separate files means each can be optimized for its purpose without being forced
to align with each other because routine docs must be beside the routines they
describe and so on.

And so, at least for people that follow my recommended practice of docs being in
separate files, the much simpler support for standalone Markdown files without
embedding it in Perl files would be sufficient.

-- Darren Duncan

On 2023-09-23 1:11 p.m., Paul "LeoNerd" Evans wrote:
> On Sat, 23 Sep 2023 10:02:18 -0700
> Scott Baker <scott@perturb.org> wrote:
>
>> I'm curious how "switch to Markdown" would even work?
>
> It prettymuch wouldn't. There's too many moving parts everywhere.
>
> But we discussed it anyway just to come to that conclusion, and be
> prepared to explain it to the folks that inevitably will say "drop POD
> in favour of Markdown rather than keep stealing its features".
>
Re: PSC #117 2023-09-21 [ In reply to ]
On 9/23/23 14:34, Tomasz Konojacki wrote:
> On Sat, 23 Sep 2023 16:59:46 +0200
> "Philippe Bruhat (BooK)" <book@cpan.org> wrote:
>
>> * POD extensions - do we keep stealing features from Markdown (like
>> tables, images, language markers)? Do we switch to Markdown?
>> Neither are easy.
> Transition to a different markup language would take many years and I'm
> not sure it would actually gain us anything. And fragmentation is never
> a good thing.

Actually, that part might not be hard at all.  If there was a new pod
directive "=md" that parses everything until the next POD directive as
Markdown, then as soon as Pod::Simple supports it, everyone can use it
just by installing the latest Pod::Simple.  In fact, some of this work
is already done by Markdown::Pod, and Markdent (but would need
reimplemented to not use Moose).  There would be a little more effort to
tell Metacpan to look for standalone .md files containing documentation.

The bigger problems I see would be that 1) Markdown is defined in terms
of HTML, and 2) nobody wants "standard" markdown.

The first is a problem because most existing markdown parsers pass
through HTML elements, giving users the ability to supply their own HTML
any time Markdown isn't enough.  That won't work for generating Troff
output for man pages or console perldoc.  So, POD's markdown could
either omit that part, or be paired with some kind of HTML-to-Troff
converter if one exists.

The second problem is that the original daring-fireball version of
Markdown (which was defined in Perl, even!) isn't probably what the
average person would want for Markdown.  Case in point, you can't "steal
features like tables from markdown" because original markdown doesn't
have tables.  There would need to be a bikeshed war over which markdown
features got included and which implementation's semantics to use.  (I'd
vote GitHub's)  Also Markdown isn't very future-proof, because the
slightest changes to parsing rules could break interpretation of old
docs.  Though, that could be handed with a version in the pod directive,
like "=md2"  "=md3" and so on if it came to that.

Anyway, I would also love it if I could use the shorter Markdown
notations in my Perl modules.
Re: PSC #117 2023-09-21 [ In reply to ]
On Sun, 24 Sep 2023 16:16:46 -0400
Michael Conrad <mike@nrdvana.net> wrote:

> Actually, that part might not be hard at all.  If there was a new pod
> directive "=md" that parses everything until the next POD directive
> as Markdown

...

> The bigger problems I see would be that 1) Markdown is defined in
> terms of HTML, and 2) nobody wants "standard" markdown.

...

You've basically made exactly the same points we made ourselves, and
concluded it's far more complex than it first appears...

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: PSC #117 2023-09-21 [ In reply to ]
> On Sep 24, 2023, at 13:16, Michael Conrad <mike@nrdvana.net> wrote:
>
> The second problem is that the original daring-fireball version of Markdown (which was defined in Perl, even!) isn't probably what the average person would want for Markdown. Case in point, you can't "steal features like tables from markdown" because original markdown doesn't have tables.

The original DF Markdown _did_ support tables, because the original DF Markdown definitionally allows HTML to be included inline in a Markdown document — see https://daringfireball.net/projects/markdown/syntax#html, which spells this out.

I suspect this makes it a bigger mess to add to POD rather than a smaller one.

j.

--
John SJ Anderson // john@genehack.org
Re: PSC #117 2023-09-21 [ In reply to ]
On Mon, 25 Sept 2023 at 10:39, John SJ Anderson <john@genehack.org> wrote:

> On Sep 24, 2023, at 13:16, Michael Conrad <mike@nrdvana.net> wrote:
>
> The second problem is that the original daring-fireball version of
> Markdown (which was defined in Perl, even!) isn't probably what the average
> person would want for Markdown. Case in point, you can't "steal features
> like tables from markdown" because original markdown doesn't have tables.
>
>
> The original DF Markdown _did_ support tables, because the original DF
> Markdown definitionally allows HTML to be included inline in a Markdown
> document — see https://daringfireball.net/projects/markdown/syntax#html,
> which spells this out.
>
> I suspect this makes it a bigger mess to add to POD rather than a smaller
> one.
>

The original POD parsers also supported tables. It just never made it into
the POD definition itself. I forget the syntax however, but i do remember
making use of it back in the 5.6/5.8 period, and hacking on the code
involved in one of the POD converters, pod2html I think. I think we lost it
when POD was standardized and we removed some of the hand rolled
converters.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: PSC #117 2023-09-21 [ In reply to ]
I don't like Markdown a lot. Org mode FTW!

I'm sorry for a very raw comparison but switching POD to Markdown sounds
like switching Perl to Python to me.

I also wish Ricardo wrote CODE_OF_CONDUCT.md and SECURITY.md in POD rather
than Markdown since GitHub supports rendering it as well (but unfortunately
not much people care for such "minor violations").

On Sat, Sep 23, 2023, 6:44 PM Philippe Bruhat (BooK) <book@cpan.org> wrote:

> Two of us again, here's the summary of our meeting:
>
> * While implementing PPC 0013, it turned out it was vague in some
> places, so further discussions and refinements to the PPC document
> are needed
> * POD extensions - do we keep stealing features from Markdown (like
> tables, images, language markers)? Do we switch to Markdown?
> Neither are easy.
> * We’ve disabled the Wiki and enabled Issues on the PPCs repository,
> to better separate discussions on the form and substance of PPCs
> * PPC 0022 will soon be merged, and moved to “Exploratory” status
>
> --
> Philippe Bruhat (BooK)
>
> Only a fool follows orders without knowing why.
> (Moral from Groo The Wanderer #86
> (Epic))
>