Jjgod Jiang wrote:
> On Fri, Nov 28, 2008 at 11:37 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > I'm still a bit in doubt what to plan for the core Vim code. The MacVim > > project is also making a lot of progress. And some Mac code is too old > > and buggy. > > That's what I have been thinking for quite a long time. And I believe > MacVim developers are also considering this. Let me explain the > situation in a more detailed manner (Björn et. al., correct me if I'm > wrong), so that more people can see what's going on: Thanks for writing down the overview. > 1. Do we still need to maintain the old (Carbon) code? > > As you can see, the Carbon code (gui_mac.c) was developed between Mac OS > 10.0 to 10.2 age, with the hope of supporting both Mac OS Classic and Mac OS > X. It's not a bad implementation at that time. But as time goes by, the > system environment and application framework provided by Apple have been > changed greatly (Apple is a company embracing for change). Though Apple > is striving to maintain compatibility since then (that's why the carbon > code still builds and runs, and works more or less), but as we are towards > 64-bit and Snow Leopard, Carbon will be dropped eventually. So there is no > good way to revive the old carbon code without completely rewrite it with > Cocoa (that's what we have been doing since 2007). > > In my opinion, to avoid confusion and give more Mac-vimmers a better > experience, the original Carbon code should be freezed and only to be > used for pre-10.4 systems. For Tiger and Leopard (and the upcoming Snow > Leopard), a Cocoa-based implementation should be chosen as the default > GUI. OK, so we keep the Carbon code, but stop working on it. If someone finds a problem, we'll ask him to try the Cocoa code. If he is on OS 10.2 or 10.3 that won't be possible. I guess we are assuming there are few people in this situation. This would also mean I remove Mac items from the todo list. Perhaps moving to the Mac help files as "known problems". > 2. Is MacVim/vim-cocoa ready to be integrated? > > From the user experience perspect, both of them are stable enough and > used by many people. In fact, MacVim is becoming the "de facto" option > for most vim users newly come to Mac. > > Part of the code base of MacVim or vim-cocoa may be Mac OS X 10.5 only, > but I believe in general, Björn and me are working hard to maintain > 10.4 compatibility. > > So both of them are ready. Or soon to be ready if not. > > 3. What's the rock blocking this integration? > > The rock, I believe, is the development model vim currently used. It's > a completely "cathedral" like model, in which sources are updated > iteratively patch by patch. > > However, the development of MacVim (and vim-cocoa sometimes) is done > in a much higher traffic way with central git repository maintained > by Björn (or me, for vim-cocoa case) and several private repositories > maintained by other developers. New releases are tagged from the > central git repo and binaries are built from the tag. > > While I'm not trying to argue which model is better, I simply don't > see any easy way for us to integrate the source of MacVim or vim-cocoa > and keep the vim core tree updated, since all changes must be sent out > by you, in a patch by patch manner. The git approach is definitely > more friendly for regular changes since both MacVim and vim-cocoa are > actively developing. > > Besides, some parts of MacVim/vim-cocoa sources contain binary resource > files (images, nibs, etc.), so there is no way to use regular patches > to update them. > > 4. So far, here is the situation we're facing. Suggestions are welcomed, > since personally I'm really eager to see a bright future of vim/mac > development! I think the main point here is that the Cocoa version is constantcly being improved, by multiple people. Taking a snapshot and including that in the main Vim branch will have the effect of being outdated in two weeks. Since work on the core code is mostly done by me I don't see a good reason to change the development model. This code is used on all platforms, we can't force people to use specific tools. What we have now works nearly everywhere (also VMS). Trying to include the Cocoa code into the main code every one or two weeks looks pointless. I don't see what we gain with this. It's just extra work. So, following this line of thought it would be better to keep the MacVim and vim-cocoa available separatly. We can tell people where to download it. I don't need to "bless" changes in that code, so it also saves me time. A potential problem for this method is that I make changes in the main code that make it difficult to merge back with the Mac version. It's potential, because I haven't heard of such a problem happening yet. And the two parts of the source code are nearly completely separate. Only when I change the interface between the core and the various GUI implementations there could be a problem. This will happen infrequently and most likely will not be much work (e.g., changing tab page labels). -- A vacation is a period of travel during which you find that you took twice as many clothes and half as much money as you needed. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
