On 31/08/2007, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Simon Large wrote:
> > On 31/08/2007, Alexander Klenin <klenin@gmail.com> wrote:
> >> On 8/31/07, TortoiseSVN <issues@tortoisesvn.tigris.org> wrote:
> >>> The following task has a new comment added:
> >>>
> >>> FS#384 - Regex support in search boxes
> >>> User who did this - Stefan Küng (steveking)
> >>> While the balloon tooltip and the indication whether regex will be used or not
> >>> (depending on whether the string is a valid regex expression or not) is good,
> >>> the dropdown menu to choose regex search (or not) is something I
> >> don't really like:
> >>> Most users will simply enter some text there (e.g., "/path/to/look/for", "authorname",
> >>> implemented feature", ...) which is a valid regex but still searches for
> >>> what the user thinks it will (even if the user isn't even aware that a regex search is done).
> >>> So adding yet another GUI element (button, menu, or whatever) is a
> >> little bit overkill.
> >>
> >> I too am unsure about this exact feature, but these are (small)
> >> problems I wanted to address:
> >> 1) Although rare, there are cases when the user wanted to search a
> >> string which just happened to be a valid regexp matching quite
> >> different thing. (e.g. TMyClass.MyMethod actually searching for any
> >> char instead of literal dot, a+b will found aaaab but not literal a+b
> >> etc.)
> >> Even if the user is aware of quoting rules, this still constitutes
> >> slightly irritating 'oops' moment.
> >
> > This is a very good point, and as most users are currently unaware of
> > the regex feature, and a good number will not even know what regex is,
> > let alone how to use it (TSVN is used by a lot of non-programmers
> > too), then I think regex should be off by default.
>
> Please let's not make this a bigger issue than it is. The regex search
> has been there from the beginning, and you *all* haven't noticed it
> until now. That means that "oops" moment doesn't really happen.
> Even with your examples (TMyClass.MyMethod would *maybe* find one or two
> other strings which aren't really intended, a+b would find aab too which
> isn't that big a deal because you won't find that many *words* which
> have two or more identical consecutive chars ) that's not a big deal.
It will find aab too, but that's not the problem. Regex a+b will not
find literal a+b. OK, it's an unusual case, but you might look for a
comment that you know you put in brackets.
> > There is already a drop down menu for the search box in the log dialog
> > (search messages, authors, paths, etc.). Adding a regex option here
> > would not take up any more space, and give better control IMHO.
>
> Yes, we could maybe add another check entry there for using regex. I
> don't say the current situation can't be improved, but I won't add more
> buttons to the log dialog for something that hasn't been an issue for
> more than two years.
>
> >> 2) When entering simple search string, automatic refresh of search
> >> results is good, because it provides a nice 'narrowing' filter -- with
> >> each new letter, set of selected commits is either reduced or left the
> >> same.
> >> However, when trying to enter and edit regexp, continuous auto-refresh
> >> is distracting, because the set of commits varies widely based on the
> >> part you entered.
> >
> > Agreed. Another good reason for controlling use of regex.
>
> If you don't like that, press Ctrl-F to bring up the find dialog. The
> filter box is for instant filtering, and people *expect* that the filter
> gets applied while typing (that's how all other apps work who have such
> a filter box).
Nonono, I like instant filtering. But the reason it works well is that
most expressions do not include any regex special characters. Try
entering .* in Firefox's instant find and it does a literal search,
not a match for everything. Is regex really that common in an instant
filter box?
> The filter timer is set to a whole second, which shouldn't interfere too
> much even when entering a complex regex. And don't forget: people will
> notice much easier that there's a regex in play if the filter gets
> applied automatically.
>
> >> I agree that manual regexps on/off switch is unwieldy, so maybe the
> >> following will be better:
> >> 1) Even if entered string is a valid regexp, still indicate (and
> >> perhaps even use, for tiny optimization) normal substring search if
> >> the string does not contain any special characters.
> >> This way users unaware of regexp feature who entered such characters
> >> will get visual indication that something 'unusual' happened.
> >> 2) If search string is 'essential' regexp, whether valid or not,
> >> increase auto-refresh delay.
> >> 3) If an (excellent IMO) suggestion by Lübbe in this task is
> >> implemented, add 'quote all special chars' in pattern menu, which will
> >> add \Q and \E around current search string.
> >
> > In regex mode, use pale green background to indicate a valid regex and
> > pale red to indicate invalid. Use a slow timer to refresh the list, or
> > none at all.
>
> It's a log dialog, not a carnival dialog.
> I've already made the background *slightly* reddish when the regex is
> invalid - that's enough coloring.
>
> > In non-regex mode, have rapid refresh of the list. Background is always white.
> >
> > BIG FAT WARNING: if we add background colour coding we have to provide
> > a way to set the colours for visually impaired users.
>
> Since I'm using an algorithm to calculate the reddish background, that's
> not an issue (as long as the default window background isn't full red,
> in which case there won't be a difference in the background color).
>
> > Maybe add a registry setting so that admins can prevent regex mode
> > from ever appearing on graphic artists' PCs (with apologies to all the
> > computer-literate artists out there).
>
> Way overboard here. Always remember: no one has noticed or complained
> about this for over two years. It's NOT A BIG ISSUE!
OK, fair point. I guess leave it as it is.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Sep 1 00:03:35 2007