I'm trying to save a macro to the file I'm editing.
All goes well until I close and reopen the file. When I reopen the file, the pasted macro
<80><fc>^B Setup^M<80>
has become
■üSetup^M■
I assume this is encoding related but it's beyond me on how to resolve it.
Following are some settings that might be relevant:
fileformat=dos
fileformats=dos,unix
fileencoding=latin1
fileencodings=ucs-bom,utf-8,latin1
encoding=utf-8
Does anyone have an idea what I need to change to make it work?
Edit
I had no idea where the <80><fc>^B sequence was coming from.
It appears to be inserted into the macro when I type //***** Setup with the SHIFT key pressed up until the S from setup. The macro gets pasted as //*****<80><fc>^B Setup
Note 1: I use an Azerty keyboard. For the keys / and *, I need to press the shift key.
Note 2: A solution is to not hold the SHIFT key when typing the space character between //***** and Setup. Holding the shift key mearly has become an automatism when typing that pretty much used sequence.
you are using the gui with -W option? Then read that question. It is really related to it.
Related
When I'm in insert mode in vim and I use the arrow keys, it sends what seems like a letter and a carriage return. For example, pressing ↑ it sends:
A
It looks like A\n but I'm not sure exactly what characters/codes it's sending. Why does this occur, and is there a way to disable this?
The usual sequence sent by a terminal for the Up arrow is <Esc>OA or ^[OA (the ^[ sequence represents the <Esc> key, also equivalent to Ctrl+[.)
If your Vim fails to recognize this sequence as the Up arrow, it will end up executing this sequence: <Esc> which will leave Insert mode and go to Normal mode, then O to insert a new line above the current one and go to Insert mode, then insert a literal A since you'd be in Insert mode again.
You can confirm that this is indeed the sequence your terminal is sending Vim by typing Ctrl+V followed by the Up arrow in Insert mode. (Ctrl+V in Insert mode inserts the next character literally.) I'd expect you'd see the ^[OA sequence inserted.
Then you can check what your Vim thinks the sequence for the Up arrow is with the :set <Up> command. I'd expect you'd see something like:
t_ku <Up> ^[OA
(t_ku is the internal name for the setting corresponding to this Up arrow key. You can also use :set termcap to see all Vim settings related to the terminal, including the special key codes.)
If either of these don't match the expectations, that would explain why your Vim is not recognizing the Up arrow key. (One alternative explanation is that 'ttimeoutlen' is set too short, but I'd say that's highly unlikely.)
These settings are usually managed by the 'term' setting. By default, it's set based on whatever you have for $TERM on your shell outside of Vim.
You can start by looking at what Vim thinks 'term' is, and where it's set from:
:verbose set term?
term=screen-256color
Last set from ~/.vimrc line 100
The :verbose part asks Vim to tell you where it's set from, so you'll see if your vimrc or one of your plug-ins is overwriting it. If Vim shows none of that, it means it's coming from the $TERM variable in your shell.
So look at what $TERM is set to outside of Vim and see if that seems to be correct or not. Are you setting that explicitly somewhere? Be it one of the shell's initialization files or perhaps from your terminal emulator itself?
Also possibly relevant whether you're using tmux or screen, in which case you should double check that $TERM is also set correctly both inside tmux or screen, but also outside it.
Hopefully all these hints should lead you in the right direction fixing this. If you can't figure out, post your findings as comments on this answer and I'll update it with more specific fixes you can try.
You're probably in vi compatibility mode. try :set nocompatible
If that makes it function as you would like, put set nocompatible at the top of your vimrc file to get it to default to this behavior.
In vim, to find a character you can use 'f' to find the next matching character in the line that your cursor is on, and 'F' to find the previous matching character in the line that your cursor is on.
Is there a way to move around like that on the bash command line?
I know that you can set bash to be in vim mode, by saying set -o vim, and this works great for my local machine, but I administer a lot of machines where I can't change that setting.
Ignoring for a moment the security issues associated with everybody in your office sharing the same user, you could add a key binding to the readline command character-search:
# ~/.inputrc
C-]: character-search
To use the search, type Ctrl-] followed by the character you want to search for. You can bind the command to any key sequence, not just Ctrl-], but for obvious reasons you probably don't want to emulate vi mode by binding it to the letter f.
This would be less invasive than turning on vi mode so most users would probably not even notice the change. However, somebody could easily stumble upon your key sequence by accident and become very confused. You would also have to use three keystrokes instead of the two you're accustomed to with vi.
Xcode's auto-completion is often getting in my way by giving me argument placeholders when I already have them. Here's an example:
I want to change that second MoveToPoint to AddLineToPoint, so I delete part of the name, and hit control + space for the Show Completions command. I get something like:
You see the annoyance. I tab complete the name, but now I have to delete the 3 arguments, the commas, and the parentheses. This kind of thing annoys me and throws off my flow when writing code.
Ideally I'd like a way to delete these placeholders with one command, or have a separate auto-complete command, so along with Show Completions (control + space), I could bind something like Show Completions without Placeholders. Does anyone know how to do that?
XCode does support this actually. They call it "Select Previous Completion". Check it out here (under Code Sense).
You essentially just hit ⌃> (hold control and press >) for XCode to choose your previous completion. It think it only works well though if the new method you're calling takes the same number of arguments as the previous one.
Hope this helps
For some reason, I cannot jump forward with <C-I>; gives me the error beep. <C-O> works just fine.
I don't see any remapping going on either. Any ideas what might be the problem?
I'm using vim 7.3 on win7
EDIT: I just found out <C-I> does the same as %! I still can't figure out how to fix it though.
Why does having <TAB> mapped affect <C-I>? The short answer is, "historical reasons", dating from even before the original 'vi'.
The ASCII code for <TAB> is 9, same as <CTRL-I>. Since terminals receive their input encoded in ASCII, they can't tell whether that "TAB" signal came from the actual <TAB> key, or from the user holding CTRL and pressing I. Since Vim was originally written to run on terminals, it can't tell the difference either.
A couple of other pairs of indistinguishable keys are <C-M> with <Return>, and <C-[> with <Esc>.
It's possible there's some arcane way to tell the difference between the two (more likely if you're using GVim), but if there is, I don't know it. As a workaround, you could use nnoremap <SomeOtherKey> <C-I> to give <C-I>'s original function to some other key.
I found a fix for the problem, but I don't know why it works..
I had <TAB> mapped to %. By removing this, <C-I> works as normal.
Any idea why this works...?
I am trying to use the a macro in xcode.
I type in a then hit escape and select it.
This is annoying because I have to hit page up 5 times to get to the a.
Is there a different key combination that will just let me use the a as typed without having to select it?
Have you changed your XCode defaults? I'm using 3.1.4 and I don't have to hit page up. Here are my exact key presses:
a
escape
enter
I can also hit escape first and start typing the macro name.
Edit: Argh! Your demon has infiltrated my XCode! ;) If I auto-complete some things, they become sticky as the new starting "a" macro--I can't even backspace and type "a" to use the first "a" macro. Each file has it's own persistent memory too, so switching files changes the default. Using a method or property or any other parsed symbol seems to have priority over the macros so the default will never go back to the initial "a" macro once you auto-complete a parsed symbol.
Pretty weird bug. I must not have seen it because I don't use macros much.
The only way I found to fix this is to change the "a" macro to some other auto-complete such as "ai". That way when you type "a" "escape", typing "i" next will select the macro you want even if there's a bad sticky default.
Start with this reference http://mcdevzone.com/2009/04/09/useful-xcode-tricks/
Then edit "~/Library/Application Support/Developer/Shared/Xcode/Specifications/TextMacros.xctxtmacro/Contents/Resources/ObjectiveC.xctxtmacro" and change the "CompletionPrefix = a;" to some other prefix.
When you restart XCode, the new prefix will work in place of the old "a" macro.