So no reactions about search changes suggestions? It would be good to fix 3. and 4. at least, if 1. is too difficult. (5. is for further discussion)
S. From: Steve Stefanovich Sent: Wednesday, 11 March 2015 14:18 To: Fossil SCM user's discussion Subject: Displaying new search results The new search functionality is awesome and quick - thanks, drh. It is a huge step forward to make Fossil usable for non-programmers, i.e. GUI-only users (managers, testers, documentation writers). It's not quite there yet, IMHO. drh - and other valued contributors - what do you think about fixing or improving the following: (Fossil 1.31 Win binary, /search page) 1. How about displaying the search results in table with sortable columns, similar to /brlist and ticket reports? Suggested columns would be mtime, type (doc/check-in/ticket etc.), creator username, filename (wiki title, ticket subject) and search hit snippet. (Add commit hash if 5. below is implemented). This would cater for much more common use case where you can't remember - or don't know - the 'unique enough' search keyword(s) to get relevant hits, but you do know a person who updated the content or roughly when it was done. By sorting on columns you can quickly zoom in on what's relevant even if there are lots of search hits due to common keyword. 2. Include search on full path filenames too. Sometimes I'm interested in specific file, but remember only roughly what it is called or where is it located. This would be even more useful if search can traverse commits and show deleted/renamed versions as well; sometimes I know there was a file with 'foo' in its name that I can't find anymore because someone has deleted or renamed it. 3. If the file extension is not wiki, the hyperlink to go to contains the first line of the file instead of the filename. So if I enable search of the source code by adding, say *.c in search admin page, instead of the full path filenames being displayed, I get the first line of the comment or copyright notice. It should be full path filename. 4. The search result hyperlinks should have the ?mimetype=text/plain suffix always set, otherwise if they are not wikis, then they get served as downloads. It is more conceivable that I'd want to look at the file content instead. If I need to download, I can always quickly delete the suffix and get it. 5. Search over past commits. This probably deserves a separate discussion on its own. I hope that if it can be invoked with params that limit the keyword search on file extension, tag, date or number of hits, it can work fast enough even as full text search. The challenge would be how to display the context for different use cases. Thanks for Fossil, it is really useful software. Cheers, Steve
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
