In principle this is a good idea - we already have linking schemes to Perl documentation and CPAN, so we should also provide convenient ways to link to the ever changing Perl6 documentation. As [bareword] links are traditionally on-site links, I propose a different scheme, similar to [doc://] and [cpan://]:
- [syn://S(\d\d)(?::(\d+))?] could link to "http://perlcabal.org/syn/S$1.html#$2"
- [syn://S(\d\d)(?:/(\w+))?] could link to "http://perlcabal.org/syn/S$1.html#$2"
This is a bit off the cuff, but as both kinds of links are to Perl6 synopses, using the pseudo-protocol syn:// makes sense to me - maybe a different name like perl6syn:// makes more sense (yet makes it more verbose)...
What I wouldn't like is making the traditionally local links [\w+] going off-site, even for a class of special cases.
Update: I wrote handlelinks settings - (patch), which implements this scheme, but have neither tested nor applied that patch yet.
| [reply]
[d/l]
[select] |
doc6://? syn6://? 6doc://? Not as verbose yet still more indicative that you're getting Perl 6 documentation.
(After sitting and looking at them a minute or two I like the last most out of my three. But that's just MHO, of course :)
Afterthought: Of course given that it's going to something different and has a bit different syntax than the normal doc:// perhaps it's a good thing that the prefix is more different from that.
| [reply] |
I don't like any of them. I'd expect doc6:// (or 6doc://) to go to perldoc for Perl 6 (and I hope we won't need that, being able to just use Perl documentation because I hope that site will host both Perl5 and Perl6 documentation). I don't see the Perl 6 design documents as being equivalent to the Perl 5 manuals. I expect there to be Perl 6 manuals written at some point that don't focus on the design nor the difference between Perl 5 and Perl6 but just thorough document how to use Perl 6. That documentation will likely be based on the exeg (or perhaps not since they seem to be getting quite out-of-date), but they'll be different than any of the AES.
Using syn for all of apoc, synop, and exeg doesn't work for me either. If apoc, synop, and exeg weren't all so hard to spell and so hard to consistently abbreviate (as in people natually abbreviating them the same, which I don't see happening), then they'd be good choices for what to put in front of ://, but I don't think syn6:// works, in particular.
Corion's patch used syn:// for the following code:
if (! $escsuffix) {
("http://perlcabal.org/syn/", "Perl 6 Synopses")
} elsif ($escsuffix =~ m!^(S\d\d)(?:[:/](.*))$!) {
my ($page,$esc) = $2;
my $display = $suffix;
if ($suffix =~ m!^S\d\d([:/].*)$!) {
$display = $2;
};
("http://perlcabal.org/syn/S$page.html#$esc", "$page$display")
} else {
# error in spec, just pass it through with a prefix
"http://perlcabal.org/syn/$escsuffix"
};
which suffers from ignoring the apocs and exegs (perhaps those are currently less important but as the design solidifies again, they will likely become more important again).
And I think we need more research on how anchors work. For example, I think the POD parsers use some rule for turning lots of characters into underscores and we need to encode those same rules here.
| [reply]
[d/l] |
| [reply]
[d/l] |
Anyone working on this proposal needs to (re)read Perl 6 links first.1
The crux of the problem is what to put before ://. It is too bad that no appealing term has been coined (as far as I know) for the apoc, exeg, and synop triad. Something like "perl 6 bible", for example.
Although aes:// isn't very appealing as a mnemonic, I am starting to think we should use it. If we come up with an appealing alternative, then we should make that an alias for aes://.
1 It also serves as a good example of how to interact with gods such that nothing gets done.
| [reply] |