Forums Bug Reports $hfind not updating $regml with the new syntax

As the title says, $hfind is not updating $regml() when you use the new syntax:vs

Note: this is rather a feature suggestion; just like before, I know this is just an edge case that must be handled

This is not possible when using the new format because the matching process takes place first, with the results being accumulated in a list which is processed afterwards. If you want to access $regml() results, you will need to use the old format, where the matching and processing are performed at the same time per item. I would not be able to add what you are requesting because $regml() is an independent identifier. The same issue would apply to any identifier that maintains a state value that changes during processing when called using the new method in $hfind().

This is how you designed $hfind to work yeah. Is there any special reasons for that design? What prevent you from executing the command everytime you have a match?

This change was implemented because scripters asked for a way of sending the results of $hfind() to a @window or an alias. The only way to implement this was to create the match list and then process it, which precludes $regml() (or any other identifier) results that maintain states per item match. Unfotunately the only way to make identifiers work in the context you are asking would be to use the old method of specifying the Nth item and managing the results yourself.

Note: I recall that at one point the new implementation did send the results to the @window or alias inside the match loop (per item match), however this resulted in gpfs/crashes because scripts were modifying the hash table that was being processed in the loop. So I changed the method to build the list of results first and then process them outside of the hash matching loop, which is what is causing $regml() not to work in the way that you want.

I know, I'm the one who asked for that change (no crash afaik, it would just keep matching as you added items to the table, not ideal but scripters could have worked around it), and who basically asked for that new feature anyway.
Here, you are agreeing there is a way to do it 'per item match', but you are saying the method is the cause of the problem above. That's quite not true.
Processing first and then executing the command does work around the problem but brings the $regml() issue (as far as I can see, this is the only problem, others identifiers are not related to the processing). Now, making a copy of the table and using this table to do it 'per item match' would prevent the problem with modifying the table being processed, while still allowing us to use $regml().
Any reason it cannot be implemented that way?

Modifying the hash table during the loop would definitely have resulted in memory corruption and gpfs/crashes at some point, even if you did not experience them yourself. As for making a copy of the entire hash table to use for the matching process, that would not be practical. Allocating memory and duplicating the contents of a hash table with thousands of items, or perhaps far more if a user is processing a large hash table, would be both slow and memory intensive. The only solution for your situation is to use the old $hfind() method I'm afraid.

The main point of that new syntax is the speed improvement, the original feature suggestion was actually about getting small amount of match in a big table.
I'm sure the time spent on copying the hash table is going to be negligible compared to the whole speed improvement.
Now rest the memory problem, I don't think being memory intensive is a problem as long as it's not on the long run; unless this is a stack issue, I can see only advantages.
$hfind is one the most powerful function in mIRC and I don't think this should be ignored just because it's only for $regml(). It could also only make a copy when regex are involved.

edit: What is best is to revert back to the previous method and keep track of items added during the search&match in order not to match them, much better than copying the table.

I think you have to weigh up functionality vs. speed. Keeping track of added items is going to slow down the identifier for the sake of filling $regml(1).

I wonder if a separate identifier, say, $hfindrml(), could be made for that purpose.

Or even a .ml property?

I'm just trying to see if we can improve $hfind consistently, I see this as an issue .
As far as speed goes, using the new $hfind syntax is faster than the old $hfind and I think that changing the new $hfind syntax to execute the command for each match without pre-processing by keeping track of added items would still be faster than using the old $hfind, so there is still a speed gain :P

Using a new property for $hfind isn't possible because there is already .item/.data .
Imo, pre-processing isn't needed and only brings the $regml problem, I don't understand why one would do it this way.
The help file doesn't even mention that you cannot use $regml with this new syntax, of course people will try to use it.

Khaled, please look into it!