Bug 127174 - Search dialog doesn't support "whole word only" option
Summary: Search dialog doesn't support "whole word only" option
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Find-Search
  Show dependency treegraph
 
Reported: 2019-08-26 22:25 UTC by Eyal Rozenberg
Modified: 2021-01-29 20:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
potential UI mockup (24.36 KB, image/png)
2019-08-29 08:32 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2019-08-26 22:25:04 UTC
When searching for an expression in a worksheet, I can search for it as a substring, as the whole cell contents, or as a regular expression. That's good, but there's a missing option: Whole-word search. Many editing applications have this - and LO Writer has it, even, but LO calc doesn't.

This feature is important when searching for cell references, e.g. H1 : You don't want to get the results for H10, H11, H12 and so on.

Now, it's true that you can achieve the same with a regex search, but then you'd have to remember the syntax for word-boundary (which is different in different regex implementations, e.g. vim vs bash). Plus, few users know what regular expressions are and how to use them.
Comment 1 V Stuart Foote 2019-08-27 03:04:17 UTC
Hmm, we already use ICU libs for regex and word bounds are already integral. Imagine it would not be too much of a stretch to use ICU word bounds in a search option.

@Eike?
Comment 2 Heiko Tietze 2019-08-27 06:52:31 UTC
If you search for H1 you find H10 but "H1" retrieves only this term. It's a very common and sufficient way for this restriction, isn't it?
Comment 3 Eyal Rozenberg 2019-08-27 07:04:14 UTC
(In reply to Heiko Tietze from comment #2)
> If you search for H1 you find H10 but "H1" retrieves only this term. 

If you search for "H1" (with the quotes) it looks for "H1" (with the quotes). I'm not sure what you mean by your comment.

(In reply to V Stuart Foote from comment #1)
I wonder if the relevant code in Writer won't just work essentially as-is.
Comment 4 Cor Nouws 2019-08-28 18:09:02 UTC
why not?
Comment 5 Heiko Tietze 2019-08-28 18:31:51 UTC
(In reply to Eyal Rozenberg from comment #3)
> If you search for "H1" (with the quotes) it looks for "H1" (with the
> quotes).

Correct, I was wrong.
Comment 6 Thomas Lendo 2019-08-28 19:31:24 UTC
In principle I support a 'whole string only' search option to not have to use regex.
Comment 7 Heiko Tietze 2019-08-29 07:57:38 UTC
We discussed this topic in the design meeting. While too many options are contraindicated to usability, these checkboxes are collapsed by default. So let's do and introduce a whole word option.
Comment 8 Eyal Rozenberg 2019-08-29 08:32:32 UTC
Created attachment 153730 [details]
potential UI mockup

I was actually thinking about something like this as the UI, i.e. not in the collapsed section. Perhaps not in that position among the other boxes, but one of them. Sort of like we have in Writer.

Still, if you disagree - collapsed is better than nothing at all.
Comment 9 Thomas Lendo 2019-08-29 08:37:57 UTC
(In reply to Eyal Rozenberg from comment #8)
I support your idea but you must have localizations in mind which need mostly more space than the English strings and we should avoid a second line.
Comment 10 Eyal Rozenberg 2019-09-07 17:46:33 UTC
(In reply to Thomas Lendo from comment #9)
> (In reply to Eyal Rozenberg from comment #8)
> I support your idea but you must have localizations in mind which need
> mostly more space than the English strings and we should avoid a second line.

... and isn't that already a problem with the existing checkboxes?
Comment 11 Thomas Lendo 2019-09-22 20:23:39 UTC
(In reply to Eyal Rozenberg from comment #10)
> ... and isn't that already a problem with the existing checkboxes?
Yes. Now the dialog is for example much wider in German than in English what looks not good. When implementing this feature, an algorithm should be introduced that breaks the checkboxes into a second line in a logical and visually good way.
Comment 12 Eyal Rozenberg 2019-09-22 20:45:56 UTC
(In reply to Thomas Lendo from comment #11)
> When implementing this feature, an algorithm should be
> introduced that breaks the checkboxes into a second line in a logical and
> visually good way.

Is there a separate bug page for that?
Comment 13 Thomas Lendo 2019-09-22 21:24:30 UTC
(In reply to Eyal Rozenberg from comment #12)
> (In reply to Thomas Lendo from comment #11)
> > When implementing this feature, an algorithm should be
> > introduced that breaks the checkboxes into a second line in a logical and
> > visually good way.
> Is there a separate bug page for that?
Haven't found any yet. https://bugs.documentfoundation.org/showdependencytree.cgi?id=113136&hide_resolved=0
Comment 14 Heiko Tietze 2019-09-23 05:31:42 UTC
(In reply to Thomas Lendo from comment #11)
> ...an algorithm should be
> introduced that breaks the checkboxes into a second line in a logical and
> visually good way.

Objection. Multi-line check-/radio buttons are common on macOS but violate HIG on Windows and (all/most/some?) Linux WMs. The only solution is to make functions simple and easy to understand with a few words.
Comment 15 Eyal Rozenberg 2019-09-23 06:11:20 UTC
(In reply to Heiko Tietze from comment #14)
> Objection. Multi-line check-/radio buttons are common on macOS but violate
> HIG on Windows and (all/most/some?) Linux WMs. The only solution is to make
> functions simple and easy to understand with a few words.

I think you're misunderstanding Thomas: He meant (IIANM) conditionally having more than one line of checkboxes, not having individual checkboxes with more than one line of text.

Regardless - I feel implementing this feature is more important than its exact placement. So I wouldn't mind if it were added to the "Other options" set of boxes at first, after which point the argument about where it should be placed could continue (or not continue...)
Comment 16 Thomas Lendo 2019-09-23 10:09:03 UTC
(In reply to Eyal Rozenberg from comment #15)
> Regardless - I feel implementing this feature is more important than its
> exact placement. So I wouldn't mind if it were added to the "Other options"
> set of boxes at first, after which point the argument about where it should
> be placed could continue (or not continue...)
I support that it should be placed in the other options area. The 'whole cell' setting in Calc is the pendant to Writer's 'whole word' setting and not the mentioned 'whole string only' search option of this bug report.

If the 'whole string only' search option should be placed in the checkboxes area under the search field, this decision should be well justified as space is rare.
Comment 17 BogdanB 2021-01-29 20:44:27 UTC
Not here yet...
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: f2389a70da606768a39ee599de6a5b24058734aa
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

The discussion blocked from the placement of the option.