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

Re: MacVim plugin patch

Expand Messages
  • Matt Tolton
    ... I was thinking that the object we handed the plugin would have some kind of addDrawer method. Are you saying we should just give the plugin a reference to
    Message 1 of 34 , Apr 1 11:43 AM
    View Source
    • 0 Attachment
      > > > - Possibility of having plug-ins in floating panels? Plug-ins in drawers?
      > >
      > > I think that these are the best way to present plugins. I think that
      > > plugins should be allowed to create floating panels as well as new
      > > windows (I'm not sure we actually have to do anything special to allow
      > > this) and to add drawers to vim windows.
      >
      > No, you wouldn't have to do anything special at all. A plug-in could
      > create any number of windows/panels and it can access all visible
      > windows via NSApp.

      I was thinking that the object we handed the plugin would have some
      kind of addDrawer method. Are you saying we should just give the
      plugin a reference to the window and let them add a drawer on their
      own? Or should we help facilitate this somehow?

      > > > - Plug-in persistence: automatically save/load plug-in layout? Save plug-in
      > > > layout in "workspace" files?
      > >
      > > Hmm...it doesn't seem like this is really necessary... do you have a
      > > use case in mind for this?
      >
      > Well, if you load a plug-in and then quit MacVim should that plug-in
      > automatically load when you restart? E.g. a plug-in that lives in a
      > drawer...should it open that drawer when you restart or do you have to
      > go through the process of loading that plug-in manually each time you
      > restart MacVim?
      >
      > What if you want a "drawer plug-in" loaded for one window and no others?

      Ok I see what you're saying. I don't think that this is necessary.
      If a plugin wants to save some state, I think it should do it on its
      own.

      > >
      > > Basically I see the plugin architecture going something like this:
      > > - We load a bundle and obtain a reference to the principal class. We
      > > call some class method on this to initialize the bundle. When we do
      > > this we pass it an object that can be used to do things like add menu
      > > items, get a current list of the vim windows, subscribe to certain
      > > application wide notifications (like when the active vim window
      > > changes).
      >
      > Ok, that sounds good...it would be good if plug-ins communicate with
      > MacVim via this one object. Plug-ins should not know anything about
      > the internals of MacVim so that it can change without having to change
      > the plug-ins. (Maybe that is obvious, but...)

      Agreed.

      > > - Every time we create a new instance of MMVimController, we
      > > instantiate an object of the bundle's principal class. When we
      > > initialize this object, we give it some object that it can interact
      > > with (that is specific to that MMVimController) which will allow it to
      > > do things such as add a drawer to the vim window, send input to vim,
      > > subscribe to notifications for that particular vim instance (like when
      > > a new tab is selected).
      >
      > It seems to me that some plug-ins might only want their principal
      > class to be instantiated once...I have no concrete example, but it
      > seems natural to have a separation between plug-ins that are
      > instantiated once and those that are instantiated each time a new Vim
      > process connects.

      I was basically thinking the informal principal class protocol would
      include something like this:

      + (BOOL) initializePluginWithController:(MMPluginController*)controller;
      + (void) terminatePlugin;
      - (id) initWithInstanceController:(MMPluginInstanceController*)controller;

      If a plugin is "application scoped", then it just will not implement
      the initWithInstanceController selector and we won't instantiate one
      for each instance. The plugin can then do all of its initialization
      stuff in the initializePluginWithController method.

      Does this seem ok?

      >
      > Notifications should be easy enough using Cocoa's notification system.
      >

      What notifications do you think are necessary? All that I can think
      of are things like "tab changed" and "tab closed" notifications.
      However, this may not be necessary...see below.

      >
      > >
      > > Some questions I have:
      > > - How do you think we should handle plugins adding menu items? Right
      > > now it seems like all of the menus are controlled entirely by vim. Do
      > > we want to add a single menu that plugins are allowed to add menu
      > > items to? Do we want to allow them to create entire menus of their
      > > own?
      >
      > This is simply not possible at the moment. One of the first thing I
      > will work on when I get my new Mac is to clean up the menu system. My
      > intentions are to allow menu items to be added from within MacVim
      > without involving Vim, thus plug-ins could add menu items easily. A
      > separate plug-in menu may not be too bad either. Either way, you can
      > hack something together temporarily, or you can wait for me to fix
      > this (which won't happen for another month).

      Yeah...I was looking at the code that handles this. It shouldn't be
      -too- bad to tweak it a little bit to allow for a plugin menu.

      >
      >
      > > - Do we want to provide a way to communicate with a specific plugin
      > > from within vim?
      >
      > No. Vim should not be aware of any MacVim plug-in stuff.

      The scenario that I was thinking about was a plugin that would like to
      be notified of certain vim events. It could set up an autocmd in that
      vim instance to send a message to itself when something occurred (like
      a tab was closed, or changed, or a new buffer was created, etc)

      >
      >
      > By the way, plug-ins should be allowed to interact with Vim processes
      > the same way clients can interact with a server (in Vim's
      > client/server scheme): by evaluating expressions [MMVimController
      > evaluateVimExpression:], and by sending input [MMVimController
      > addVimInput:]. You will have to come up with suggestions on how they
      > can interact with MacVim (as you define the protocols for this)...I
      > haven't given this much thought.

      Got it.

      >
      >
      > Anyway, I've got a better idea of what you're aiming to implement and
      > I think it seems good. You should probably go ahead and make a fork
      > of MacVim.git and start working on it. If you have questions or want
      > comments on ideas then I'd be glad to help out, otherwise I will
      > simply look at your code as it progresses and give you comments then.
      > My only wish is that you try to separate the plug-in code from "core
      > MacVim" as much as possible: "core MacVim" must in no way depend on
      > the plug-in code, and the plug-in code should depend on "core MacVim"

      Ok will do.

      > as little as possible. (Also, I humbly ask you emulate the MacVim
      > coding style as much as possible.)

      Of course!

      Matt

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Stefan Eletzhofer
      Hi, ... Ok, fine with me. ... Sure. I meant that we should provide some sort of very basic example plugin, which cocoa-dumb people like me can use as template
      Message 34 of 34 , Apr 3 2:41 AM
      View Source
      • 0 Attachment
        Hi,


        Am 02.04.2008 um 19:58 schrieb "Matt Tolton" <matt@...>:

        >
        >>
        >> Once I'm home again I'll sit down and think and code that -- if
        >> there's a git repo I can clone from. And some example plugin, perhaps
        >> one which just does an alert box (hint hint).
        >
        > I'll put this up in a git repo at some point. As of now I am just
        > working in a local branch. If you want I can send out a patch that
        > you can apply against the main repo.
        >

        Ok, fine with me.

        > As for a plugin which shows an alert box...I don't think we need to
        > provide this functionality (showing alert boxes) as you can just
        > directly use an NSAlert can't you?
        >

        Sure. I meant that we should provide some sort of very basic example
        plugin, which cocoa-dumb people like me can use as template :)

        Stefan

        > Matt
        >
        > >

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      Your message has been successfully submitted and would be delivered to recipients shortly.