back
26 comments
Hmmm. Why not MacVim: https://code.google.com/p/macvim/ ?
This looks like it's a plugin to macvim; or at least a fork of it.
for those wondering what this is it's a proof of concept vim gui based on a embeddable macvimframework (mainly based on bjorn winklers macvim)[1]

it's great to see so much work on vim/neovim lately. while not related to the macvimframework idea, the author of ultisnips lately chimed in on the issue tracker of neovim. i think the end result of the discussion was that thiago was working on json-rpc now, wanted to implement a has('neovim') feature and move the python code running in an external thread. i can't find the issue right now.

i'm getting more and more annoyed with osx though. a cold boot on my 8gb macbook air has about 3gb of resident memory. redraws are extremely slow. iterm while much faster than terminal, is still just a textview which is slow, causing a lot of annoying flicker in vim terminal. it's gotten so annoying for me that i actually have a heavily patched dwm(i used to run awesome, but that's just annoying to setup in osx) with dwb browser, pidgin(yes, sadly otr in osx won't be fixed until adium 2.0 comes out, whenever that will be). and just general cmus/newsbeuter/mutt etc.

so why not just run linux on the macbook? if linux had a half decent gui toolkit that was as easy to use as cocoa(no not gtk) we wouldn't to switch to osx or windows all the time for utility applications.

[1] https://github.com/qvacua/macvim

Just on a few points:

- Using all available memory for buffer cache is a good thing, as long as the OS can immediately drop it if there are more urgent uses for the memory.

- I haven't used iTerm very much, but and because Terminal has always seemed snappier. I'm surprised you had the opposite experience.

Does he mean to include buffers? On linux, the term "resident memory" refers to memory that is explicitly not buffer cache. Or does OSX use this term differently?

One day, we may be able to use the same RAM terms across all major OSs.

i think people are waiting on wayland to go public IMO.
I know I am (sticking with OS X until Wayland is mature enough).

There is no guarantee that Wayland is what Linux needs to persuade me to ditch OS X, but I'm certainly eager to try it out (when it is mature enough).

For anyone interested in Vim-like editors with Mac UI, I suggest trying Vico – https://github.com/vicoapp/vico

It is completely native, supports TextMate bundles and is scriptable using Lisp dialect.

I feel like I need to make the obligitory comment. If you want an editor that is scriptable with Lisp and supports Textmate bundles, and Vim keybindings; Emacs[0] + Evil mode[1] (Extensible Vi layer, it's great) + Yasnippet[2] (Yet annother snippet library, has textmate bundles).

I switched from vim to this setup a while ago and have to say I've been very happy with it. I like the advantage of having a full language to use and find the environment more customisable (maybe just because I never got fully comfortable with VimScript. That being said, I still use vim for quickly editing single files as you can't beat the startup time.

[0] http://www.gnu.org/software/emacs/

[1] https://gitorious.org/evil/pages/Home

[2] https://github.com/capitaomorte/yasnippet

"That being said, I still use vim for quickly editing single files as you can't beat the startup time."

Add (server-start) to your .emacs and keep a running emacs around long-term. Then you can edit single files quickly with emacsclient -t.

Yeah, good point, I actually have:

  alias e='TERM=xterm-256color emacsclient -t'
  alias ec='emacsclient -c'
  alias ed='emacs --daemon'
in my .zshrc to do just that but for some reason I use vim anyway, due to it's omnipresence on every server box I go into and I suppose muscle memory of typing vim whatever_file_i_want_to_edit .
And even alias 'emacsclient -t' to 'vim' in shell, to keep one's existing habits of CLI editing.
Vico is amazing, I'm currently working on contributing to it. Highly recommended, and it's simple to build too. Go get the version from GitHub, it's now open source and managed by the community.
Yes, agreed Vico is quite excellent.
One of the key benefits of VIM is that it is available on so many platforms. So commands and plugins are useful on OS X, Linux and even Windows.
what's wrong with vim in a terminal? I've never understood the appeal of a GUI based vim clone
The main reason I use gvim is for better looking fonts and more colors.
Also, gvim has more potential keybindings available than vim running in a terminal.
Still not convinced. I'll take tmux and a non-gui vim any day of the week.
Agreed, the ability to ^z out of the the editor into the shell to quickly run a command is a killer feature for me. True colors or a slicker ui would be nice but they're not critical to my work.
These kinds of projects are neat, but the reason I use vim on OS X is because it's the same editor I use on my FreeBSD server, and the same editor on all my Linux boxen at work. I'm used to it, and the experience is consistent.

I appreciate the attempt to make vim a better experience on Macs, but it comes at the detriment of being the identical experience across all platforms I use.

The name made me think it was about the vim plugin, vim-R for statistical programming. https://github.com/vim-scripts/Vim-R-plugin
Why would you put this under a different license than Vim itself?
And GPL3 at that...smh
not sure but why this appeared in front page, i dont see anything special on it.
It has"mac", "vim", "redefine" and "experience" in the title.