I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/
Related
I've been struggling for 2 days to install some plugins which use python on Vim (Windows). Even with a stock vimrc.
Using the official vim 7.4 binary (x86)
I've checked that it comes with +python/dyn and +python3/dyn
I've installed Python 2.7.10 x86, and appended python's path in my Path environment.
:echo has('python') prints 1 as expected.
Yet: when I type :python print 'test', vim quits, just as if I've typed :q
:python mum tell me, why does windows exists?, it quits as well. Wondering why... Not a print issue at least.
Using tuxproject's nighty builds of vim 7.4.826 (x86)
It does come with +python/dyn and +python3/dyn. Also:
Used libraries: Perl 5.22.1, Python 2.7.10, Python 3.4.3, Ruby 2.2.3, Lua 5.3.0, Tcl 8.6.4, libXpm.
Great! That's the verison I've downloaded (2.7.10) ! Wait...
:echo has('python') prints 1 as expected.
But, "merry christmas!" says vim.
Sorry, this command is disabled, the Python's site module could not be loaded. Windows isn't good enough. Oh, and merry christmas!
Using tuxproject's nighty builds of vim 7.4.826 (x64)
I tried to use x64's python binary, taking care of removing the x86 version from my Path variable. Same issue as above.
Using Kaoriya's vim 7.4.something (x64) and Veegee's vim 7.4.803
Same issue as above.
What about compiling vim ?
Windows.
I'm not that lazy, well, yes I am... but I'll try to compile it if there isn't any other workaround. I don't really want to compile it if it won't solve anything. If only I could at least understand why these issues happen...
All right, I managed to solve the issue.
For those who may be interested, the intended python version was Python 2.7.9 and not 2.7.10. Installing Python 2.7.9 x86 (and x64) fixed everything for the corresponding vim version.
First of all, need to check for the python version compiled into the vim. One of the way is to edit the gvim executable (e.g. for window it's gvim.exe), and look for "python\d*.dll\c" as mentioned inside the vim manual. Nonetheless, when you run :echo has('python3') || has ('python'), it may give you the hint that vim cannot find and load python27.dll or python32.dll, so you can guess the python get compiled with vim in this way as well.
Once you have identified the python version needed, and if your python is installed on another location, then you can specify the pythonthreedll location to let vim to find it.
:set pythonthreedll=D:\installed\python\python35.dll
check again with following:
:echo has('python3')
I have this problem too but I didn't have to install previous versions.
All I do to solve this is just set PYTHONHOME=C:\Users\MYUSERNAME\Anaconda2 in my system environment variables!
You may have to adjust the location if you did not use Anaconda as a python installer.
Note: I use python 2.7.11 and 3.5 (Both of them are installed via Anaconda 64-bit)
PS. Please ensure that PYTHONHOME is typed correctly, no underscores. And it should point to the location of Python 2 only. Don't point to Python 3 folder.
PPS. It turns out that if you set PYTHONHOME, your working python3 command on the terminal will crash, so I do not suggest this anymore.
It may be trivial question, but I'm looking over the internet and SO about namei in macos. I can't find it on Yosemite, also homebrew doesn't contains such package to install. From what I was searching, MacPorts doesn't have it neither. Could some pro developers from MacOs help me or suggest other command that will be able to check for ownership and permissions on a path?
I'm writing this as an answer vs. a comment although I will make a comment first and that is, this doesn't appear to be a question suited to this forum and you might want to ask elsewhere, e.g. Super User.
That said, namei is a part of the util-linux package and as such is not a command normally found under OS X. If it's even possible, you have to download the source code for util-linux and then selectively compile namei and then manually install namei by itself as you would not want to compile and install the entire util-linux package under OS X. I've done similar under OS X with individual utilities of the GNU Core Utilities package however not with the util-linux package.
I have Mac Pro, with OS X 10.9.4 (can't upgrade to Yosemite yet), and I'm trying to build vim7.4 with gui-support, or get any kind of gui-support. My current vim is version 7.3, I'm guessing, that's the default vim that ships with macs. I have the Terminal.app and iTerm2.app, my vim rc has the default
set term=xterm-256colors
or what have you.
What I have so far:
macvim
The colors look great, basically it's the same setup I had on my ubuntu system, but it's really annoying that it opens a new window. Is there a way to get it to open within my terminal? (not launch it from the terminal, open inside of it)
As I've said I have the regular vim7.3
And while I can use color-schemes, they look like garbage compared to my ubuntu system. I suppose this must be due to gui-support option? I tried, CSApprox but that gives me a weird error.
So I decided to simply build vim 7.4 and enable gui support, but I get random errors.
My basic config make looks like:
./configure --enable-gui=yes
make
At which point it complains about missing header file etc. , I figured this should not be that hard.
Any tips?
The basics of what I'm trying to do is:
Have a vim version installed with gui-support, or a work-around where my colors are all screwed up.
Thanks!
Building Vim on Mac OS X is a waste of time.
Step 1: Download the appropriate MacVim build from here.
Step 2: Put MacVim.app into the /Applications/ directory.
Step 3: Put the bundled mvim script somewhere in your PATH.
Done.
To run MacVim in your shell:
$ mvim -v filename
To run MacVim from your shell:
$ mvim filename
Building Vim with GUI on macOS using Homebrew:
brew edit vim.
Add a new line with option for GUI:
option "enable-gui", "Enable GUI mode"
Change from no to yes in the following line:
opts << "--enable-gui=no"
Install or re-install vim:
brew reinstall vim --enable-gui
Troubleshooting:
If you've errors related to Python 3, see: vim's GH-2754.
Checkout new Homebrew PR at GH-25785 with above patch.
I'm in trouble to make flyspell to work in emacs. I'm a Mac user, but I'm not using Aquamacs, which seems to provide this facility by default.
Starting new Ispell process [/usr/local/bin/aspell::default] ...
ispell-init-process: Error: No word lists can be found for the language "en_US".
The error message is trying to tell you that Emacs started the external program aspell in a subprocess, which is good, but that it couldn't find its dictionary file, which is bad.
Try typing M-x ispell-change-dictionary RET SPC to see if there are any dictionary files that Emacs knows about, and select one of them.
If that doesn't work, then there is something wrong with your installation of flyspell. What to try next depends on the version of Emacs you are using (the terminal version that comes with OS X, a newer terminal version installed via Homebrew or MacPorts, the Cocoa version, or Aquamacs). On my machine, for example, I am running Cocoa Emacs 24 under Snow Leopard, and flyspell.el comes preinstalled, but to actually get it to work I had to install the aspell package using Homebrew (which provided the aspell executable and its dictionary files). Can you give us more information about your environment (OS X version, Emacs version, etc.)?
hey i am new to the macports thing as i recently switched to the mac. as i was thinking of developing some applications in my mac i wanted all the usual gnu and opensource tools i need. but i had a small confusion. i was installing git with macports and i noticied it installed a lot of packages like Perl that i already have in my machne. so i was thinking won't there be any conflicts and how does one know which version is used. the macports one or the apple one?
MacPorts installs all of its ports into /opt/local (or whatever prefix you configured it with, but it's /opt/local by default). It installs its own copies of Perl, Python, etc., so that the MacPorts install is standardized, and to avoid conflicts (Apple-supplied versions of some programs like Perl and Python, and some libraries, often lag far behind the latest versions of those tools).
When you install MacPorts, it automatically prepends /opt/local/bin to your $PATH variable (you can change this by editing your shell configuration file), so if you call perl, etc., you'll get the MacPorts version. However, the Apple-supplied versions will still be intact and unchanged, and other programs that rely on those versions will not be affected, either.
There shouldn't be any conflicts, since MacPorts installs all of its programs under a completely separate directory hierarchy in /opt/local/.
If you have multiple versions of software installed (e.g. the default OS X Perl and MacPorts' Perl), then it depends on the order of directories in your $PATH environment variable. MacPorts typically sets itself up with its bin directories earlier in your path, so saying perl at the command line will invoke the MacPorts Perl, not the OS X Perl.
MacPorts installs its own dependencies in the /opt/local tree (you can change this default when you build MacPorts) because its packagers then have a known quantity to test against. In some cases there is a system package for a given dependency that will let you use the system-installed version, but that's actually pretty rare. System vs. MacPort versions are chosen according to whichever comes first on the PATH (for executables) or the linker path(s) for dynamic libraries. Use your standard development tools' options to select the appropriate libraries to link against and you should be fine.