Regex Wizard and Tester
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
Menu
▾
▴
#1908 Regex Wizard and Tester
Adds a Regex Wizard button to the following dialogs:
Edit-Find
Edit-Replace
Line-Filters
Button will also be added to future comment-filter
dialog.
When the button is selected, the dialog passes the
current regex string (if any) to the Regex Wizard.
Currently, the Regex Wizard implementation only has
the tester. The wizard implementation will be added
later.
The tester includes example regex strings with example
source, that can be used to test regex.
If the OK button is selected, it changes the value of
the calling dialog's regex field.
Logged In: YES
user_id=1435334
Adding source
Logged In: YES
user_id=1435334
FYI:
There seems to be a problem with submittig zip files using
IE7.
When I use IE6, I can submit zip files with no problem.
When I use IE7, it just hangs for a while, and then I
finally get an error window on IE7.
Logged In: YES
user_id=1435334
Added line-search logic, and more help text.
entry 4
Logged In: YES
user_id=1435334
Added logic to highlight background text
Logged In: YES
user_id=631874
Nice idea and patch.
There are several problems though:
1) most importantly I don't believe "Wizard" approach (or
term in GUI) is good for regexps. Users think wizards as
click-click -thing for doing something (setting up something
with few steps). regexps are kind of programming language,
and creating simple click-click wizard would be hard.
I understand the need for easier regexps. But then, most
people don't need or want complex regexps, just simple
pattern matching for which they are used with filenames. So
another approach could be to convert simple patterns like
Dlg*.cpp to regexps for file filters would be nice. And
likewise for linefiltering etc ("*// TODO*" as regexp).
2) WinMerge is localized, so all user-visible strings must
be read from string resource. I know it is a pain...
3) ..so I'm not sure what to think about your long example
text. It has its merits, but how useful it would be for
Italian or Swedish users? Translators don't like it, thats
for sure.
Maybe better approach would be to give user current visible
text for testing too. Even find/replace could be done for
actual file contents since there is undo..
4) Try to avoid hard-coded colors. We have already enough
problems with them. Some users like weird colors in Windows
and so hard-coded colors break the GUI. Maybe you can use
difference colors, since there is hightlight color too.
Logged In: YES
user_id=1435334
>>Users think wizards as click-click -thing
>>for doing something
That's what I was shooting for. If you notice, the tester
has a Wizard button at the buttom.
However, I stop trying to implement the wizard, when I
found all the problems I was having with the current
WinMerge Regex implementation.
I couldn't add the functionallity I was looking for,
because the current implementation doesn't support it.
So I'm putting the Wizard part on hold, until I can
determine a better workaround. Either fix the current
Regex, or replace it with something better.
>>Dlg*.cpp to regexps for file filters would be nice. And
>>likewise for linefiltering etc ("*// TODO*" as
>>regexp).
That's hard to do with the current regex implementation,
since it doesn't have support for whole word
search. '\bmyword\b'
I think it would be better to set-a-side this patch, until
the regex implementation can be improved or replaced.
Or maybe I can just remove all the example text, and just
call this a Regex Tester.
I could modify the other dialogs, so the buttons are
renamed from Regex Wiz to Regex Test.
Logged In: YES
user_id=631874
> That's hard to do with the current regex implementation,
> since it doesn't have support for whole word
> search. '\bmyword\b'
If I remember correctly \W works as word search: \Wmyword
Manual confirms that since I've added
^// \WId: .*\$
as an example filter for filtering CVS $Id tags.
I've thought about one idea for an different approach into
this tester idea. No matter how smart example text we create
it always misses something. And user wants to search/filter
real-life files anyway.
For find/replace I think better idea is to convert dialogs
non-modal and allow user just test regexps with open files.
If regexp find result isn't correct user can just edit
regexp and click find button again, instead of opening
wizards and testers dialogs.
For linefiltering it can be non-modal dialog too. User types
regexp and editor highlights lines that do match.
For folder compare this gets very interesting. As with
linefilters, use non-modal dialog and highlight items that
match. Same dialog probably can be used for GUI-filtering
items, like "Hide Items" from context menu does not. So user
can easily remove items from results without editing
filefilter and rescanning folders. Would be pretty handy.
Logged In: YES
user_id=631874
Don't get me wrong, good wizard helps for sure. But I think
easier editing and possibility to see results immediately in
actual files is more useful in practice. Then it is easy and
fast just try how changes in regexp affect in practice.
Logged In: NO
>>For find/replace I think better idea is
>>to convert dialogs non-modal and allow
>>user just test regexps with open files.
This is an interesting idea.
However, one thing I like about the tester, is that you
can see all the hits (matches) at one time.
If I went with this approach, I would want to be able to
highlight all the matches.
I'm not sure how easy that would be if the there's already
highlights for diff lines.
Logged In: YES
user_id=1435334
>>If I remember correctly \W works as word search: \Wmyword
I just tried this, and it doesn't work with WinMerge CRegEx.
I get no matches.
FYI:
The previous noboy sender, was posted by me.
Something must have gone wrong with my browser when I
posted that.
Logged In: YES
user_id=1435334
I just tested \W with cregexp.cpp implementation, and it
does work with it, but it doesn't work with CRegEx class in
RegExp.cpp.
I don't understand why WinMerge has two different regex
implementation in the first place.
What was the motivation for this?
Logged In: YES
user_id=631874
You are right, it may not be easy to get highlighting for
find to work with highlighting for differences. Ok, one
solution is to add new configurable color for find
highlighting. That allows users to change it to fit their
color schemes.
> I don't understand why WinMerge has two different regex
> implementation in the first place. What was the motivation
> for this?
diffutils regexp is part of diffutils. Replacing it is of
course possible but not trivial. And every time we change
diffutils code updating that component becomes a lot harder.
We really need to update diffutils someday, but its huge
task already. New version has lots of rewritten code, so
merging our changes to it requires lot of work and testing.
Cregexp implementation was added (I think) for linefilters.
And actually there is third implementation in
editlib/cregexp.h/cpp. It comes with CrystalEditor.
Changing linefilters and editor to use same regexp would be
one logical step.
Logged In: YES
user_id=1435334
>>Ok, one solution is to add new configurable
>> color for find highlighting. That
>>allows users to change it to fit their color schemes.
I think this would be a good solution, even if you're not
using regex. A user might want to highligh all matches of
a regular search string.
I'll see if I can tackle this, and post a new patch with
this approach.
I would still like the tester to be included as an
alternative option.
Logged In: YES
user_id=631874
Yes, tester can be alternative too. Of course it is easier
to use tester when creating filters, as actual data may not
be known yet... For find/replace I think using current files
is better approach.