Ticket #405 (new enhancement)

Opened 9 years ago

Last modified 8 years ago

fast filter

Reported by: iNode Owned by:
Priority: major Milestone: Future Releases
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: Votes for changeset:

Description

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.

Change History

comment:1 in reply to: ↑ description Changed 9 years ago by andrew_b

  • Version set to master

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".

comment:2 follow-ups: ↓ 3 ↓ 4 Changed 9 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 9 years ago by 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.

comment:4 in reply to: ↑ 2 Changed 9 years ago by 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).

comment:5 Changed 9 years ago by 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.

comment:6 follow-up: ↓ 7 Changed 9 years ago by 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

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 9 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by angel_il

  • Milestone set to 4.7

comment:10 Changed 9 years ago by angel_il

  • severity set to no branch
  • Milestone changed from 4.7 to 4.7.0-pre2

comment:11 Changed 9 years ago by angel_il

  • Milestone changed from 4.7.0-pre2 to 4.7.0-pre3

comment:12 Changed 8 years ago by iNode

  • Milestone changed from 4.7.0-pre3 to future releases
Note: See TracTickets for help on using tickets.