For some reason the kid is too lazy to suggest stuff himself so

(15:59:25) <@Vliedel> i'd love to see /filter be able to handle hash tables
(15:59:48) <@Vliedel> it just needs to add a switch for /filter to look to item or value
(16:00:37) <@Vliedel> and off course a switch to tell /filter that its supposed to treat in/outfile

I was just about to register
Anyway, the reason i like this is because it would be nice to combine the speed of /filter to sort or filter lots of data with the speed of hashtables to read 1 item.

How are you suggesting the table would be sorted?

So that if you sorted this table:

$hget(table,1).item = c
$hget(table,2).item = a
$hget(table,3).item = b

It'd become:

$hget(table,1).item = a
$hget(table,2).item = b
$hget(table,3).item = c

Or something else?

no so you can for example /filter hashtable @window matchtext

I don't think it makes a lot of sense to support hashtables in /filter since /filter is for the most part a sorting command, not just something to move/dump data. Maybe a /hdump command or similar..

uh /filter is to filter data isn't it? Sorting is another thing it can do. Anyway a hdump as i know them would only be able to dump all items to a custom window, where /filter can handle windows, dialogs and files. Plus it can sort in the same command if you wish..

The way you're suggesting it seems to be that hashtables will only be accepted as input, not output, which would make it inconsistent with /filters other features.

yeah output is a bit harder probably, as you need to provide items and value, which can only be provided if you can seperate them or so.

Sorting hash tables can already by done with /filter, but not directly from the table. Save the table's items to a file, or put it in a custom window if you want to do it that way, and then filter it. If you add line numbers when filtering, you will be able to $hget the line numbers to find what the data is. This works great for top 10 lists and can be done very quickly (under 1 second) with very large tables.