#1908 Regex Wizard and Tester

open
nobody
GUI (476)
5
2012-12-21
2006-07-22
No

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.

Discussion

  • David Maisonave (Axter)

    Logged In: YES
    user_id=1435334

    Adding source

     
  • David Maisonave (Axter)

    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.

     
  • David Maisonave (Axter)

    Logged In: YES
    user_id=1435334

    Added line-search logic, and more help text.

     
  • David Maisonave (Axter)

    Logged In: YES
    user_id=1435334

    Added logic to highlight background text

     
  • Kimmo Varis

    Kimmo Varis - 2006-07-24

    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.

     
  • David Maisonave (Axter)

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-07-25

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-07-25

    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.

     
  • Nobody/Anonymous

    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.

     
  • David Maisonave (Axter)

    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.

     
  • David Maisonave (Axter)

    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?

     
  • Kimmo Varis

    Kimmo Varis - 2006-07-27

    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.

     
  • David Maisonave (Axter)

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-07-27

    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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks