I use isearch all the time in Emacs but I've noticed on large org mode files it can take some time to find the first match. Is there any way to speed up isearch in a buffer?
EDIT: The most noticeable speed improvement came from setting isearch-lazy-highlight to nil. I was experiencing a noticeable delay when calling isearch to jump to text and this delay has now disappeared.
One thing to keep in mind is that the longer your search pattern the quicker the search. So quickly typing a long search pattern (or even entering one by using M-e) can help if the buffer is humongous.
Another thing you can do is to turn off option isearch-lazy-highlight, so you don't make Isearch find and highlight all of the matches in the currently visible text. See also options lazy-highlight-initial-delay and lazy-highlight-interval.
More generally, consult the Isearch doc.
If you were to Narrow the buffer to only the section(s) of interest before searching, then the search would be faster.
Whether this represents an overall time-saving or time-loss no doubt depends upon your use-cases.
Related
In a follow-up question to my previous question, is it possible to inhibit font-locking for a specific region in a buffer? I've looked through the special text properties portion of the manual, but couldn't find any properties that appeared to disable fontification. Is there another mechanism?
As an example, could font-lock be disabled for just the first line or two of a buffer?
There's no specific support for that, no.
You can try to abuse the font-lock-extend-region-functions, but you'll need to be extra careful to try and avoid inf-loops where one font-lock-extend-region-function tries to extend the region and you shrink it back ad-nauseam.
I used to be confident of returning to buffer from mini-buffer by just pressing C-g once, until I learned there is a "recursive-edit-mode" inside Emacs Here, which seems to make cancellation action inconsistent. Therefore, I am reading the entire section in hope of finding a more consistent / stateless command to return to mini-buffer.
However, I encountered below problems when following and trying to replicate what the manual says:
Entering Recursive-edit-mode: After "M-x query-replace RET C-r" (in Fundamental-mode), I could not replicate "a pair of square brackets" in mode-line. However, now I DO have to press C-g TWICE to return back to buffer.
Question: Does recursive-edit-mode still have square brackets now? (I am using ver 24.3)
Quitting: The manual directs me to the Quitting section for quitting command. It says Aborting with C-] (abort-recursive-edit) is used to get out of a recursive editing level and cancel the command which invoked it. So I tried it out within "M-x query-replace RET C-r", hoping one C-] will get me out from minibuffer to buffer, but it still takes 2 shots to do that.
Question: Is this normal? If yes, any other command to guarantee command abortion and return to buffer with 1 execution?
Just want to brush frequently used command such as C-g. If made consistent, it may help avoid inputs being eaten (sometimes unnoticed) by the minibuffer due to trapped inside recursive-edit-mode.
Visually confirming point each time inside the buffer makes keyboard input an closed-loop feedback process and thus consumes more attention, though.
You definitely will see square brackets in the mode line for a recursive edit -- but not for a recursive minibuffer.
C-g does act consistently, but it does different things in different contexts (always the same thing for a given context, however). That can be confusing. It can take some getting used to - a bit like it takes getting used to the various behaviors of C-g during Isearch, depending on the current search state.
If you use recursive edits or recursive minibuffers then you need to pay attention to clues wrt the current state/context. Again, this is like learning Isearch. minibuffer-depth-indicate-mode is a must, to provide feedback about what state you are in.
FWIW, beyond minibuffer-depth-indicate-mode, I use a standalone minibuffer frame, and with each recursive edit or recursive minibuffer the background hue is changed slightly, to better indicate the level etc. (The background color changes slightly also for (a) active minibuffer and (b) Isearch. I use library oneonone.el for these things.)
If you don't use a standalone minibuffer frame then you might consider highlighting the square brackets or something else in the mode line, to help you tell where you are at.
C-r during query-replace is a good example of when a recursive edit can be useful. There are a few others. But generally I do not make much use of recursive edits, FWIW. (I do, however, use recursive minibuffers a lot, because I use keys bound in minibuffer maps that do invoke commands that themselves might prompt for input etc.)
Wrt your question about query-replace with C-r: There is no minibuffer involved at all, here. And C-] after C-r does end not only the recursive edit but also the query-replace (whereas C-M-c ends the recursive edit and returns to the query-replace.
FWIW - In Icicles interactions, you might find yourself within any number of recursive minibuffers. (For example, you might use progressive completion to successively narrow the set of completion candidates, and each narrowing opens a recursive minibuffer.)
C-g always aborts the current command, or if there is none then the current minibuffer, and C-] always aborts the current minibuffer. Repeating C-g (or C-]) pops back up the minibuffer chain, a level at a time. But (in Icicles) you can use C-M-S-t (aka C-M-T) to pop directly back to the top level (exit all minibuffers).
Similarly, answering a minibuffer prompt (e.g. hitting RET or using mouse-2 on a candidate in *Completions*) exits the current minibuffer, popping up a level (to the parent minibuffer or to the top level if there is none). (In Icicles RET can optionally put you back at top level.)
It's not that convenient when you do a typo during an incremental search and the search string receives the wrongly typed character. Is there a way to prevent this. As if control-g was pressed automatically on error.
For example we have the following text:
keywords
keys
Default emacs behavior:
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" won't be found, the cursor stays on the "keywords" line, search echo area displays "keyzs", which is not convenient
Needed behavior:
We start incremental search and search for "keyz"
The "key" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" is found and highlited
You could try something like
(defadvice isearch-printing-char (before drop-mismatches-on-next-char activate)
(while (or (not isearch-success) isearch-error)
(isearch-pop-state)))
Emacs keeps the incorrect part, because it happens very often that you search for a string and it is not found, but not because it's incorrect, only the search string is found before the cursor. In this case it is very convenient that you can press C-s and the search starts from the beginning of the file.
It is very useful behavior and it happens to me more often than mistyping the search string. If there is indeed an error in the search string then you can simply press C-g to go back to last good search string.
I think the problem is that you're not thinking about searching in a way that's congruent with the way isearch has been designed to work, and so your question doesn't really make sense within the context of isearch as it currently exists.
Isearch does already give you exactly the feature what you want, but you have to tell it that you want it to happen by typing that C-g you seem so vehemently opposed to typing. If you don't tell isearch what you want to do, and when you want it to do it, how is it supposed to know what to do?
As #Tom tried to explain, the default way isearch starts from the current position in the buffer, and can restart at the beginning of the buffer if you've typed some failed characters and then press C-s, is a very valuable feature. I'm sure many people rely on this behaviour. Your method of using a macro to always start an isearch at the beginning of the buffer would confound and confuse many of us, though of course it's not a bad thing for someone such as yourself who is accustomed to it. It does mean though that the rest of us are quite confused by your dislike for having to press C-g to delete the non-matching text.
Think also for a moment about what a second C-s does if you press it immediately after starting isearch (any time but the first time in a session) (i.e. before you type any other character). Note in particular what happens if your previous search string would only partly match something in the current buffer, and then you press C-g (and also note how the failed search string is presented, regardless of whether it would partly match something in the current buffer or not).
Think also about how your feature might adversely affect the use of multi-isearch-next-buffer-function.
Claiming that other editors can do what you want isearch to do in emacs doesn't really help your case much.
I think what you really want is some slightly different type of search function which only allows you to search for text that it is possible to find in the current buffer, instead of isearch's ability to search for anything whether that text happens to exist in the current buffer or not.
Perhaps isearch-mode could be adapted to do what you want it to do, but one way or another I think you'll have to write some elisp code. Perhaps you could implement your new search mode as an option within isearch-mode that can be toggled on and off in the same way case sensitivity can be toggled on and off; and that can be set by default, again in the same way that case sensitivity can be turned on or off by default.
If you make a typo during incremental search all you need to do it press backspace to correct the typo.
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press backspace
We press s
"keys" is found and highlited
As with most of the other answers, I'm just pointing out another feature which helps mitigate the described problem. This one is particularly useful if you've continued to type several would-have-been-good characters after the bad one.
M-e is the binding for editing the isearch string, and in the case where there are no matches for the current string, it rather helpfully places point at the first non-matching character.
So if you have made a small typo, you can quickly type M-e, fix the mistake, and type RET to return to isearch using the corrected search string.
Emacs reindents the current line whenever I type certain things, like ";" or "//". This is pretty annoying, since there are a whole lot of places where it isn't smart enough to indent correctly.
How do I disable this feature? I still want to be able to indent the line with TAB, but I don't want any source code I type to cause it to reindent.
(I'm using Dylan Moonfire's C# mode, but this probably applies to any cc-mode.)
Try running c-toggle-electric-state to turn off the electric action of these characters.
You can do this as part of a c-mode-common-hook, or toggle the state manually by hitting C-c C-l.
most likely caused by the inline-and-indent 'feature' of c-mode and derivatives. emacswiki has several solutions.
In vim, visual block can be recall by 'gv' command so that multiple commands can be applied easily. (such as, comment out, then indent, then do_something_fun).
In Emacs, how can this be achieved?
[C-xC-x] only works when current cursor position stays where previous block ended.
If previous block was changed, the closest is to go through 'point-to-register' and 'jump-to-register'.
Just I am curious if there is an Emacs built-in command making this in one shot.
If Transient Mark mode is off, the region is always active. If it's on (which it sounds like is your situation), you can set mark-even-if-inactive to non-nil to allow region commands to work while the region isn't highlighted.
However, note you also can cycle back through previous mark positions using C-u C-SPC -- this will pop the mark ring. Once you're back to where you want to be, C-x C-x will rehighlight the region you want. (It may take a little bit of playing with this feature to get a feel for it, but it's why I can't switch away from Emacs now.)
If I understand correctly what you are asking for, then you don't need to do anything. When you select a region in emacs, it stays selected until you select a new one. So you could select the region and then perform as many actions as you want.
Sounds like you're looking for the secondary selection, which stays put even as the region might change. (It stays put until you move it.)
See:
the Emacs manual, node Secondary Selection
Emacs wiki page Secondary Selection
library second-sel.el:
Also narrow-to-region (CTRL-x n n ) applies every command from then on just to that region- you can't hurt the rest of the buffer, it doesn't even show. After done editing , widen (CTRL-x n w )to get back the whole buffer.
CMM
If you use evil-mode, just press gv like in vim.
Since the answers here and for other similar SO questions didn't help for me (CUA-mode, Emacs 24, not only indent-rigidly), I continued searching and finally found a reselect-last-region defined in this collection of custom function (starting line 670). That worked like a charm for me - and hopefully does for others still arriving here.