> Yes, that makes sense. Reading that I got confused by your choice of
> names; is MMPluginController the "mediator object" (in my
> terminology)? If so I think it should be called something with
> "mediator" or something similar in it since a controller usually is
> something else. (The book "Design Patterns" by Gamma et al. may have
> a better term than "mediator" for it.)
Ah Mediator is definitely a better name...I was trying to think of
something better than Controller. Thanks.
> > 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)
> Maybe it would be a better idea to investigate how hard it would be to
> put hooks inside the Vim code which forwards Vim events to MacVim and
> then you can use notifications inside MacVim to enable plug-ins to
> listen to these (or simply pass the events to the plug-ins). This
> requires a bit of extra glue-code, but I've been forced to do similar
> things already so it's not too bad (and it might come in handy for
> "core MacVim" as well).
> I still maintain that Vim should remain completely ignorant of plug-in
> stuff, otherwise you'll break the tenet that MacVim (and Vim) should
> not depend on plug-in code in any way.
Hmm...ok. I'll look into this.
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php