Re: Name clashes in lookup by title

I understand the aggrevation. This is a particularly annoying problem when people pick usernames that match parts of the Perl lexicon, so that if you think you're highlighting "sort" with [sort] you're really linking to a user.

It's an ongoing problem bound to get worse. As it does, the search button at the top of the page is likely to become less useful over time, and Super Search will become more of a vital component to finding anything around here.

Do realize that the Search button at the top of every page is only searching titles. That means that if you search for "Newbie question" or "Regex Question" there will be thousands of hits, limited to 50, and probably sorted by node id. So in many ways, Super Search is already a better option.

The very problem you've mentioned (title clashes) prompted the SiteDocClan to adopt a policy "way back when" of always linking within site documentation by node id instead of by node title.

When presenting links in your nodes, the safest links are and will always be specific links, rather than best guess links. Try to favor the following types:

[id://........]        (Node ID)
[cpan://......]        (CPAN search)
[perldoc://...]        (perldoc.com search)
[doc://.......]        (link to actual function POD or actual
                       POD documents)
[pad://.......]
.....
[download]

There are others, but you get the idea; it's better to be specific as to what you're trying to link to rather than to rely on the "lazy" [ ..... ] links.

For the record, you can actually search for specific nodes by id, just by typing the node ID into the search box.

Dave

Comment on Re: Name clashes in lookup by title Select or Download Code

Replies are listed 'Best First'.
Re^2: Name clashes in lookup by title (plans) by tye (Sage) on May 06, 2004 at 21:56 UTC
This is a particularly annoying problem when people pick usernames that match parts of the Perl lexicon, so that if you think you're highlighting "sort" with sort you're really linking to a user. I don't think so. Where does grep (`[grep]`) take you? It doesn't take you to grep (`[id://133383]`, a user) but to perlfunc:grep. Hence the need for `[user://grep]` which we'll have one day RSN. The "Search" at the top needs to be renamed "Find" as it isn't very good at searching, only at finding things that you already suspect are there and that you know exactly or nearly exactly how to get to them. And we shouldn't have (many nor important) nodes with titles consisting of only digits (for example, it is no longer possible to register a username consisting of only digits) but searching by node_id should be fast. So at some point, node=1234 will be directly translated to node_id=1234 (because only digits are given) instead of the current behavior of first looking for matching titles and then falling back to looking up the node ID. So, although a link like 65535 (`[65535]`) currently takes you to an inactive user's home node, in the future it will take you to Re: Submit Button (node ID 65535). Before that happens, you will also be given the ability to link via `[title://65535]` if you really wanted to find title(s) containing numbers. Some of the DWIM in "simple search" needs to go away because it is simply too inefficient. Currently, if you give it 9 words, it will try to find nodes with titles that contain all 9 of those words. If there are none, then it will find nodes having titles that each contain 8 of the 9 words, then try 7 of 9, etc. It does this rather efficiently (it doesn't take 9 passes over the set of node titles; just a single pass is done, perhaps in several steps), but not nearly as efficiently as Super Search's simple method of just requiring that matches contain all 9 words (or else no matches are found). Super Search also needs to support 'simple search's trick of adding a space to the front and back of titles so you could search for titles containing " foo " and not find titles containing "food" but still find titles where the "foo" word is either the first or last word in the title (though it won't find ":foo:", simply because SQL doesn't provide an efficient way to support that w/o reindexing on "words" which we defer to google because they do it better than we could). Update: Oh, and as to the original question, "newest first" would be better. Since Super Search has proven that MySQL can handle it despite the bugs that can make such ordering very inefficient if you aren't careful, I'll add that to my plans. And I may make trying to search but having no exact matches just take you straight to super search with stuff prepopulated... - tye	[reply] [d/l] [select]
Re(2): Name clashes in lookup by title by bart (Canon) on May 06, 2004 at 15:30 UTC
For the record, you can actually search for specific nodes by id, just by typing the node ID into the search box. Just as a counter example, I'd like you to look up 1. It returns 2 results, but not one with node_id 1. But in general, you are correct. Except I don't think that searching for nodes by node_id is all that useful. p.s. Nice post.	[reply]
Re: Re(2): Name clashes in lookup by title by davido (Cardinal) on May 06, 2004 at 15:38 UTC
You're correct, putting a node ID in the search box subjects it to name clashes as well. Good thing that very few nodes are named 31523. ...and exactly one carrys that ID. There will be times when you simply can't search even by ID. You will always be able to link by ID though. (Just wanted to clarify). You may also always get to a particular node ID by hand-crafting the URL. This is not terribly user-friendly, but works fine: `http://www.perlmonks.org/index.pl?node_id=xxxx (where xxx is the actual node id)` [download] Careful. Dave	[reply] [d/l]
Re: Re: Re(2): Name clashes in lookup by title by demerphq (Chancellor) on May 07, 2004 at 13:58 UTC
I think its better to do: `<a href="?node_id=272750">A direct link to Sporty's Home Node</a>` [download] A direct link to Sporty's Home Node As that way you wont appear to log anyone out, and if the gods are ever mad enough to rename index.pl it will still work. :-) BTW: Sporty was chosen because he happened to be in the CB when I wrote this and as such it was easy to get his node_id. I'm not picking on the Java Freak or anything here. :-) --- demerphq _{First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi}	[reply] [d/l] [select]