Add a temporary name filter to the current view of the main view window.

[toff]

By using 'F' in the main view window you can enter a regex that will be used to filter the current view based on the torrent name.
To remove the filter set the input to empty.
This is adding a 'view.temp_filter' property and a 'match{}' function.
For example with Ctrl+X you could do:
command> view.temp_filter=main,"match={d.name=,.*linux.*iso}"

• temp filters are view independent (you can set/unset different temp filters per view)
• you can't sub-filter a view that shouldn't be filtered (started, stopped)
• you can sub-filter views that are filtered already (even when filter is triggered frequently)
• if you only enter a word at filter> prompt it will auto convert it to a proper name filter
• log messages can be displayed when temp filtering occured
  • disabled by default
  • can be enabled with: ui.console.log.tempfilter.set=1
• (filtered) word along the name of the view is displayed if a view is temp-filtered (at the top left corner). E.g. [View: active (filtered)]
• certain views can be excluded from subfiltering via view.temp_filter.excluded config option
  • its default value: "default,started,stopped"
  • example usage in config: view.temp_filter.excluded.set="default,started,stopped,leeching"

Edited 2017/04/17 15:00 : Added chros73 more detailed description.
Edited 2017/01/08 11:00 : Fixed some ambiguity in the description.

[chros73]

Woow! It's a long awaited feature if it will be merged. Thank you!

A couple of notes though if you don't mind.
I still like the @pyroscope way to deal with the results.
Instead of filtering the main view itself (with sub-filter), what about:

• creating (defining) a new view (like here) e.g. named filter (somewhere here)
• assigning a key to it (e.g. F) and deal the manual filtering only (!) there

Advantages:

• filter view will be standalone, any sorting can be set-up for it in config files
• you can switch back and forth between the already filtered view and any other (until new filtering won't be triggered)

[toff]

Oops, my description is ambiguous.
When I say the "main view" I'm referring to the main view window (lists of torrents).
Currently the temporary name filter is applied to the current view of the main view window.
So it can be applied to any existing view.

[chros73]

Woow, indeed!

Sorry for my previous comment, just ignore it, I haven't played with it at that time. Now I did.
It works like a charm! :

• temp filters are view independent (you can set/unset different temp filters per view)
• you can't sub-filter a view that shouldn't be filtered (started, stopped) (see this)
• you can sub-filter views that are filtered already (even when filter is triggered frequently)
• if you only enter a word at filter> prompt it will auto convert it to a proper name filter

F key means capital f.

Small modifications:

• About log messages, since temp filter is view independent: display the name of the view as well. E.g.:
  • Clear temporary filter on 'main' view.
  • Temporary filter on 'name' view: .*nu.* .
  • View 'started' can't be filtered. (when try to filter on started or stopped views)
• Display (filtered) word (or the the actual temp filter as well: truncate it if it's too long (e.g. >32 chars)) along the name of the view if it's filtered (at the top left corner). E.g. instead of [View: active]:
  • [View: active (filtered)]

The modified patch:

• complete is here
• changes in it are: here , here , here and here

Thank You!

[chros73]

I just noticed 1 more thing: if a view is sorted (just once, not by a schedule2 command), and temp filter is cleared then the view won't be updated. You have to switch to another view then back.

E.g. suppose the name view that is sorted by default here:

I think the solution can be that here we call current_view()->sort(); (sort() calls filter()) instead of current_view()->filter(); .

Edit:
I just realized the scheduled sorting is on by default for name view as well: here
But we can emulate that it's off by overriding the 10 sec interval with 3600 sec in our config for the sake of the test:

schedule2 = view.name,10,3600,((view.sort,name))

[chros73]

Regarding to the above issue: we have to call both methods (filter() and sort() as well) in that case.

So, the complete patch is here and the last sorting fix is here.

Thank You for your work!

[toff]

I've merged your changes.
I've just moved the "started/stopped" view check earlier, on 'F' press.
Thanks to you too :-)

[chros73]

I've just moved the "started/stopped" view check earlier, on 'F' press.

Even better! Thanks

1 more suggestion popped in my mind:
Since we have indicator about a filtered view (top left corner) and usually we use 1 word as a filter, let's not display those 2 console messages by default (they are polluting the precious space in the console). It can be still useful, e.g. using complex regex.

So let's create a config directive for it that should be disabled by default, name can be something like: ui.console.log.tempfilter .

[chros73]

Your modified complete patch is here:
Changes are: here , here , here

You can enable console logging tempfilters with: ui.console.log.tempfilter.set=1 command.
I haven't touched the console log part on started and stopped views on purpose.

[chros73]

Just a note to those who use @pyroscope's rtcontrol (or any other xmlrpc util that uses views for queries): rtcontrol uses the main view by default to select data .
That means if this (or other used) view is subfiltered then the result of the query will be filtered as well! (E.g. summary of the size of all the deletable data, etc.)

[pyroscope]

Adding a view.temp_filter.excluded.set={stopped,started,main} setting would allow to exclude certain views from accidental filtering at will.

[pyroscope]

Looking at some uses of multicall and the main view, I think the current solution is a bad idea (see the scraping code by @chros73 that relies on iterating all items, and other multicall uses).

Filters should apply to the UI view only (i.e. keep / update a separate filtered list, so treat the filter result as a cache of the main list of a view), and a d.multicall.filtered command could make it available on demand. Right now, you have a massive breaking change when it comes to d.multicall2.

d.multicall.filtered should come in 2 flavors, use the user's active filter if only given a view name, else use the given explicit filter condition → d.multicall.filtered=viewname,filter,fields… with filter being empty meaning the currently set UI filter, else a bool condition as usual.

This would also remove the need to special-handle started and stopped (which is a sign of the breakage).

[chros73]

Looking at some uses of multicall and the main view, I think the current solution is a bad idea ...

Filters should apply to the UI view only (i.e. keep / update a separate filtered list, so treat the filter result as a cache of the main list of a view), ...

Right now, you have a massive breaking change when it comes to d.multicall2.

You're right. This alone renders multi-view solution into a single-view solution (like yours was but this one way faster): hence I only use it with name view since I don't filter / use it otherwise.

[pyroscope]

While looking at download_list, a) that command exists and is always unfiltered, and b) the forgotten default view should be exempt from filtering like started/stopped. It's forgotten because it has no default key binding, and thus should be used instead of main as a ‘default’ (duh!).

While I stand behind #519 (comment), adding "default" to the protected list makes the current implementation less dangerous.

[pyroscope]

From a view with 4 items…

$ rtxmlrpc d.multicall.filtered '' tagged 'and={(d.is_open),(d.ignore_commands)}' d.hash= d.is_open= d.ignore_commands=
['8D…05', 1, 1]
['F8…9D', 1, 1]

[chros73]

b) the forgotten default view should be exempt from filtering like started/stopped. It's forgotten because it has no default key binding, and thus should be used instead of main as a ‘default’ (duh!).

Wow! I don't think that I ever knew about this! Thanks for the reminder.
Just tried out and it indeed works. That changes things, again.

looking at download_list, a) that command exists and is always unfiltered

Which command do you mean?

While I stand behind #519 (comment),

I'm not sure anymore (with your revelation), again :) Since temp-filtering fits completely to the general filtering of rtorrent, and with the use of the proposed excluded option we can clearly stop harming our code.

adding "default" to the protected list makes the current implementation less dangerous.

So, view.temp_filter.excluded.set="default,started,stopped" would be correct as the default value for this option.

@rakshasa , what do you think about this feature?

@toff : will you modify this pull request with the mentioned changes or shall I create a new one instead of this?

[toff]

@chros73
I'm not sure I understand because the "default" view is not accessible from the UI as far as I know.
Of course it would not hurt to exclude it but doing it in the code should be enough ?

I don't use pyroscope / rtxmlrpc so I may be missing somethings.

[chros73]

@toff:

I'm not sure I understand because the "default" view is not accessible from the UI as far as I know.

That's correct until you use rtorrent-ps with which you can assign keyboard shortcuts to different objects, e.g. to existing or custom views.

I don't use pyroscope / rtxmlrpc so I may be missing somethings.

You don't have to use it, as @pyroscope mentioned you can use config snippets that rely on unfiltered (full) list of downloads (like auto scraping).

Of course it would not hurt to exclude it but doing it in the code should be enough ?

I think it's not enough.
Views also can be used (either by pyrocore or config snippets) to process predefined filter list of downloads :

• e.g. let's say you frequently want to do something with all of the currently downloading downloads (means leeching view), so you don't have to create custom code snippets but you can just use the leeching view with the help of d.multicall2
• in these cases, we want to main filter a view but we don't want to allow subfiltering (by accident) at all, hence we need a configurable option in our config

I hope it makes sense.

[chros73]

@toff :

I implemented @pyroscope's suggestion about having view.temp_filter.excluded config option that allows to exclude certain views from subfiltering.

• its default value: "default,started,stopped"
• example usage in config: view.temp_filter.excluded.set="default,started,stopped,leeching"

Changes:

• here's the diff for it
• complete patch is here
• I updated the description

Can you also add the previously mentioned ui.console.log.tempfilter option? (Here's the diff for it.)

Thanks

[toff]

@chros73
OK, I've merged your suggestions.

[chros73]

Cool, Thank You!

[pyroscope]

tempfilter vs temp_filter is unneeded variation, and also (view|ui).temp_filter.* would be more consistent.

[chros73]

@toff, can you rename ui.console.log.tempfilter to view.temp_filter.log as @pyroscope suggested: diff
Sorry about this, I hope this one was the last change. :)

[pyroscope]

Similar but ‘search instead of filter’ implementation at pyroscope/rtorrent-ps@b8a640b