Loading ...
Sorry, an error occurred while loading the content.

12375Re: MacVim cocoa plugins

Expand Messages
  • Nathan Ramella
    May 28, 2011
    • 0 Attachment
      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

      -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
    • Show all 15 messages in this topic