Here are the current link-handling settings:

Much of the complexity has been factored out already but there are still a lot of improvements for the infrastructure of link handling that are desired and partially implemented. But even what we have now isn't a simple text substitution. Provide the start of an enhancement to get your customization and it might get into the queue with the other enhancements that have yet to be deployed. Sometimes such a kick-start is exactly what is needed.

If you are missing something, then implementing it will probably rectify that situation. I don't see the obvious right way to do something like what you have asked for that I'd consider flexible to the point of being worth implementing, but I haven't sat down and tried to design it (but it appears you haven't sat down and tried to design it in any detail either so I don't feel particularly lazy in comparison).

I think for the case of CPAN we could do:

my $escapedname=$query->escape($nodeloc); my $cpantitle= $title || $no
+deloc; my $mode=$VARS->{cpan_link_opts} || 'mode=module'; return qq[<
+a href="http://search.cpan.org/search?$mode&query=$escapedname">$cpan
+title</a>];
[download]

IMO there isnt so much need for a general solution, I dont think that many of the link types can really benefit from such tricks.

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

The idea behind this was to get pmdev out of the business of providing linker methods, especially the more esoteric ones. Maybe I link a lot to foobar.com in my posts, but no-one else does. Why should the Monastery provide a linker method just for me and my closest friends? But, why should I have to do what a computer can easily do for me? Enter custom linkers.

I'm thinking of a way that I can create a linker that I call foobar:// and it would look like:

foobar: <a href="www.foobar.com?baz=%L">Foobar: %T</a>

Now, you don't have to wade through yet another discussion of how PM does/doesn't provide a linker for foobar.com. I can just go make one. If you like it, add it to the default linkers.

---

• In general, if you think something isn't in Perl, try it out, because it usually is. :-)
• "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Note that & should be &amp; for URLs that are part of HTML. Most of the time, there is no practical difference. I just noticed that (and assume the problem pre-existed, since that problem exists all over PerlMonks) in the trimmed-down code, so FYI to anyone updating such code.

- tye        

There seem to be two main types of links, with a few oddballs.
• Internal links, which are id, localtime, node, pad, and pmdev. These are the guys calling htmlcode(). I don't think v0.1 allows the ability to customize to a link using this.
• External HTML links, listed below^*. These are the ones I think are excellent candidates for customizing. There seem to be 3 variables total that are used:
  • %L - location
  • %T - title (if given - defaults to %L)
  • %E - $query->escape(%L);
• The oddballs. From your list, the only one is isbn, which has the tr/// and default to a different title in it. I think we can leave customizing that would allow for this one out of v0.1 and add it later.

So, if I read everything right, the linking methods would look something like:

• cpan: <a href="http://search.cpan.org/search?mode=module&query=%E">%T</a>
• link: <a href="%L">%T</a>
• google: <a href="http://www.google.com/search?q=%E">%T</a>
You get the point. Even if you don't expose this, I think it would make the internal code a lot easier to manage.

^*External linking methods:

• cpan
• dict
• doc
• ftp
• google
• href
• http
• https
• jargon
• kobe
• kobes
• link
• lj
• lucky
• perldoc

---

• In general, if you think something isn't in Perl, try it out, because it usually is. :-)
• "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"