With the help of the Most Enlightened (thanks!) (and some research on my part), we now have new link tags available. Each searches a certain site for the value you provide and returns a list of hits:
[jargon://] searches the Jargon file hosted at the University of Amsterdam.
Examples: meme, "You're a Nazi!", "Don't do this."
(I chose this one because I can get to it through the web filtering software I have to deal with at work. Folks have posted links to other copies of the Jargon file, but many of those are blocked by that software.)
[kobe://] is an alternate for the [cpan://] tag; it searches the CPAN mirror at the University of Winnipeg for a given module or distribution. It's named after the maintainer of that site.
Examples: sendmail, lwp, Here's an easy way to install CPAN modules.
(It was chosen because I've found [cpan://] to be slow from time to time and use this one more often than not.)
[perldoc://] searches perldoc. The idea here is to provide a way of linking to current Perl documentation.
Examples: unlink, A Cookbook, "How do I send email from Perl?"
(This was based on a recent conversation.)
Again, these tags only provide the search results, so they're not as specific as linking directly to a given document. However, I hope they'll prove at least as useful as other tags that've been added over time.
Update: Owing to popular demand, we've added [pad://] as a shortcut to a user's scratch pad.
Please note that this behaves slightly differently if you do not enter a title parameter. If, for example, you type [pad://footpad], the result is "footpad's scratchpad".
If you enter a title, it behaves like the other link tags, e.g. "Check this out."
Update #2: Thanks to the tireless (and a little help from me), the documentation has been updated. (P.S. Thanks for the help, tye.)
Cheers!
--f
Re: New Link Tags
by suaveant (Parson) on Oct 18, 2001 at 18:11 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: New Link Tags
by stefan k (Curate) on Oct 18, 2001 at 19:54 UTC
|
Well,
why not extending this mechanism to a more customizable and
user definable way of linking?
I can imagine creating my own tags in the user settings, where I could be asked for a name for the tag and a link, with a placeholder (e.g. %s) in the appropriate position, that resolves the tag-link. Uhm, I don't know if you can understand me (I only hardly do), but probably an example will make that clear.
Say you got your own perl module review site located at
http://www.myperlmodulereview.org, there you got the search script located in /cgi-bin/search.pl which takes the arguments in this way: module=HTML::Parser&order-by=date. Thus a correct URL would look like:
http://www.myperlmodulereview.org/cgi-bin/search.pl?module=CGI&order-b
+y=date
Now you could define your own tag simply by assigning it a name (say "myreview") and the resolver which consists of the above URL except that 'CGI' would be replaced with %s, so that the dynamic content will be placed there:
Tag: myreview
Resolves-to: http://www.myperlmodulereview.org/cgi-bin/search.pl?phras
+e=%s&order-by=date
Then:
[myreview://CGI]
would then create the above link automagically.
Of course this would be private to each user but maybe one could then even implement a kind of importing mechanism, so that if footpad did another really useful tag I could adress it by using [footpad::newtag://linkto] or even globally import all of footpad's tags into my own 'namespace'.
... uhm .. do you get me?
Regards... |
Stefan
|
you begin bashing the string with a +42 regexp of confusion
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: New Link Tags
by VSarkiss (Monsignor) on Oct 19, 2001 at 02:25 UTC
|
| [reply] [Watch: Dir/Any] |
Re: New Link Tags
by tommyw (Hermit) on Oct 18, 2001 at 18:22 UTC
|
Sorry for attacking what's obviously an improvement. Obviously the requirement for having the extra destination exists, and this does solve it. But I can't help thinking there's a cleaner solution.
Regarding the kobe:// tag: this means the article's author gets to pick which site the reader goes to. Or they include two tags, and the reader picks one. Either mechanism has its problems.
Instead, would it be possible to store the preferred site in user settings and have the server dynamically expand the cpan:// tag to point to the readers chosen site?
I've no idea whether this is possible, or how hard it would be...
| [reply] [Watch: Dir/Any] |
|
If you think it's a good idea, then what about changing [google://] to point to your search engine of choice?
It would be a lot more work - extending the database, providing a mechanism for people to choose their search engine through user settings, etc
But far more importantly, it is pointless - why provide a link to something, if the reader might end up somewhere where the content is different? "CPAN" ne "KOBE". While Randy Kobe's site mirrors the modules and metadata, it doesn't mirror the site content - it is presented in a different way. Perhaps if I use the [cpan://] link, I WANT you to go to CPAN, not some other site.
On the other hand, there are a lot of tags now to remember, and these will grow, but it seems meaningless to me to have a link in a Perlmonks post that could lead to a number of different sites.
Simon Flack ($code or die)
$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
=~y'_"' ';eval"die";print $_,lc substr$@,0,3;
| [reply] [Watch: Dir/Any] |
|
Ah, based on the description given above, I thought kobe:// was simply a mirror of cpan://, to be used when communications to cpan itself were decided to be too slow.
Ok, in that case, I retract the particular suggestion (although will happily leave it around if anybody does want to implement a similar option
| [reply] [Watch: Dir/Any] |
Re: New Link Tags
by Masem (Monsignor) on Oct 18, 2001 at 22:04 UTC
|
How easy is it to extend this to other link tags?
One idea I just had was that you could create a user:// tag that would return the closest match in the user list to it's argument; while this causally would help to locate users faster, it would help when a user has a name that is the same as node title. However, I believe that the user name list is searched first in the generate bracket tag, so this isn't a big problem.
However, I can see using user:// along with other tags, like sopw://, med://, or dis:// that would be like Super Search in limiting the search to only those areas. Since a limited search *ought* to be faster than a search of all nodes on the backend, this can help improve the speed when these are used. Eg: "Please take a look at {med://Death to Dot Star}" should be faster to parse for presentation than "{Death to Dot Star}" alone (replace those curlies with square brackets, of course).
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
| [reply] [Watch: Dir/Any] |
Re: New Link Tags
by echo (Pilgrim) on Oct 18, 2001 at 22:17 UTC
|
[kobe://] is an alternate for the CPAN tag; it searches the CPAN mirror at the University of Winnipeg for a given module or distribution. It's named after the maintainer of that site.
But the guy's name is Kobes.
| [reply] [Watch: Dir/Any] |
|
|