ctrlf icon indicating copy to clipboard operation
ctrlf copied to clipboard

C-s and C-r doesn't always search the next or previous occurrence.

Open 4goodapp opened this issue 3 years ago • 2 comments

When I run ctrlf then run the command other-window C-x o , (to maybe do some editing), I have to run other-window C-x o again to get back to ctrlf. I expect I can run C-s or C-r anytime, whether the point is in the mini buffer or in the main buffer.

CTRLF takes the basic idea of Isearch, together with most of its keybindings, but emulates the more reliable user experience of web browser text search. For example: all editing commands can be used during a search as usual; C-g always has the effect of canceling the search; and C-s ALWAYS moves to the next candidate, with wraparound signaled by an overlay which indicates the current match index and the total number of matches (another UI paradigm borrowed from other programs).

4goodapp avatar Aug 20 '22 22:08 4goodapp

Fair enough. It looks like the current behavior is C-s and C-r have no effect when typed outside the minibuffer during an active search. I agree it would be an improvement to make them have the same effect as when point is in the minibuffer.

Until that is fixed, the best workaround I can think of is exiting the search with RET to perform editing, then resuming it with C-s C-s when editing is done. This is what I personally do.

raxod502 avatar Aug 21 '22 21:08 raxod502

Until that is fixed, the best workaround I can think of is exiting the search with RET to perform editing, then resuming it with C-s C-s when editing is done. This is what I personally do.

This workaround is fine for me as well. C-s C-s bring back ctrlf with previous searched text. Much easier than using other-window C-x o. Still I think ctrlf should after using other command command like other-window. Hopefully a fix won't be hard to implement.

4goodapp avatar Aug 22 '22 04:08 4goodapp