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

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.

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.

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.

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.

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.

Related

How can I fix Xcode's open quickly?

I wonder if I'm doing something to make it not work, but simply put after tapping cmmd + shift + O or going to File >> Open quickly the option doesn't show up. It's like I did nothing.
Wondering if this is a known Xcode bug or if I'm doing something.
I'm using Xcode 10.1
You probably have more than one monitor connected.
This is something that confused me a lot of times as well; the quick search prompt will remember its position (you can drag it around) even on secondary monitors.
For what is worth, in my opinion, that field should always be presented on the current (in focus) editor.

Is there a standard public-friendly keyset available for vim?

I've seen several bits of documentation on how to do ad-hoc vim key bindings.
Since I'm trying to pitch vim (or, to be more accurate, the idea of free 'nix text editors in general) to a coworker, I'm hoping to make it as painless for them as possible.
In contract to that ad-hoc approach, is there a wholesale block of widely accepted text I can throw into a .vimrc file in order to make most "standard" mac or windows keyboard shortcuts behave roughly the way they would on those systems? (For example, ctrl-s for save, ctrl-f to bring up a search, ctrl-v to "put" a string, ctrl-w to close, ctrl-q to quit, or some subset/superset of those ...)
Thanks for any help. I'm happy to build these on my own if needed, but I figured that if I'm documenting it for future use, I might as well link out instead of rebuilding the wheel.
I did a bit of looking around before asking, but if this is a duplicate, feel free to merge.
mswin.vim provides many typical Windows keybindings, so that any Notepad user will feel almost comfortable with Vim. You enable that by putting
source $VIMRUNTIME/mswin.vim
into your ~/.vimrc, cp. :help mswin.vim.
:set insertmode
(or starting via evim) almost turns Vim into Notepad by defaulting to insert mode :-)
The downside is similar to training wheels for bikes: It allows for some quick successes, but overall takes longer to become proficient. (I personally started out with mswin.vim, and gradually reduced the mappings.)
There is cream. It's a vim plugin that starts in insert mode and rebinds ctrl-c to copy, ctrl-v to paste etc...
http://cream.sourceforge.net/home.html
It's intended to make things easier for people used to editing in more conventional editors. That said I never used it. I learned vim the hard way and don't regret it.

Improving development flow and editing with XCode.

XCode is a little weak in the way that it obliges you to format code, and the restrictions it places on you. I'm thinking of things such as select a block of code and use tab to reposition the whole block, which is very useful for cleaning up indenting, amongst other things.
I realise that I can use an external editor (such as Sublime Text 2, which is superb and my daily editor) to edit code, but I'm wondering if there are any plugins or tools which exist out there which integrate into xcode to improve this development experience.
What kind of extensions exist for xcode, or if there aren't any, are there any lesser-known features which assist in improving this?
It's hard to give you an answer, as we don't know what features you use elsewhere that you think are missing in Xcode. For example, you can move a block of code in or out by pressing Cmd-{ or Cmd-}. Or you can "fix" the indenting by using ctrl-i as jrturton pointed out above. All of the emacs keybindings work. In fact, you should look over the key bindings in the prefs to see what other things are possible. Some of my favorites are:
1) Select a word and hit Cmd-E to make it the search term. Then Cmd-G to find the next instance.
2) F6 to step over in the debugger, F7 to step in and F8 to step out
3) As much as I hate command lines, gdb has a number of useful commands for calling methods while stopped at a breakpoint. You can call any function or C++ or Objective-C method using the call command. (Type help call at the gdb prompt to learn more.)
4) If your index is up-to-date, you should be able to Cmd-click on a symbol to go to it's definition, or option-Click to see its documentation.
Are those the sorts of things you're looking for? If not, please give examples of what you want. As far as I know there is no plug-in mechanism in Xcode 4, so no extensions exist.
Though the first answer is a great one (learned a lot from it), I wanted to add a little hint that helps me a lot when pasting codesnippets. A lot of times xCode copies indentation in a way I don't like and then I have to reindent the whole snippet.
What I started to do is jump to the first char in line (ctrl + a | cmd + ArrowLeft) and either paste the code immediatly, or indent by one or two before pasting, dependend if I'm in a function, loop etc.

What's the point of viEmu plugin for Visual Studio?

This may sound a bit provocative but it actually is a real question. Feel free to edit if you don't like the tone.
Now, as much as I understand vi from my short experience with it like 10 years ago, it's a primitive text editor with one editable line at the bottom of the screen created before the scrollbars were invented, with some crazy shortcuts to overcome this limitation.
Can somebody explain me how one can be more productive with it than with, say normal VS.NET editor? Moreover, why would anybody want to use viEmu which supposedly turns your VS.NET into an ancient vi?
I'm willing to give it a try but I need some motivation to overcome the learning curve.
It honestly sounds like you have never seen someone use Vi who is truly proficient in it. When you normally use Visual Studio you frequently will move your hand over to your mouse, click through options, dialogs, classes, etc.
With ViEmu your hand never leaves the keyboard. You are compiling, switching files, highlighting groups of text, fixing indentation, performing complex motions on your code and running regular expression searches in seconds. For people who are fast typists it allows you to achieve a speed for tasks you would not be able to otherwise.
Many people will counter this by saying things like, "Most of my development time is spent thinking. The extra speed I gain from using tools like these is negligible.".
That is a non-argument in my opinion. It is true, for most large programming tasks you spend far more time planning and thinking then you do actually slinging code. But that doesn't mean that being able to express yourself through your IDE 2x faster doesn't have an impact on your productivity as a programmer.
The viEmu page itself has a pretty good article that might help to answer your question: Why, oh WHY, do those #?#! nutheads use vi?
I've spent the last couple months trying to teach myself to use vim "properly" and now I can hardly stand using other editors because they seem underpowered and clunky. For a random example, imagine you have a line of code that looks like this:
$welcomeMessage = "Welcome to SiteName!"; // shows at the top of homepage
In a normal editor, how would you change the string? You'd probably have to reach over and grab your mouse and carefully select it, or you'd move your cursor inside the first quotation mark, and hold down Shift and the right-arrow until you got to the closing quotation mark.
In vim, with my cursor anywhere in-between the quotes, I type ci" and it erases everything inside the quotation marks and puts me into insert-mode so I can type the new value I want. My hands didn't even have to move from my normal typing position.
There are so many things like this, I think you really have to spend a while using the editor to understand how powerful it is. It's very slow and hard to use at first, that's why a lot of people try it for a short time and think "this is dumb, everything is way harder", but after a while you start thinking in terms of the motions, it all starts to become automatic and it's much, much faster than using a "normal" editor. As I said, I can't go back now.
I've also had trouble understanding why people choose vim as their editor, even though I was using it from time to time, until I've finally "got it". I think most explanations of "why?" fails, because they fail to show couple crucial points. To explain those points, first you need to understand that in vim you are manipulating text primarily being in command mode. Ie by default your key presses are commands, and do not usually insert any text, unless those commands (like append, insert, change) switch to insert mode. This lets you navigate and edit your text easily without ever touching your mouse or moving your hands away from "editing pose".
Now the crucial points are:
Vim commands are divided into nouns, verbs and modifiers.
Editing is performed by combining them.
And this is what gives vim the power. To ilustrate the point, here are some most used commands:
Nouns: word, sentence, block, quotes and braces.
Verbs: cchange, insert, visual, delete
Modifiers: inside, around, till
And to ilustrate how you can mix them:
Want to change a word? cw
Same, but cursor in the middle of the word? caw
Change text inside quotes? ci", also change quotes? ca"
Delete function body? di{
Delete up till first comma? dt,
Delete up till second comma? d2t,
Jump to first comma? t,
Select word? viw
Also notice how all commands nicely translate into natural language:
delete word
change inside {
In vim if you learn a new verb, noun or modifier, you can easily mix and match with what you already know. So basically learning just one thing, you learn how to do a lot of different things.
Another great thing is that vim remembers what commands you have used, and you can repeat the sequence just by pressing .. For this post I've had to surround a lot of letters with <kbd> tag. But I've did that only once, and then just went over each letter and pressed ..
And that's basically the thing you "need to get" to understand the power of vim and become advanced user overnight.
P.S. if you don't like vim because it's console based and want a modern text editor, then I suggest looking into Sublime Text editor, which is a great editor and also supports vim mode.
P.S.2. I also recommend to map Esc key to jj and kk, which makes things a lot easier.
You are wrong about "one editable line at the bottom of the screen." All the text in the window is editable. And it does scroll (all versions) and in the case of gvim, has scrollbars.
Maybe you inadvertently put it in "ex mode". This is easily done and can be confusing.
Another answer got me thinking that watching some skilled editing using vim would be pretty revealing so I dug up this video showing basic and more advance motions while coding. This person could get even a bit efficient using some marks, etc but it gives an idea.
http://www.youtube.com/watch?v=FcpQ7koECgk&feature=related
If you need inspiration or want to see someone who really knows what they are doing with Vim, check out Gary Bernhardt's String Calculator Kata In Python, look at him go! http://vimeo.com/8569257
I think they have a long and acceptable answer for your question on the viEmu hompage:
One other even more powerful example: let's take the 'ce' command, which is composed of 'c' and 'e'. The 'c'hange command deletes the range specified by the next motion command, and also enters insert mode. It's the same as 'd', but with the distinction that it enters insert mode, instead of staying in normal mode. The boon is that the text you type in the next (short) input session is also part of the command. So if you do 'ceHello>', what you do is replace from the cursor to the end of the word by 'Hello', and the '.' command afterwards will work exactly like that: replace up to the end of the word with 'Hello'.
From:
http://www.viemu.com/a-why-vi-vim.html
I have viEmu installed ~half year ago. But I have to say (maybe without strong linux experiences) I've never used it. Too alien, too far, too complex.
So IMHO viEmu it's a great technical&historical challenge but no more for the 95% of the developers.
Basically with Vi (or ViM) you get faster because you don't need to touch the mouse and the key-map is improved (this represent learning curve cost but worth the effort) for do any text manipulation in a very easy way once that the fundamentals are learned.
Top 10 things Vi user need to know about Vim
I have not experience with VS.Net but I guess it has the same features that any other IDE has.
I have found that learning the all the key commands of the editor in my IDE was a sufficient replacement for Vi. Things like renaming, indenting, formatting, moving lines and that kind of stuff.
So I guess the major win would be for someone who already know Vi to be productive without having to learn VS.Net.
But then again, Vi has some truly esoteric but powerful features that probably can't be matched by you standard IDE editor.
I think you really should give Vim a try.
If you quickly tried Vi ten years ago, I may understand you didn't appreciate it. It's not really user-friendly at first sight. Actually its real power is revealed when you start feeling comfortable with the movements and start making it your own with customisation.
Once Vim is familiar to you you may understand why it deserves to be learnt.
I actually use VS only for debugging these days. Coding with vim (real vim, not viemu) is just a better experience.
Now, I am not going to claim that using one over another makes any difference in productivity - after all I spend most of my time trying to figure out how to solve a problem - entering the code is the easy part.

Is it possible to disable command input in the toolbar search box?

In the Visual Studio toolbar, you can enter commands into the search box by prefixing them with a > symbol. Is there any way to disable this? I've never used the feature, and it's slightly annoying when trying to actually search for something that you know is prefixed by greater-than in the code. It's particularly annoying when you accidentally search for "> exit" and the IDE quits (I knew there was a line in the code that was something like if(counter > exitCount) so entered that search without thinking).
At the very least, can you escape the > symbol so that you can search for it? Prefixing with ^ doesn't seem to work.
This is a really cool feature. I've poked through the feature documentation, and the accompanying command list, and not a heck of a lot is showing up in terms of turning it off.
If you want to search for >exit, you could always type >Edit.Find >exit in the search box; that seems to do the trick. A bit verbose, though, but it really is an edge case.
you can enter commands into the search box by prefixing them with a > symbol.
Wow, I didn't know that. Where do I find the list of possible commands?
I never actually use the search box, I've remapped ctrl+F to incremental search, which is usually ctrl+I
I find this much cooler than the normal search - give it a go, you might end up not caring about the search box anymore.
Wow, I didn't know that. Where do I
find the list of possible commands?
The commands are the same as those you can enter in the command window, so you can pretty much drive the entire IDE and debugger using it. There are a load of predefined aliases for common commands. Open up the command window and enter alias for a list, to get you started.

Resources