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.
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?
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?
(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.
why not?
(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.
In principle I support a 'whole string only' search option to not have to use regex.
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.
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.
(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.
(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?
(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.
(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?
(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
(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.
(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...)
(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.
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.
(In reply to BogdanB from comment #17) > The discussion blocked from the placement of the option. Note that that's not a blocker. This feature can be implemented in two steps: first, the functionality (a flag that is passed to the implementation that does the actual search, and the search that honors that flag itself); then the UI part can be implemented, with the control defining that flag in the dialog decided. Additionally, the first step would already enable using it in macros.