Description: The Writer's simple search UI (i.e. defaulting to a specific toolbar at the bottom of the window) is quite similar to the one provided in Firefox for example, but sadly is missing one of it's best feature : incremental searching (i.e. the search starts as soon as you type). Steps to Reproduce: Trigger a simple text search Actual Results: The search isn't performed until the field is validated or a next/previous occurrence search is triggered Expected Results: A next occurrence search is automatically performed as soon as a character is typed in the search field. A previous occurrence search is performed each time a character is erased in the search field. Reproducible: Always User Profile Reset: No Additional Info: The incremental search may be an optional search behavior enabled by a dedicated checkbox. ----- Version: 7.1.1.2 (x64) / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 8; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: CL
I confirm, that incremental search is not possible Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 21c602913d98ef46b49fc9b6f9071db92a1597c6 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL cc: Design-Team for further input and decision
If not too much overhead, of a new search algorithm, would be useful. +1
Let's set it to NEW as a valid enhancement
I'm puzzled by the summary. "Incremental search" refers to the method of showing possible terms while typing. When I enter "Libre" in the Google search bar it returns "libreoffice glade", "libreoffice", "libreoffice template", "libreelec" based on my previous searches and the knowledge Google has about me. The actual request is rather a type-ahead/find-as-you-type function. Meaning the search restarts/refines with every new letter. But in fact some applications use the term incremental for this, eg. https://www.gnu.org/software/emacs/manual/html_node/emacs/Incremental-Search.html Guess it's a challenge for developers to make the performance a good UX.
I want to document a negative aspect about this feature that am implementation should safeguard against, if LibreOffice contributors were to implement it. As of today, google-docs does not have a way of toggling-off incremental-search/find. So while incremental-search/find is very useful when it is quick, it can be frustrating if it makes the user wait on account of searching with the typing of every character. One and two-letter prefix-strings happen more often in a document than longer prefix-strings. Hence, when a user types only '1' or '2' characters, the incremental search/find races ahead and searches through the document finding all occurrences of the prefix typed so far, highlights them, and positions the cursor at the first-next-found-item. This can be **very slow** if the length of the document is very large i.e. has a a huge word count. Consider for example if one the user was searching for 'antelope', and typed the letters 'a' 'n' 't' 'e' in the search-dialog, it would give rise to searches 'a, 'an', 'ant', 'ante' with the typing of each character. Each additional character eliminates from the set of all found strings. On the other hand, pressing backspace increases the number of found strings. The amount of processing will freeze the browser tab. The problem is caused not by the textual-search through the in-memory text representation, but by the GUI rich-text-background-renderings which need to updated with any change in the search-field. Hence, the following user controls are also required for this feature - in preferences: boolean: checkbox: a way to toggle it off by default - in preferences: integer: number of characters: specify number of characters a user has to enter before incremental search kicks in. - in preferences: integer: time delay in seconds: specify number of seconds that should pass after the last typed-character before incremental search kicks in. - in find/replace dialog: boolean: checkbox: a way to toggle it on/off, which is initially set to the default as set in the preferences. Other smarts that need to be built in. - the search should detect when it is being cancelled and be quickly cancel-able, or highlight only as much of the text as could be found in the time provided. - parallelization: the incremental search should not make the user wait to type the next character Heiko Tietze in Comment 4, may have confused incremental-search with google's instant-search. Google-s instant-search is an AJAX technology based online query, which in addition to executing a partial search for updating the shown google results, it also provides in a drop-down box, suggested auto-completions. These suggestion are generated using probabilistic methods of predicting text based on existing text and past searches, and may even provide spelling correction. It does not have to be exhaustive, It only just has to be a short list of most likely completions to populate the drop-drown box. In contrast, simple editor based find-dialog incremental-search, does not have to do make predictions for autocomplete or provide search-suggestions. It does not have to do spelling corrections, but it has to be exhaustive as possible not missing any occurrence. Implementation of incremental-search is much simpler. It is just a immediately executed prefix-search through the text. The found-results are visually cued to the author by changing the background of the found text strings. The author is thus enabled to quickly see/spot the surrounding occurrences, both before and after the cursor location, boosting productivity. Suppose the user's current system color theme is of blue shading. The background current found string will have dark blue background. Other nearby occurrences of the string will have light-blue background. So when the user presses next/prev in the find/search dialog box, the cursor is moved to the next occurrence of the string, and the text-backgrounds of the found-strings are accordingly updated.
This kind of feature, ie. giving an instant visual feedback on the searched string while typing is already available in Microsoft Word at least since the version 2010, and there, it gives you both an highlighted background on the matching text and when less than 100 occurrences were found, a list of text blocks around the matched text pointing out the context. I simply really missed it once I switched to Writer.