fast filter

[iNode]

Sometimes may be usefull use fast filtering instead of file search.

How it should works. Fast filter "dialog" (like the same for search)
called by some hot-key (i.e. C-/, because F9-f it's too long
and may vary for other locales).

Enter key do end of input and apply filter to panel.

May be some user case for update panel on any input field change, but it may be slow.

[andrew_b]

Replying to iNode:

called by some hot-key (i.e. C-/, because F9-f it's too long and may vary for other locales).

I propose "C-x f" or "C-f".

[ossi]

you can't propose c-f, as that's already taken. ;)

i wonder what the advantage over incremental search (c-s) or find (alt-?) with subsequent panelizing is supposed to be - these functions cover both the fast common case (you know the start of a particular file name) and the slow complex case. the fast not-so complex case seems pretty useless to me - at least i never missed it.

[andrew_b]

Replying to ossi:

you can't propose c-f, as that's already taken. ;)

You're right. It is used in command line.

[iNode]

Replying to ossi:

i wonder what the advantage over incremental search (c-s) or find (alt-?) with subsequent panelizing is supposed to be - these functions cover both the fast common case (you know the start of a particular file name) and the slow complex case. the fast not-so complex case seems pretty useless to me - at least i never missed it.

Filter is not search or find use case. Do you suggest remove it from menu?
I suggest make it more usable.

Also we can add other use case - navigation, if we filter (non strictly) not only files but also directories.

just situation, I has files:
.mc/
.mcop/
.mcoprc

I need the third. I should press C-s .mcoprc or C-s .mc and C-s and C-s.
Also with fast filter I can press C-/ .mco <DOWN> or C-/ .mc <DOWN> <DOWN> or
C-/ prc

If you use mocp you can see that behaviour on "/" key.
(It's make navigation more simple).

[ossi]

heh, i missed the fact that the function exists in the first place ... see how useless it is? ;)

your specific example is about navigation. i fail to see how the use of an incremental filter is any better than the use of an incremental search in that context. at least the number of key strokes is the same.

[iNode]

I don't fly on the plane last years but I do not say "See how useless it is".

Try to scale example and count again.

In my example you also can see differents if you open your eyes.
And, yes, Control-Meta-Shift-Win-C it's not just one keystroke.

press C-s .mcoprc or

2 keys + 7 keys to enter name = 9 keystrokes

C-s .mc and C-s and C-s.

2 keys + 3 keys + 2 keys + 2 keys = 9 keystrokes

C-/ .mc <DOWN> <DOWN>

2 keys + 3 keys + 2 key = 7 keystrokes

C-/ prc

2 keys + 3 keys = 5 keystrokes

[ossi]

Replying to iNode:

press C-s .mcoprc or

2 keys + 7 keys to enter name = 9 keystrokes

you get the same after 8 keystrokes already

C-s .mc and C-s and C-s.

2 keys + 3 keys + 2 keys + 2 keys = 9 keystrokes

actually it is 8 keystrokes, because you wouldn't release control.

C-/ .mc <DOWN> <DOWN>

2 keys + 3 keys + 2 key = 7 keystrokes

the first <DOWN> counting twice, as it is more distant, or needs an fn modifier (on some laptop keyboards). either way an equivalent of at least 8 keystrokes is fair.

C-/ prc

2 keys + 3 keys = 5 keystrokes

c-/ is a three-key combo for me.
other than that, filtering by a non-leading part is relatively uncommon, as it's not the way one thinks normally. on top of that, in a less artificial situation it is fairly likely that the infix match will yield more matches, so you'd need navigation again.
and finally, there is no problem with making c-s look for non-leading fragments if no leading matches are found. in fact, i might like that - i forget the leading dot of hidden files on a regular basis. though then it should priorize a match closer to the start over possible earlier matches.

[ossi]

Replying to ossi:

though then it should priorize a match closer to the start over possible earlier matches.

actually, that way, the currently only case is no special case: if the search is generally done column-wise, the leading case simply becomes the first match.
though if the actual implementation did it like that, infix matches would be relatively slow on larger directories due to cache misses. still, the leading case (and possibly the second column case) is the common case, so it might make sense to actually do it like that.