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
In reply to Re^2: Name clashes in lookup by title (plans)
by tye
in thread Name clashes in lookup by title
by bart
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |