The problem is not about using non-greedy matching. It is about which chars you're matching. Specifically, you want to match 《 followed by any number of non-《 chars, followed by IJ》.
This is a regexp that finds that: 《[^《]+IJ》.
This is a typical operation, for searching text that has paired delimiters. For example, you do the same thing when searching ...
The minibuffer is a normal buffer, so you can use post-command-hook or after-change-functions (or both) to react to edits. You can use minibuffer-with-setup-hook to set them up:
(add-hook 'post-command-hook #'my-minibuf-after-cmd nil 'local)
(add-hook 'after-change-functions #'my-minibuf-after-edit nil ...
See these faces:
Face for highlighting Isearch matches.
Face for highlighting failed part in Isearch echo-area message.
Face for lazy highlighting of matches other than the current one.
Answer (just giving Fish):
Yes of course it is, this is Emacs.
Bound to up and down during find-file are the commands previous-line-or-history-element and next-line-or-history-element. So you should try to bind these functions to C-n and C-p.:
(define-key minibuffer-local-map (kbd "C-n") #'next-line-or-history-element)
(define-key minibuffer-local-map (kbd "...
In a comment underneath the question, the O.P. stated that he/she is using a version of Emacs on macOS Catalina -- presumably the GUI version (although not stated one way or the other).
In the event that Alan Third (the maintainer of the macOS port of Emacs) reads this, I really do appreciate everything that he has done and continues to do to keep the macOS ...
Ideally, one would not have to worry about line numbers at all: the various tools would cooperate to put you in the right place. However, there are holes in the coverage, so you occasionally need to know on what line you are and how to get to a given line.
As @lawlist points out, it would be preferable to use display-line-number-mode - see the EmacsWiki ...
It's all based on where the cursor is when you start the search.
C-hig (emacs)Basic Isearch says:
A backward search finds matches that end before the starting point,
just as a forward search finds matches that begin after it.
Searching backwards for word cannot find word2 because that instance of "word" doesn't ...
First, in general, Isearch uses the minibuffer only for M-e. So your minibuffer-local-isearch-map key binding is useless here. That's the keymap used when editing after M-e.
Second, your isearch-mode-map binding means that C-h ends up deleting the char in the buffer you're searching, not deleting a char from the search string. The current buffer remains ...
The following works.
(defun latex-isearch-in-math ()
"Call `isearch-forward' with `isearch-filter-predicate' set to filter out matches outside LaTeX math environments."
(lambda (BEG END)
(save-excursion (save-match-data (goto-char BEG) (texmathp)))))
The question seems unclear. What is "isearch shell"?
You seem to be using TAB during Isearch and expecting completion against previous search strings (?). If so, the key you want is C-M-TAB (not TAB), which is bound to isearch-complete in isearch-mode-map.
But you say "complete a word", not complete against a previous search pattern, so the question ...
Anything that makes changes to your ~/.emacs/~/.emacs.d/init.el initialisation file may, for various reasons, tinker with the emacs variables isearch-regexp-lax-whitespace and search-whitespace-regexp. This may lead to behaviour other than what most emacs users are used to, that is, a single space character standing for an arbitrary number of whitespace ...
I know nothing about pdf-tools. But it sounds like you're just asking how to make Isearch's lazy highlighting persist after you stop searching.
If so, the answer to that is to set user option lazy-highlight-cleanup to nil. C-h v tells you:
lazy-highlight-cleanup is a variable defined in isearch.el.
Its value is t
I will give the same answer as @Drew, but phrased a little differently.
Your expression 《.+IJ》will match the first 《, then will match the minimum number of characters (because of the ?) until the IJ》 sequence.
You cannot use the "non-greediness" of the ? to un-match the first matching 《 in order to find a later one.
An expression you can use to do what ...