Isearch vs Ctrlf Mode
or; why I still use isearch over ctrlf
TL;DR: When you're in isearch-mode you can't use the usual editing
commands, but you can use M-e
to edit the current search term.
How I use isearch
isearch is the basic search command built into Emacs. The "i" stands
for "incremental"; it starts searching as soon as you start typing,
and refines the search term as you keep typing. There are also
commands to search based on where your cursor starts out: to search
for occurences of the term under the cursor, to gradually add
successive words to the search term, etc. You initiate a search with
control-s
, and successive control-s
while searching jump to
successive matches of the term.
A few subtle operational points make it a natural navigational aid:
-
if you hit
ENTER
your cursor is left at the current term, otherwise if you quit bycontrol-g
it returns the cursor back to where you started, and -
when you start a search, the mark is left at the start-point.
My workflow then typically looks like:
-
start a search with
control-s
-
Let's assume I'm looking for some function, or want a quick reminder of what I've defined, so I search for "defun"
-
I keep hitting
control-s
, quickly looking at each one -
Then:
-
If I've seen enough, I quit with
control-g
and I'm back where I was. -
If I want a more in-depth look, I stop searching with
ENTER
. When I'm finished, I can invokecontrol-SPACE
to jump back to where I was.
-
What, and why, is ctrlf-mode?
That all works great, and is so hard-wired that I don't even notice the little inconsistences or iritations around the process! The big one is: it actually takes you outside of "Emacs" mode in a way. That is to say, once you start searching, you can't use your normal editing commands to edit the search term.
For example, say I start searching for the string "save", but quickly
realise that there's a lot of these that I'm not interested in, so I
control-a
in order to go to the start of my term and refine it to eg
"_save".
This does not do what you expect! It actually quits your current
search, and jumps to the beginning of whichever line the cursor was
currently on. In other words, isearch-mode
displays your term in the
minibuffer, but you can't otherwise operate on it as you normally
would.
Most of the time I bump into this accidentally, curse and start again.
Others with more agency over their environment did not accept the
status-quo however, and there is now a competing ctrlf-mode
. This
works much the same as isearch
, but actually feels like more of a
first-class citizen of Emacs, because all your normal editing commands
operate as they should on your search term. When I grokked this, I
immediately switched.
Strangely, the swiitch didn't take and I've now reverted back to
vanilla isearch
, paper-cuts and all. Why?
One tiny inconvenience to keep my current workflow
My chief problem is that my isearch workflow has accreted several
extensions over the years, which seemed to be incompatible with
ctrlf-mode
, and to boot the nicer aspects of isearch
aren't
replicated.
-
The ability to add words (or characters, etc) is missing. I realised I used these way more than I might have realised!
-
Because
ctrlf-mode
does actually use the minibuffer, it's possibly harder to jump into other "modal" commands from it1. I use two such examples in my regular workflow:-
Start searching, then use
control-'
to immediately jump to my desired location viaavy-isearch
-
Start searching, then hit
meta-i
to switch toconsult-line
for an overview that I can fuzzily refine (ctrlf-mode
does let you switch tooccur-mode
, but this isn't as interactive).
-
Added up, I found I wasn't gaining enough benefit from the
improvements of ctrlf-mode
to warrant keeping it — so, I finally
went looking for "how to edit the isearch search-term": low and
behold, it's entirely possible and just needs to be invoked with the
command M-e
! Just hit control-s
again, or ENTER
, and you're
back to searching — not quite as smooth, but given the other
benefits above, more than enough for me.
Footnotes
I haven't tried very hard to implement this, so perhaps it is possible after all? I haven't found examples either though, and it doesn't seem to be a priority for the authors.