12375Re: MacVim cocoa plugins
- May 28, 2011On May 28, 2011, at 4:53 AM, björn wrote:
> On 26 May 2011 17:15, Nathan Ramella wrote:I do agree with you in terms of the difficulty pushing state back
>> 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.
>> 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.
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
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
- << Previous post in topic Next post in topic >>