Carbon Emacs: no `focus' in minibuffer on incremental search

Question

Good day all,

my trusty old Carbon Emacs has developed a frustrating habit: when I use C-s, the minibuffer prompts for a search string, but it is not focussed. Obviously, typing in a string doesn’t do anything. I have no clue which buffer has the focus at that time.

When I press C-g, the search is cancelled as usual. When I press Return, the I-search prompt turns into a Search prompt, and the minibuffer regains focus. Update --- When I type C-w, the current word is set as search string, as usual, and subsequent C-s advance the search as expected.

AFAIK, I have not changed anything in the .emacs file, not customized anything. The version of emacs is the same, and the OS as well. This behavior also survives a restart of emacs. Even emacs -q doesn’t solve it.

Update -- turns out that `focus' is not the right word; with i-search, the focus stays on the buffer you're searching in, but the mini-buffer echos the search term. Well, it should, but it doesn't. So, the following snippet is looking in the wrong direction.

I’ve tried this snippet to regain focus on the minibuffer:

(defun minibuffer-refocus ()
 "Refocus the minibuffer if it is waiting for input."
 (interactive)
 (when (active-minibuffer-window)
   (message "")
   (select-window (minibuffer-window))))

(global-set-key (kbd "C-M-g") 'minibuffer-refocus)

But to no avail. It works like a charm in other cases, but not for the incremental search... Update -- That was to be expected.

Is there anyone that has any idea what’s going on, or has tips to hunt it down? This is really annoying...

Details

• GNU Emacs 22.3.1 (i386-apple-darwin9.5.0, Carbon Version 1.6.0) of 2008-11-01 on leopard.local
• OSX 10.6.7
• C-s runs the command isearch-forward

Update

the good news is that is is solved. The bad news is that I don't know how :-(

Update

The bad news is that it is back again. I also realize that the above snippet does really help because the mini-buffer doesn't really get focus.

Answer 1

This is solution that work for me. I post it because I search for solution and couldn't find it.

(defun isearch (arg)
  (interactive "MI-search: ")
  (select-window (minibuffer-window))
  (isearch-forward))

(global-set-key "\C-s" 'isearch)

I'm using GNU Emacs on Ubuntu.

EDIT: but if you use it you will not be able to search minibufer. Because of this feature you have no focus in minibufer when you search. For example you can do something like M-x C-s to search for functions names. And if you have focus in minibufer you can't do that.

Answer 2

Note that when you ran C-s, M-e provides a means to edit the searched pattern, but it is much less efficient than having C-s work as expected...

I face the exact same issue (on two different Lion machines), and I do not understand what is going wrong, yet I can tell you that:

• I use several "Input methods", i.e., several keyboard mappings: French and US Extended. I have selected the OS X option that allows to have keyboard mappings that depend upon the current application (I typically use US for Emacs, and French for mails for instance).

• The French mapping works properly,

• The US extended mapping fails as you described it,

• In the same Emacs session, going from on to the other preserves that invariant: French works, US Extended is broken,

The good news is: US not-extended seems to work properly! Maybe (maybe) C-s is some prefix on OS X in the US extended mapping for some multi-key character, and some very bad interaction are started between OS X, maybe expecting for the next character part of the multi-key sequence, and Emacs which steals them from it. Wild guess.

Answer 3

The good news is that it works again as expected. The bad news is that I don't know what fixed it.

I do think that @vpit3833 was pointing in the right direction with the recursive edit suggestion; I was answering another question about the Alt and Esc keys and after trying out some things, like doing ESC-x and similar combo's, the incremental search started working again.

Sorry I have no real answer, but at least I can close this topic.

Answer 4

I hit exactly the same problem, quite out of the blue, and discovered (as someone already pointed out) that it is something to do with OS X's own keyboard/input methods. I had been using the regular US keyboard, but then changed to the Unicode keyboard, which is when the problem arose. Once I went back to the regular US keyboard, i-search worked as expected. I got the same anomalous behavior with the US-extended keyboard.