Find again is bugged

I noticed today that since at least 4.64, probably far longer even, the find again function is bugged. It does not matter whether one searches UP or DOWN; the symptoms are exactly the same.

It will only highlight the first occurrence of the string you search for in said (unwrapped) line, and a second or third one will be fully ignored.

It might sound like a crazy problem, but I let MUSHclient do all my wrapping (think one line becoming about 20+ lines), and some people are really, really repetitive in their writing, continuously re-using the same few words in a sentence. I wanted to quickly count the occurrence of a certain word, and found out I couldn't. :/

I'm torn between agreeing it is a bug and trying to fix it, or trying to explain why it isn't a bug ...

First, by design, the find feature has a granularity of one "item". So for example, if you search the triggers list for "foo" and "foo" appears twice in a trigger (eg. in the Send box), that trigger is only "found" once.

Further, the find feature uses shared code (eg. finding triggers, line in the output, variables, timers, aliases etc.) because they all do basically the same thing:

• From a nominated starting item:
  
• Search the item for the desired string or regexp
  
• If found, remember the matching item
  
• Advance to the next item (forwards or backwards) for next time

This explains the behaviour you are seeing, once a line is matched, it starts again on the next line.

The item is remembered as a single number (eg. line number, item number in the triggers list).

I can't just remember the matching word in the output buffer as an offset from the start, because as lines are scrolled off the top of the buffer that offset would change. It would have to be a line-number/offset pair.

Even if the matching position *was* remembered, there would be cases where it wouldn't apply. For example:



In that case, we couldn't restart the search on the same line, because the anchored regexp wouldn't apply. (Nor could we re-apply the regexp starting at an offset, because that would then erroneously match on: "Worstje says Worstje says").

I am inclined to regard this as a documentation problem, and document that this is the expected behaviour.

I note that the Find function has been in MUSHclient since version 2.0 (May 2007) and you are the first to complain about this behaviour.

Well, from a user point of view, I fully disagree that it makes sense. A user sees text. Not a linked list of items describing lines where you might run into the affected word in the find function.

They see text. They search for text. They want to find text. It is that simple in my eyes.

To be honest, I don't see the problem. You already keep track of a line number for the find next feature if I read your post right. Storing an offset with it really opens up no can of worms that does not already exist.

The regular expression is a moot point as well. The user has anchored it, obviously making it so they expect a future find on the same line to return nothing, so I don't see how anything breaks there either. If it is the 'continue matching from an offset' that is problematic, I believe they have features for it. Otherwise, one will simply need to store the current search results with the line number. Perhaps it is easiest to simply call it the search state so there is less confusion: line numbers, offsets, regex match results of the current line. They're all a part of it.

I talk easily about this stuff, not diving into the code and all. But my point is that the things you bring up as the reasons for it being impossible must already be fixed somewhere for the current implementation to work.

Edit: And if the change in behaviour were to be an issue, you could always add a global option 'One find result per line' or something along those lines.

Can't you do the equivalent of enabling "repeat on same line"?

Well as it turns out, it already knows the position on the line. I am attempting to modify it to find multiple items on the same line in the output buffer.

At this stage it will only work forwards for the simple reasons that:

• The CString::Find finds the first occurrence of a string in another string, not the nth occurrence. You can specify a starting position, but that is going to affect looking forwards, not backwards.
  
• The regular expression matcher won't be easily adapted to look backwards through a string as far as I can see.

That was relatively painless, so version 4.70 will match on multiple items on the same line, finding forwards.

One possibility is to reverse the target string and the match string. Of course, this doesn't work very well if the match string is a regular expression; you'd need some way to reverse the generated machine, not the regexp string.

Yes, I think not for regexps. Imagine trying to do something like an assertion that a is followed by b, backwards.

I got it to work by doing this:

• When finding backwards, for each new line:
  
• Find *every* occurrence of the string or regexp
  
• For each one found, add to a list
  
• Once the line is completely processed then:
  
• Pull out the last item from the list (ie. start and end column) and return that as found (popping it from the list)
  
• Continue to pop found items from the list for that line until none left

Thus if "foo" is being searched for, and occurs 10 times on a line, then the list will contain 10 first/last column offsets of all the matches. Then the last one is returned. Then if you happen to do a "find next" then the second last one, and so on.

This should reliably step backwards, no matter how complex the regexp is.

That's awesome Nick. Thanks for writing a fix! :)