Hi Bram & Matt, On Sat, Nov 29, 2008 at 3:37 AM, Matt Tolton <[EMAIL PROTECTED]> wrote: > Out of curiosity, why not do this as a patch to MacVim, rather than a > completely different app? That way you get all of the nice features > that MacVim has as well as the core text rendering. :)
This question has been answered several times on this list, but not very thoroughly, thus I'm trying to answer it again, here: Basically, the biggest reason I still continue developing vim-cocoa is it's architectured differently from top to bottom with MacVim. vim-cocoa uses a single process approach, aka. build the Cocoa GUI code and vim core into a single binary, then package it into an app bundle. Each instance of vim-cocoa corresponds to a separate process and all GUI code access the structure of vim core via memory access. In contrast, Björn decided to develop MacVim in a 1-to-n process mode, aka. the MacVim app bundle has one MacVim binary in charge for all GUI operations, while the vim binary only contain a very small amount of Mac OS X code, used for exchanging messages with the GUI part. When a new vim window is created, the GUI part will fork a new vim process and connect to it with NSConnection. Thus, if the GUI part need to access any structure within vim core, it has to receive messages from vim process and interpret it. The chief advantage of this approach is it can support multiple vim windows within one MacVim instance. The "MacVim"-way is a smart approach, and implemented beautifully well by Björn. However, I still prefer my own way, there are several reasons for that: 1. It's done by myself :) So It's easier for me to coordinate with other code (I can decide when to sync with upstream source and when to merge). 2. The "shared memory" approach made accessing/exchanging infor- mation with vim much easier, so new features can be added in a easier manner (say, the ballooneval feature and netbeans support I'm considering to implement) 3. It also simplified debugging, I think. 4. Some people think vim-cocoa performs better than MacVim, though I don't think that's the main issue, Björn and other MacVim developers have done several excellent optimizations to it, so even there is speed difference between vim-cocoa and MacVim, it won't be sufficient to make most users decide which to use (after all, most users still prefered the "feature rich" one) In general, it's not that I don't like MacVim, I like it and I'm willing to make improvements on it, but when experimenting with new features, I still prefer to use vim-cocoa as my test bad. It turns out to be a simple, fast and surprisingly stable implement- ation, that's why I like it so much. Speaking of making contributions to MacVim, I'm definitely delighted to port the good features from vim-cocoa to MacVim, so that they can be used by more vimmers. Actually, the Core Text switching is inspired by patches Björn sent me quite a while ago (ATSUI renderer is fast and stable, works pretty well for both Tiger and Leopard, however, it has some limitations on edge cases), Björn already did a working Core Text implementation (for MacVim) and ask me if we can make it work for both Tiger and Leopard (by using some "degraded" approach to replace CT). Core Text is a new beast, not many people have used it and not many experiences have been told. So when I finally have some time to hack on this issue recently, I decided first make this experiment on vim-cocoa to see if it goes well. Then, after I tweaked it well enough, I'll able to work with Björn and integrate it back to MacVim (hopefully, finally replace the ATSUI renderer and traditional renderer). Looks like this email is long enough, I'll write another email about my thoughts on the integration of vim on mac (to respond Bram's question). - Jiang --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
