Carbon Emacs：没有“焦点”；在增量搜索的迷你缓冲区中
大家好，
我值得信赖的老 Carbon Emacs 养成了一个令人沮丧的习惯：当我使用 Cs 时，迷你缓冲区会提示输入搜索字符串，但它不集中。显然，输入字符串不会执行任何操作。我不知道当时哪个缓冲区具有焦点。
当我按下 Cg 时，搜索会照常取消。当我按 Return 时，I-search 提示会变成 Search 提示，并且迷你缓冲区会重新获得焦点。 更新 --- 当我输入 Cw 时，当前单词像往常一样被设置为搜索字符串，后续的 C 按预期推进搜索。
AFAIK，我没有更改 .emacs 文件中的任何内容，也没有自定义任何内容。 emacs 的版本是相同的，操作系统也是如此。重新启动 emacs 后此行为也不会消失。即使 emacs -q 也无法解决它。
更新——事实证明“焦点”不是正确的词；使用 i-search，焦点停留在您正在搜索的缓冲区上，但迷你缓冲区会回显搜索项。嗯，应该如此，但事实并非如此。因此，以下代码片段的方向是错误的。
我尝试过这个片段来重新关注迷你缓冲区：
(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)
但无济于事。在其他情况下它就像一个魅力，但不适用于增量搜索......更新 - 这是可以预料的。
有没有人知道发生了什么事，或者有技巧来追捕它？这真的很烦人...
详细信息
- 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运行命令 isearch-forward
更新
好消息是问题已解决。坏消息是我不知道如何:-(
更新
坏消息是它又回来了。我还意识到上面的代码片段确实有帮助，因为迷你缓冲区并没有真正获得焦点。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
请注意，当您运行 Cs 时，Me 提供了一种编辑搜索模式的方法，但它的效率比让 Cs 按预期工作要低得多...
我面临完全相同的问题（在两台不同的 Lion 机器上），但我没有了解出了什么问题，但我可以告诉您：
我使用几种“输入法”，即几种键盘映射：法语和美国扩展。我选择了 OS X 选项，该选项允许根据当前应用程序进行键盘映射（例如，我通常使用 US 进行 Emacs，使用 French 进行邮件）。
法国映射工作正常，
美国扩展映射按照您的描述失败，
在 ，从一个到另一个会保留该不变量：French Works，US Extended 已被破坏，
好消息是：US not-extend 似乎工作正常！也许（也许）Cs是美国OS X上的一些前缀，用于某些多键字符的扩展映射，并且OS X之间开始了一些非常糟糕的交互，也许期待着下一个字符部分多键序列，以及从中窃取它们的 Emacs。疯狂的猜测。
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.
好消息是它再次按预期工作。坏消息是我不知道是什么解决了这个问题。
我确实认为@vpit3833 的递归编辑建议指向了正确的方向；我正在回答另一个有关 Alt 和 Esc 键的问题，在尝试了一些操作（例如执行 ESC-x 和类似的组合）后，增量搜索再次开始工作。
抱歉我没有真正的答案，但至少我可以结束这个话题。
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-xand similar combo's, the incremental search started working again.Sorry I have no real answer, but at least I can close this topic.
这是对我有用的解决方案。我发布它是因为我搜索解决方案但找不到。
我在 Ubuntu 上使用 GNU Emacs。
编辑：但是如果你使用它，你将无法搜索迷你缓冲区。由于此功能，您在搜索时无需关注迷你缓冲区。例如，您可以执行 Mx Cs 之类的操作来搜索函数名称。如果你专注于迷你缓冲区，你就不能这样做。
This is solution that work for me. I post it because I search for solution and couldn't find it.
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.
我突然遇到了同样的问题，并且发现（正如有人已经指出的那样）这与 OS X 自己的键盘/输入方法有关。我一直使用常规的美国键盘，但后来改为 Unicode 键盘，这就是问题出现的时候。当我回到常规的美国键盘后，i-search 就按预期工作了。我使用美国扩展键盘也遇到了同样的异常行为。
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.