One of our esteemed monks yesterday proposed to let the cpan:// shortcut type (or "pseudoscheme") have meaningful behavior when written with no parameters ([cpan://]). Seemed reasonable enough, but I don't feel that cpan:// should be special in this regard; so I'm proposing that all shortcut types be similarly extended — or at least those for which some such reasonable behavior can be identified. Specifically, I propose that the following PerlMonks pseudoschemes render as the corresponding link in the parameterless case:

acronymAcronym Finder
apcPerl Repository Browser
c2Wiki Wiki Web
cpanCPAN
dictDICT.org
distCPAN
docPerl documentation
e2Everything
googleGoogle
imdbIMDB
isbnISBN
jargonThe Jargon File
kobeskobesearch
ljLiveJournal
modCPAN
perldocPerl documentation
wbWikibooks
wpWikipedia
wqWikiquote
wsWikisource

Note that the specific link texts shown above are merely the default; per the usual operation of shortcuts, explicit link text, if given, overrides the default.

Pseudoschemes not listed above either:

  1. are special in the parameterless case (e.g. localtime, pad)
  2. don't have obvious useful semantics in the parameterless case (e.g. http, id)
  3. are aliases of pseudoschemes listed (e.g. docs, kobe)

We're building the house of the future together.

Replies are listed 'Best First'.
Let shortcut types have useful behavior in the parameterless case - Patch and Test Cases
by jdporter (Paladin) on Aug 16, 2006 at 15:58 UTC
[reply]
Re: Let shortcut types have useful behavior in the parameterless case
by demerphq (Chancellor) on Aug 15, 2006 at 16:00 UTC

    apc:// has had a no-target default since it was created.

    And I agree with tye that any handler that doesnt have a sane no-target possibility should foward to the appropriate documentation page.

    ---
    $world=~s/war/peace/g

[reply]
      any handler that doesnt have a sane no-target possibility should foward to the appropriate documentation page

      That's a reasonable thing to do, but to my mind a better approach would be to let [foo://] DWIM from the writer's POV. IOW, if I want to link to the Perl Changes Browser, I write [apc://] If I want to link to the Wiki Wiki Web, I write [c2://]. If I want to link to the Perl docs, I write [doc://]. If I want to link to Wikipedia, I write [wp://]. And so on. Rather than assuming the author made an error.

      There's precedent for both approaches ([id://] vs. [apc://]). However, given that [id://] doesn't have any other useful default semantics, I'm not convinced that this is the precedent to follow. I'd rather follow the [apc://] precedent.

      We're building the house of the future together.
[reply]
[d/l]
[select]
        I think you misread. demerphq specified the handlers without "a sane no-target possibility" (e.g. the handlers for "http", "id" and similar) should link to docs on how to use them, not all of handlers.
[reply]
Re: Let shortcut types have useful behavior in the parameterless case
by ikegami (Patriarch) on Aug 15, 2006 at 16:56 UTC
    [http://] should go to a locally hosted copy of this. :)
[reply]
[d/l]
Re: Let shortcut types have useful behavior in the parameterless case
by tye (Sage) on Aug 15, 2006 at 15:00 UTC

    [id://] already goes to [id://], so [http://] could have a similar behavior.

    - tye        

[reply]
[d/l]
[select]
      Why not let [http://] point to http://? As everybody knows that's the best search engine in the whole wide world. ;-)

      /me ducks


      holli, /regexed monk/
[reply]
[d/l]
[select]

Back to Inner Scriptorium