This is happening because the OS's vi is ahead of Homebrew vi in the PATH.
While you could fix it by putting /usr/local/bin ahead of /usr/bin in the PATH, that would be a security hole since Homebrew gives ownership of that directory to your user. That permission change from the macOS default means that even an extremely unsophisticated malware could use ...
There is a nice implementation of NeoVim GUI for macOS named VimR (R = Refined). It has a native file manager and works fine and fast with mouse gestures and macOS UI. VimR comes with a command line tool vimr. VimR repository is more active and has more stars comparing to neovim-dot-app.
This is not possible. In the terminal, no key code is generated for modifiers alone.
Gvim also has no support for this, partly because there is no valid way to represent the key using the map commands.
vimdiff as well as the other binaries are just symbolic links to the actual vim binary. This is done because when vim starts up it checks under which name it has been started and does perform some extras (like running diff mode for vimdiff, starting the gui for gvim, or just starting in read-only mode for view or starting in ex mode for ex).
So in short the ...
There are few thing you can do to solve this. Homebrew compiled Huge version, while default Vim is in Normal version. Huge adds for example clipboard and more mouse/terminal support. This makes selecting with mouse actually select in Vim (so changes to Visual mode) instead of doing selection on terminal layer.
Having that said, you can:
press "+y or "*y in ...
From your .vimrc:
set " <- HERE
This set command must be causing it.
Looks like during initialization Vim
dumps output to terminal, but you don't see it until
Vim is closed. I get similar behaviour if I put stray set to my .vimrc
file (although I do need to press enter to skip the output, but this must ...
It looks like gruvbox sets italic on by default for the Comment syntax group if you're running terminal vim, which is a big problem if the terminal does not support italics. iTerm does but you have to get a specific termcap to enable it.
But it looks gruvbox recently fixed this issue. So, simply update your gruvbox colorscheme and the issue should be fixed.
Under OS X, it's best to use MacVim. OS X behaves differently to other operating systems when it comes to things like clipboard management. MacVim is specifically designed to address the areas where Vim falls short on the Mac.
Coming to a terminal near you
Although MacVim runs as a GUI (like GVim) by default, you can use MacVim in the terminal ...
Basically when you paste using cmd + V, it is just throwing the content of the macOS clipboard at vim. It is just like typing each character that is in the clipboard literally into vim. That sometimes works, but often it doesn't. So the use is discouraged.
For this purpose there is the "* and "+ registers which use the system clipboard and paste the content ...
I had exactly the same problem when trying to get vimtex working with Skim. That is, I had vim 8 installed with --with-client-server (showing as +clientserver) and XQuartz running but --servername option was just ignored.
The solution for me was setting DISPLAY:
After that everything worked exactly as it should.
Edit: help x11-...
If you are seeing a similar issue and using Windows Terminal jump down to the "Update" below.
Seeing <ESC> used as the LHS of a key mapping causes me some discomfort. You've demonstrated one reason why...it doesn't seem to work right in a vimrc file. It doesn't matter what you have on the RHS, the LHS <ESC> causes some characters (maybe ...
Since I don't have enough points to make a comment and i have seen --with-override-system-vi a ton of times I hope this helps someone else. Options were removed from brew - [github]: https://github.com/Homebrew/homebrew-core/issues/41128
I ended up switching to neovim https://neovim.io/
Steps if you want to do the same.
brew install neovim
In my .zshrc ...
mvim is a shell script which uses the name it's run as to decide what to do:
# Next, peek at the name used to invoke this script, and set options
# GUI mode, implies forking
case "$name" in m*|g*|rm*|rg*) gui=true ;; esac
This is not uncommon. Vim itself reacts differently on whether it is invoked as vim, ...
For the first situation (tex selection to PDF) if you have a tex compiler that allows for input from stdin you could echo your visual selection.
function! EchoPipeCmd(cmd) range
echo system('echo ' . shellescape(join(getline(a:firstline, a:lastline), "\n")) . ' | ' . a:cmd)
command! -range=% -nargs=+ EchoPipeCmd :<line1>,<line2>...
Looking at the keycodes, towards the end of the table is:
<M-...> alt-key or meta-key meta alt <M-
<A-...> same as <M-...> <A-
<D-...> command-key (Macintosh only) <D-
Combinations would look like <D-M-x>.
Though I don't think a combination of modifiers alone can ...
It seems that was a bug in the version of vim-airline I had. Following the posts instructions on how to debug my vimrc, I commented out the plugins and everything worked ok. So I started commenting out one by one each plugin, and when i did so in vim-airline it bugged again. So i found out how to update my plugins (i use Vundle as a plugin manager, so
Got an answer on the vim_use Google group. It came down to priorities, and which vimrc is being used. For MacVim, there's a .gvimrc as well as a .vimrc file, and the .gvimrc file was overriding the .vimrc settings. Once I copied the .vimrc file to .gvimrc with the following changes in particular, I got the same view:
set tabstop=4 softtabstop=0 expandtab ...
There are special keys <k0> to <k9> and <kPlus>, <kMinus>, <kDivide>, <kMultiply>, <kEnter>, and <kPoint>, which can be mapped separately, e.g.,
inoremap <k0> Zero
inoremap <k1> One
I checked this with GVim running on Windows 7; the behavior on macOS might be different.
The problem is that you have updated your plugins in the transition Linux to Mac. This also brings a major update of Vimtex, in which the syntax plugin has been included as part of Vimtex. Part of the syntax script changes are to simplify the math zones.
The exact issue you raise is discussed here, and this comment should provide the required change, ...
Yes, this is possible. However, the answer depends on the choice of PDF viewer, and it is not necessarily straightforward.
In order to enable such synchronization, you must enable synctex.
Due to the complexity of the answer, I will instead refer you to my LaTeX plugin vimtex, which has implemented such synchronization support for several PDF viewers. More ...
Looks like the only NeoVim GUI for Mac OS X at the moment is Neovim.app. It installs a script called gnvim which behaves just like good old gvim, starting a GUI version and accepting all the parameters (but see 'vim_diff.txt' for details on changed, missing and removed features.)
The following function is a start; it will probably fail on a number of cases. You can build off it:
function! MyMap (...)
let l:i = 0
if a:0 > 2
let l:opt = a:1
let l:i += 1
let l:key = a:000[i]
let l:action = a:000[i+1]
let l:mod = 'A'
let l:mod = 'D'
echo 'nnoremap' ...
Opt-Left and Opt-Right already do what you want by default, as well as Alt-Backspace.
Cmd-Left and Cmd-Right are mapped to <Home> and <End> by default. You can remap them to do whatever you want:
inoremap <D-Left> <C-o>g0
inoremap <D-Right> <C-o>g$
nnoremap <D-Left> g0
nnoremap <D-Right> g$
You can use fn to bypass Mouse Reporting for programs like vim. (i.e. do fn+left-mouse button to clear the selection.)
(If you are not using a Mac and you are having a similar issue, you can use ctrl-z to suspend vim. Once you are done doing whatever, execute the ...
Quoting from Bram:
I assume you are talking about the command line, or entering search.
Yes, it's intentional that the line break does not work like pressing
Enter. The idea is that you are pasting text, not a command. You are
supposed to view the text before deciding to execute it. The thread
that started it mentioned that the source of the text ...
Sorry, it's because I set :set ambiwidth=double. It makes some characters twice as wide as usual. I set :set ambiwidth=single, and all is fine. This line, I must have copied from some stranger's vimrc and did not examine closely. It's my fault, not Vim's fault.
I have no idea what ambiwidth is for. Maybe there is some font that need it to display right (see ...