Description: The searching functionality needs to be improved, specially in terms of the sorting of the output. I think this enhancement is related to the searching in the function wizard (Bug 158301). The proposed enhancements: - Special syntax like wildcards - Sorting of the results ( I suggest to use edit-distance algorithm to sort results according to the degree of similarity to search terms) - searching will be for name, arguments, and description (I suggest that we store keywords for all description, so searching will be more accurate. But I think this will be a hard job to do) What are your suggestions on this? Actual Results: --- Expected Results: --- Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 342670dc6b0fc5b93a40b9cf86b8cca67fac88a3 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Search engines taught us to use quotes, many tools work with wildcards... but I'm not sure if our average users expect any of these. Andreas suggested to sort the results and have names with the search term first and descriptions further down in the result list. Could be a simple and straight-forward solution. Sidebar and dialog should return the same results.
That sounds amazing. I think wildcards will not be of great use here. Giving names a higher priority over descriptions is a good idea, and we could also limit the results to a fixed number of functions so that irrelevant items do not appear at all. I will make the functionality work for both the sidebar and the dialog.
As for tdf#158301 (which is originated from the partial results of tdf#146781, at least ATM), the FW is not supposed to be a full-blown Help. The FW is an aid (for example, in order to reduce typos, or to ease introduction to Calc's functions). Although my opinion/preference goes against the request in tdf#146781, I respect(ed) that others might desire such search result (possibly more relevant for newbies or when you are not sure which specific function you need to select). The problem is that instead of adding an _option_ (as originally requested in tdf#146781), the resolution was to _impose_ a different searching result, on everyone. The new search result might perhaps in some case help some users, but there is no doubt that it negatively impacts most non-newbies (which should tend to be most users as time goes by, we all should hope). Unfortunately, you have to have a certain amount of experience with the FW (and Calc functions in general) in order to properly balance the need for some UI artifact against the alternative users' experience/interaction/expectations. The FW was already less efficient in comparison to similar features in other spreadsheet tools, and the imposition of the broader searching results in tdf#146781 was not an improvement, IMNSHO. The reluctance to add some form of _option_ (i.e. tdf#158301, and as originally requested in tdf#146781) moves me towards rejecting (FWIW) the result of tdf#146781, instead of kindly respecting others' requests and preferences. The result of the search in the FW should be always sorted alphabetically, because it impacts the use of keyboard shortcuts (e.g. arrow keys, home, end, PgDn, PgUp) within the dialog, and the natural expected visual search that users apply on the resulting list. Any change in this regard will further disrupt what is already a low-efficiency wizard (in comparison to other spreadsheet tools). Moreover, when typing a (possibly complete) name of a function in the search box (e.g. TEXT, or SUM), users expect a relatively reduced list of results (for example and in no particular order, just from memory and surely incomplete: TEXT, TEXTJOIN, ISTEXT, or SUM, DSUM, SUMIF, SUMIFS, SUMPRODUCT...), instead of a long lists that probably spans even longer than the height of the window, as is the result of almost every commonly-used term. The situation is worse with partial terms, although the expectation for a relatively-short list is not so prominent in that case. I can understand the reasoning to allow the search to include functions' descriptions – I have described situations in which I could take advantage of it – but I am not in favor of searching function's descriptions in every-and-all cases I would use the Search field in the FW. This is even more so when other related RFE were not implemented (e.g. the improvement of the Category field UX, tdf#155316, which is itself based/explained within several comments in tdf#104487). I could suggest other ways to change the UI of the FW in order to _optionally_ include functions' descriptions in the search results, but considering that a (minimal) check box was not welcome (tdf#158301), then there is no reason to bother with alternatives. In my case, the current partial result of tdf#146781 has negatively impacted my UX performance with the FW.
(In reply to ady from comment #3) > Although my opinion/preference goes against the request in tdf#146781, I > respect(ed) that others might desire such search result (possibly more > relevant for newbies or when you are not sure which specific function you > need to select). Glad to eventually have you among the reviewers. Let's start with the simple sorting and ponder over necessary improvements later.
AhmedHamed committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d05e0be5f4ab2bdb31d6cf14528a9a8ee5ac965c tdf#161543 Enhance the searching functionality in FD & FW It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.