I changed my job and now I have a Macbook for working I configured Iterm2 with zsh and almost everything is working, but certain shortcuts aren't, one of the most used by me every day "alt+backspace" to delete a word before a special character appears, I tried a lot of things with the Hexa code an so on, in most cases it is almost working, but it deletes the entire line
Example :
ls /tmp/file1
With alt+ backspace this will delete the complete text /tmp/file1 while on Linux it will just delete file1
Is there some way to configure Iterm2 to have the same behaviour than in Linux for this shortcut ?
I tried things like this
https://jorge.fbarr.net/2018/06/08/iterm-and-altbackspace/
But it's not working as in Linux.
This is what helped me. Option key should send ESC+ sequences and all will work fine.
And I have no idea what is "normal"
Related
i have Vim with plugin vim-go and neocomplete, when o move the cursor from left to right in insert mode this happens
Note: this only happens with go code and vim-go required binaries (such as gocode, godef, goimports, etc..)
someone have same problem?
i am running Ubuntu 14.04.2 LTS 64bits with Kernel 3.13.0-48 Vim 7.4.52 with lua support
thanks in advance
It looks as if you are using gnome-terminal or konsole.
When you use cursor-keys to move around in insert-mode, the keys send escape sequences. In particular, if you happen to press the shift- or control-keys, those can send different escape sequences (with numbers), possibly with semicolons to separate the numbers. There are some limitations on vim's handling strings of that sort, and in some cases (see this discussion) it will get confused and stop interpreting the string, leaving junk on the screen.
The root of the problem is that in vi, the program (mis)uses the escape character for two different reasons:
a special "command" character sent by the user to the editor
the first character in the strings sent by most special keys to an application (including an editor).
The latter requires the program (vim) to wait "a while" to determine which case to use. If you are using a slow machine (or a slow connection) and your keyboard-repeat is fast, that defeats vim's attempt to distinguish the two cases. Likewise, your plugins send many characters to the screen for each keystroke, making vim slower.
It is aggravated by modified keys (using shift- or control-modifiers) since xterm and other terminals encode that information as a number. gnome-terminal and konsole use an older variant of xterm's (see xterm FAQ How can I use shift- or control-modifiers?) which is more easily mistaken by vim as not being an escape sequence.
If it is only a matter of timing, then moving your cursor more slowly would avoid the problem (agreeing that is only a workaround). You can gauge the amount of output done by vim by running it in script to capture the output into a typescript file. I do that to analyze bugs, by sending the data back to the terminal more slowly. Some of those typescript files are surprisingly large, for the little apparent work done.
I changed from neocomplete to YouCompleteMe, the random characters is not showing anymore.
I have a couple files that were recently edited on windows and via Cpanel's file editor and now show up double spaced (as in an extra line CR/LF between each line). Vim is telling me (via :set ff?) the file format is unix (and I'm working on a Mac). If I show special characters via :set list all the lines just end in $. I tried setting the format via :e ++ff=mac which appears to remove all line breaks in the currently edited document and when I write the file and re-open it's back to being double spaced. I also tried searching and replacing ^M and various \r\n combinations. I know I'm missing something simple but can someone shed some light on what is going on? Is this even a line ending issue?
It appears to be a line ending issue.
The Vim wiki has this to say on the subject:
http://vim.wikia.com/wiki/File_format#Terminator_after_last_line
I, however, for expediency, when faced with a line ending problem, use BBEdit on my Mac to change them to Unix (I share, on the LAN, my eight Linux boxes with a Macbook Pro so I use a directory in Dropbox to transfer files across. scp will do the same job).
Unless you have a copy of BBEdit lying about, you can download Barebones's free Text Wrangler & it'll do the same job. Only works on a Mac obviously...
Simply put, I know you can do ctrl+v+tab to insert a physically real tab character in a bash statement. But how do I do the same for iTerm?
The answer was to hit control+v, then tab afterwards, not all together! Hope this helps someone.
It's not iTerm, but your shell that affects how you''re able to insert a tab.
First, make sure you're in BASH shell: Type the following command:
$ echo $RANDOM $BASH_VERSINFO
23714 3
The first is a random number, and the second should be the BASH Version number. If you get a blank line or just a random number, you're not in the BASH shell, and that's probably one of your issues.
Another thing is to execute this command:
$ set -o
allexport off
braceexpand on
emacs on
errexit off
errtrace off
[...]
privileged off
verbose off
vi off
trace off
The two lines of interest is the emacs and the vi lines. One of those should be on. If they're both off, you can't do the Ctrl-V-Tab to insert a tab character.
When the vi mode is on, it should be Ctrl-V-Tab like you said. With emacs mode on, it is either Ctrl-V-tab, or possibly Ctrl-Q-tab.
However, this isn't an iTerm thing, this is your shell that's doing it.
If by a "physically real tab character" you mean sending the tab hex code (0x09) to the shell, then you can do this in iTerm by pressing Ctrl + Tab (⌃ ⇥).
This is the default setting, although you can change it (as well as add other hex code values to send) in iTerm > Preferences > Profiles > Keys.
I'm not certain why you're comparing a "bash statement" with iTerm. You write bash scripts in iTerm. Which means, assuming you're writing your scripts in iTerm, you're already doing what you want.
I'll assume you mean scripting in vi vs command line. The way I get literal characters on the command line is by using vi editing mode. Do set -o vi. Then you can use ctrl+v followed by tab in the manner that you're used to.
IMO, using vi editing mode comes with a slew of other pluses like searching your history, faster navigation, etc. So you could just add it to your .bashrc if you wanted and use it all the time.
One should also try Ctl + V Ctl + I. It is working in konsole where Ctl+V+Tab deosn't work.
I use zsh and have the Emacs keybindings set up for it. I'd love to have it replicate all my regular Emacs text manipulation commands. One which I miss is the Kill/Yank keys. It would be nice if I could select text (using C-SPC - this works) and then do something like a kill-region (C-w - This right now deletes the previous word). The yank (C-y) works fine and I can even even cycle through them using M-y.
Does anyone have such a setup working?
A simple "\C-w": kill-region in my .inputrc file binds the key to the function I want.
Update: Spoke too soon. The above only does it for applications that use the readline libraries. Zsh uses its own zle. The way to configure similar behaviour is to stick bindkey "\C-w" kill-region into your .zshrc
Smething just happened in the last 20 minutes or so to my vim. I must have hit something, but I can't figure it out, and nothing will get it back to the 'real' behaviour.
I've always used : to jump to a line number. Now, when I hit : then a number - (1-9), vim instead goes in to "insert" mode and inserts a letter. (1=q, 2=r, 3=s, 4=t, 5=w, etc.)
Trying to search around for this is worse than looking for a needle in a haystack!
Any ideas as to what sort of secret "mode" I've enabled? And better yet, how I might get back to normality?
Thanks!
Not sure what you've done there but you can also jump to a specific line number by entering the line number and then hitting G (Shift+g).
Shift+g on its own will take you to the last line of the file.
It could be your shell and not VIM. If restarting VIM doesn't fix your problem, try opening a new shell and using VIM there. If nothing works, move your .vimrc file and any shell start ups out of the way (by renaming, not deleting, of course), open a new shell, and VIM. If that doesn't work, try a new keyboard. :-(
Closing and opening vim should reset whatever you funky mode you've discovered. If not, you've got something profoundly weird going on -- vim doesn't store settings that are turned on while in the file.
BTW, you're totally ruining my "vim doesn't break" meme.
Well, I've no idea what it was, but rebooting the computer - Macbook running leopard - seemed to work.
I'd tried new shells to no effect. I just didn't want to have to reboot.
See - macs have problems too! :(
Thanks for all the quick responses from all y'all. Hopefully I won't have to figure that one out again.