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.
> 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).
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!
Stefan
--
___
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 Fri Aug 31 23:48:07 2007