On May 28, 2011, at 4:53 AM, björn wrote: > On 26 May 2011 17:15, Nathan Ramella wrote: >> >> I stumbled upon Matt Tolton's plugin work in one of the earlier >> branches and managed to get things working - but it took a fair amount >> of digging. >> ...(clipped).. >> Matt's example FileExplorer plugin is great and I can easily imagine >> others that could be written if the plugin code was easily available >> and had higher visibility. >> >> It would appear that the plugin code is absent from the latest tree, >> what can I do to get it back in place? I'm willing to put some time >> into this. > > Unfortunately I now think that having this type of plugin code is a > bad idea and I do not wish to reinstate it. > > There are a few reasons for this, the main one being that it is unsafe > and difficult to communicate with the Vim process from within the GUI. > The general principle of MacVim is that all state must be inside the > Vim process; the GUI should only deal with presentation. However, > synchronous querying of state is something that should be avoided, so > there is no easy way to figure out what the Vim process is up to > inside the GUI short of pushing state from the Vim process to the GUI. > > The plugin architecture you refer to lives entirely inside the GUI > process, so it suffers from the difficulties above. The only way I > see to resolving this is to design an API that lets you get access to > all the state that a plugin could ever wish to take an interest in. I > believe this is a major task which simply is not worth the effort (and > the complexity of it is not appealing to me). > > Instead of providing a very general plugin architecture I think it is > better to focus on very specific features and try to implement these > in a way that is scriptable from Vim. Examples of such features that > already exist are menus and the toolbar. Another work in progress is > a file browser. I envision that the file browser will essentially be > a view that displays hierarchical data and that what goes into this > view will be scriptable from within Vim. This way it can be used for > browsing files, or tags, or ... > > I hope that gives some explanation as to why I am opposed to a general > (Cocoa) plugin architecture. > > Björn >
I do agree with you in terms of the difficulty pushing state back and forth. I was considering the netbeans interface for this task - abstracting the plugin manager as a communications multiplexer using the existing communication mechanisms, but at the same time leveraging the message passing in obj-c. But, I can appreciate your position and the fact that you took the time to explain it. Thanks for all the good work in making MacVim available! -Nathan Ramella -- You received this message from the "vim_mac" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
