[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Find again is bugged
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
Find again is bugged

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Wed 10 Nov 2010 06:29 PM (UTC)  [ quote  ]
Message
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. :/
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Wed 10 Nov 2010 08:03 PM (UTC)  [ quote  ]
Message
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:


Search for: ^Worstje says 
Regexp: checked


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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #2 on Wed 10 Nov 2010 08:19 PM (UTC)  [ quote  ]

Amended on Wed 10 Nov 2010 08:32 PM (UTC) by Worstje

Message
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.
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Reply #3 on Wed 10 Nov 2010 08:33 PM (UTC)  [ quote  ]
Message
Nick Gammon said:
*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.

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

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Wed 10 Nov 2010 09:53 PM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Wed 10 Nov 2010 10:51 PM (UTC)  [ quote  ]
Message
That was relatively painless, so version 4.70 will match on multiple items on the same line, finding forwards.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Reply #6 on Wed 10 Nov 2010 11:52 PM (UTC)  [ quote  ]
Message
Nick Gammon said:
*The regular expression matcher won't be easily adapted to look backwards through a string as far as I can see.

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.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Thu 11 Nov 2010 03:35 AM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #8 on Thu 11 Nov 2010 03:42 AM (UTC)  [ quote  ]
Message
That's awesome Nick. Thanks for writing a fix! :)
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

2,042 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]