Allow iterating matches in search #5

Closed
opened 2020-10-21 21:06:23 +02:00 by p · 0 comments
Owner

At minimum C-n and C-p should go to the next or the previous match, otherwise the search feature is difficult to use.

This needs further analysis.

The editor might be given a callback to attempt handling the key. The search function would go through a "search" binding map, find actions "down" or "up" and use this to invoke search() with a direction flag.

This can later be used to toggle flags, specifically case sensitivity or globbing (which should arguably be on by default).

It could also be used as the input mode for the selection add/remove feature of #2. The only caveat there is that the current search mode automatically does an ${input}* glob that cannot be disabled.

In general it would be nice to have some sense of the amount of files that match: one option is to highlight the matches (how?), another one is to append a low-contrast "(no matches)" or "(match 1 of 4)" remark to user's input, or to the right side of the bottom line (like an RPROMPT).

At minimum C-n and C-p should go to the next or the previous match, otherwise the search feature is difficult to use. This needs further analysis. The editor might be given a callback to attempt handling the key. The search function would go through a "search" binding map, find actions "down" or "up" and use this to invoke `search()` with a direction flag. This can later be used to toggle flags, specifically case sensitivity or globbing (which should arguably be on by default). It could also be used as the input mode for the selection add/remove feature of #2. The only caveat there is that the current search mode automatically does an `${input}*` glob that cannot be disabled. In general it would be nice to have some sense of the amount of files that match: one option is to highlight the matches (how?), another one is to append a low-contrast "(no matches)" or "(match 1 of 4)" remark to user's input, or to the right side of the bottom line (like an RPROMPT).
p self-assigned this 2020-10-21 21:06:23 +02:00
p added the
priority
label 2020-10-24 07:18:09 +02:00
p added the
WIP
label 2021-07-17 10:39:58 +02:00
p referenced this issue from a commit 2021-07-17 14:24:45 +02:00
p closed this issue 2021-07-17 14:24:45 +02:00
Sign in to join this conversation.
No Label
WIP
easy
priority
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: p/sdn#5
No description provided.