[Libreoffice-bugs] [Bug 140805] FIND TOOLBAR: Incremental/Type-ahead search in Writer should be supported

2021-12-16 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=140805

--- Comment #6 from Dominique  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 140805] FIND TOOLBAR: Incremental/Type-ahead search in Writer should be supported

2021-12-16 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=140805

--- Comment #5 from hgkamath  ---

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 140805] FIND TOOLBAR: Incremental/Type-ahead search in Writer should be supported

2021-03-22 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=140805

Heiko Tietze  changed:

   What|Removed |Added

Summary|FIND TOOLBAR: Incremental   |FIND TOOLBAR:
   |search in Writer should be  |Incremental/Type-ahead
   |supported   |search in Writer should be
   ||supported
   Keywords|needsUXEval |needsDevAdvice
 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda
   |.freedesktop.org|tion.org

--- Comment #4 from Heiko Tietze  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs