#526 Search [Shift]Ctrl+H behave differently

release
closed-fixed
Program (402)
9
2006-10-17
2006-06-19
Anonymous
No

If I create a file with the following lines:

line 1: 00000000
line 2: 0000

and highlight '0000' on line 2, Ctrl+H finds '0000'
twice on line 1 and once on line 2. However,
[Shift]Ctrl+H finds '0000' once on line 2 and 5 times
on line 1. Shouldn't the behaviour be the same for both
forward and backwards searching?

Discussion

  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    • assigned_to: nobody --> yooden
     
  • TK Soh
    TK Soh
    2006-08-11

    Logged In: YES
    user_id=411637

    Looks like something to do with the cursor position.

     
  • Scott Tringali
    Scott Tringali
    2006-08-11

    Logged In: YES
    user_id=11321

    Bote that ^G has this same behavior. I vaguely recall some
    discussion on this and don't remember what the result was.

    Seems like a good idea to me. If I Shift-^G in a Mozilla
    mail message, it won't partially match the last selection.
    It's almost as if it does this:

    Starting point = (beginning of selection - length of
    selection)

     
  • Scott Tringali
    Scott Tringali
    2006-08-11

    • milestone: 103147 --> release
     
  • Tony Balinski
    Tony Balinski
    2006-08-13

    Logged In: YES
    user_id=618141

    Such behaviour is fine when the search pattern is of fixed
    length (as in a "literal"/"case" search); it is hard to
    imagine a decent way to do this for variable length patterns
    using regexes. The current way is at least consistent
    between these two search types: step back one then check for
    a match; repeat until found.

     
  • Joor Loohuis
    Joor Loohuis
    2006-08-13

    Logged In: YES
    user_id=197101

    I always considered the described behaviour perfectly
    normal, given what is happening with the cursor. Considering
    the fact that a search is done starting at the cursor
    position, and the cursor is placed at the end of a match,
    I'd expect a reverse search to step one position back at
    each search. Perhaps a reverse search should position the
    cursor at the beginning of the match. If such a change would
    be made, it would have to be optional.

    How do other editors handle reverse searching?

     
  • Logged In: NO

    kedit behaves just the same as nedit.

    arnon

     
  • Logged In: NO

    I looked at gvim.
    When doing a backward search, it places the cursor at the
    beginning of the match, so the search acts just like doing a
    forwrd search.

    arnon

     
  • Scott Tringali
    Scott Tringali
    2006-08-14

    Logged In: YES
    user_id=11321

    One could say that ^H is always a fixed-length string and
    can/should behave differently.

     
  • TK Soh
    TK Soh
    2006-08-14

    Logged In: YES
    user_id=411637

    IMO, treating ^H specially may create some confusion. In any
    case, I wonder what would happen if we place the cursor at
    the begining of the match.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-21

    Logged In: YES
    user_id=119143

    I think the behaviour is perfectly consistent: Not the
    search term is backward, only the iteration of the starting
    point. The alternative would mean that the search would have
    to start at an alternative point in the document
    ($selection_start - ($selection_end - $selection_start))
    which is not marked and not discernible.

     
  • Scott Tringali
    Scott Tringali
    2006-08-21

    Logged In: YES
    user_id=11321

    Funny thing... consistency depends on how you look at it.

    You could say that it's either consistent or inconsistent,
    depending on what you expect and how well you know the
    implementation.

    Throwing off my programmer hat and speaking strictly as what
    my gut would expect, I would expect it not to match
    mid-string going backwards since it doesn't match mid-string
    going forwards.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-21

    Logged In: YES
    user_id=119143

    It does not match mid-string going forward because the
    starting point for the next search is $selection_end, just
    as the starting point for the previous search is
    $selection_start (-1, necessarily).

    So, true, $selection_start could be starting point in both
    directions ($selection_end wouldn't make sense for backward
    searches). We would step through overlapping matches just as
    we do now on reverse searches. Most of the time the user
    wouldn't notice because there is overlap, but he would find
    them in case they exist.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-30

    Logged In: YES
    user_id=119143

    Seems again to be a pretty simple change. I don't really
    have a preference about this yet, I will try it out for a
    while. Feel free to chime in.

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-30

    Logged In: YES
    user_id=119143

    I have used this change for the last weeks and hardly
    noticed a difference. If noone objects, I would commit this
    as patched.

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-30

    • priority: 5 --> 9
    • status: open --> open-fixed
     
  • Thorsten Haude
    Thorsten Haude
    2006-10-17

    • status: open-fixed --> closed-fixed