Changing perspective: turn MacVim into a plugin
Rainer Schmid
the last days discussions started to allow MacVim to pull in plugins
(not vim plugins, but plugins based on shared libraries or bundles).
There is e.g. the discussion about using it to include a terminal in a
vim tab or split, or the discussion about the textmate project
feature.
I started wondering if we rather shouldn't do it the other way round,
i.e. make MacVim a plugin instead of enabling MacVim to pull in
plugins.
Apart from the fact that such a plugin could be used in arbitrary
programs that need editing, it could also be used in a "uber-MacVim",
i.e. a program with the main purpose to pull in the MacVim plugin (and
hence allows editing), but that also allows to pull in other plugins
(like the suggested terminal plugin).
By doing it this way, MacVim itself would stay "pure" (i.e. no
platform-specific extensions), but at the same time it would allow
(independent) implementations of all that cool stuff.
Rainer
Nico Weber
> I started wondering if we rather shouldn't do it the other way round,
> i.e. make MacVim a plugin instead of enabling MacVim to pull in
> plugins.
Could you be more specific? Which parts of MacVim would you add as a
plugin? Clearly, there needs to be some core functionality executing
the plugin stuff. I don't see lots of MacVim behaviour that could be
put in a plugin; it's mostly core functionality.
> Apart from the fact that such a plugin could be used in arbitrary
> programs that need editing,
You mean you want to make MacVim into a plugin you can plug into other
programs? That won't work in general, since there's no unified plugin
architecture that the other plugins support. You can, however, get
something close to this by using the "Edit in ODBEditor" input manager.
>
Confused,
Nico
Rainer Schmid
> > I started wondering if we rather shouldn't do it the other way round,
> > i.e. make MacVim a plugin instead of enabling MacVim to pull in
> > plugins.
>
> Could you be more specific? Which parts of MacVim would you add as a
> plugin? Clearly, there needs to be some core functionality executing
> the plugin stuff. I don't see lots of MacVim behaviour that could be
> put in a plugin; it's mostly core functionality.
Maybe the problem stems from the fact that the term "plugin" can be
used in various contexts. In my mail, the term "plugin" never referred
to vim plugins, but rather shared libraries that can be loaded by
other programs dynamically at runtime and the programs can communicate
over a standard interface (sometimes also referred to as "bundle", but
the term "bundle" is also overloaded with different meanings).
So in this respect, basically all of MacVim needs to be turned into a
plugin (i.e. the whole .app including all the resources, etc.). People
then could use the "MacVimView" class in their application and what
they get is a full-blown vim editor.
> > Apart from the fact that such a plugin could be used in arbitrary
> > programs that need editing,
>
> You mean you want to make MacVim into a plugin you can plug into other
> programs? That won't work in general, since there's no unified plugin
> architecture that the other plugins support. You can, however, get
> something close to this by using the "Edit in ODBEditor" input manager.
I know that it won't work in general. But people could add support it
explicitly in their programs (not sure how realistic this is, though).
The "Edit in ODBEditor" is something I already use, but the difference
would be that a plugin could be more like a drop in to the NSTextView
rather than editing in an external program.
I don't know how feasible this would be.
Rainer
Nico Weber
>>> programs that need editing,
>>
>> You mean you want to make MacVim into a plugin you can plug into
>> other
>> programs? That won't work in general, since there's no unified plugin
>> architecture that the other plugins support. You can, however, get
>> something close to this by using the "Edit in ODBEditor" input
>> manager.
>
> I know that it won't work in general. But people could add support it
> explicitly in their programs (not sure how realistic this is, though).
> The "Edit in ODBEditor" is something I already use, but the difference
> would be that a plugin could be more like a drop in to the NSTextView
> rather than editing in an external program.
>
> I don't know how feasible this would be.
I don't think it's feasible. It'd be a _lot_ of work, and you don't
really want a 7mb vim process for every single text input on your
system ;-)
Nico
Jjgod Jiang
On Fri, Feb 22, 2008 at 10:37 PM, Nico Weber <nicola...@gmx.de> wrote:
> I don't think it's feasible. It'd be a _lot_ of work, and you don't
> really want a 7mb vim process for every single text input on your
> system ;-)
I think we can adapt something like multi-tty for emacs [1], so that vim
can run as a server process, then every NSTextView sub-class instance
simply communicate it by NSConnection protocol. Of course it's not easy
but I think it's possible at least.
[1] http://lorentey.hu/project/emacs.html.hu
- Jiang
Nico Weber
> vim
> can run as a server process, then every NSTextView sub-class instance
> simply communicate it by NSConnection protocol. Of course it's not
> easy
> but I think it's possible at least.
And then you'd have a buffer for every text field? Then doing `:make`
in one textfield would freeze all other textfields.
And, as I said it's a lot of work. And I don't imagine many
applications would use this kind of plugin. And if this was done as an
InputManager hack that replaces nstextfields in general, it has to be
incredibly hacky and would break with each software upgrade.
To me this sounds like of the things that look good on paper but
aren't used in practice (and even if they are used, they don't work).
Enough stop energy already ;-)
Nico
George Harker
It seems like if the standard autocmd stuff could be hooked such that
an obj-c or c++ plugin got notifications like you would for an
autocmd, plus if there were sufficient (though minimal) hooks to add
panes / rollouts / drawers etc to the GUI, then it would be a great
addition.
I really like MacVim, and for many tasks, I think the standard vim
plugins suffice well. The area where they fall down IMHO in terms of
being good GUI citizens is their attempts to construct gui-like
interfaces using text in a split pane or tab.
For that, genuine native gui code seems to be better. It feels and looks nicer.
Ideally, you might end up with a plugin which presented vim commands
to MacVim allowing a nicer GUI etc to be constructed for filebrowsers
etc. That way existing browsers/ explorers could be adapted to have a
nicer GUI component and could operate in text mode like they always
have.
I know this isn't a simple thing to do, and plugin architectures are
always hard (plugins can crash the app, defining interfaces is hard
etc). But over time it would be a very nice thing to have.
Just my 5 cents.
Cheers
George
björn
So, if I understand you correctly, you are looking for a view class
(lets call it VimView) which you could just drop into your app in
interface builder much like what you can now do with NSTextView?
This could be possible to some extent, but it certainly would not be
easy. Also, since Vim is a program (and not a view), lots of Vim
functionality would be crippled (menus, toolbars, etc.). What happens
when you type ":q" in your view? That is just one example, but it
highlights my point: Vim is an application, not a view.
I did spend a fair amount of time thinking about this when I started
the MacVim project, but I always seemed to run into problems that I
could not come up with any elegant solutions for. Of course, that
does not imply that it is impossible but I leave that project to
somebody smarter/more optimistic (take your pick) than me.
To summarize: adding a "plugin architecture" to MacVim is something I
can wrap my head around (it will be difficult/time consuming enough),
making MacVim into a "plugin"
(or a view) is beyond me.
/Björn
björn
>
> Personally, I'd prefer to see a plugin architecture for vim.
>
> It seems like if the standard autocmd stuff could be hooked such that
> an obj-c or c++ plugin got notifications like you would for an
> autocmd, plus if there were sufficient (though minimal) hooks to add
> panes / rollouts / drawers etc to the GUI, then it would be a great
> addition.
>
> I really like MacVim, and for many tasks, I think the standard vim
> plugins suffice well. The area where they fall down IMHO in terms of
> being good GUI citizens is their attempts to construct gui-like
> interfaces using text in a split pane or tab.
>
> For that, genuine native gui code seems to be better. It feels and looks nicer.
>
> Ideally, you might end up with a plugin which presented vim commands
> to MacVim allowing a nicer GUI etc to be constructed for filebrowsers
> etc. That way existing browsers/ explorers could be adapted to have a
> nicer GUI component and could operate in text mode like they always
> have.
>
> I know this isn't a simple thing to do, and plugin architectures are
> always hard (plugins can crash the app, defining interfaces is hard
> etc). But over time it would be a very nice thing to have.
Like many other suggestions this sounds great to me...but, it is not
something I feel comfortable attempting to implement.
It sounds to me that you are suggesting a better way for Vim plugins
to "manipulate" the GUI. As such it really should be implemented for
_all_ platforms...and that's not going to be easy. :-(
Sure, we could do something like this only for MacVim but then I
really think we are straying away too far from Vim. (We'd have Vim
plugins that would only work on a Mac.)
I might have misunderstood your suggestion, but my idea for plugins
differs from yours in that it simply is "a way to add custom views to
a MacVim window" (more or less). As such, it has nothing to do with
Vim...it's just Cocoa (except for the fact that they'd be able to do
nifty things like evaluate Vim expressions with [MMVimController
evaluateVimExpression:] and modify the Vim state with [MMVimController
addVimInput:]). I've said it before, but I really do not want to
modify the Vim source at all, if possible.
/Björn
björn
>
> > I think we can adapt something like multi-tty for emacs [1], so that
> > vim
> > can run as a server process, then every NSTextView sub-class instance
> > simply communicate it by NSConnection protocol. Of course it's not
> > easy
> > but I think it's possible at least.
>
>
> And then you'd have a buffer for every text field? Then doing `:make`
> in one textfield would freeze all other textfields.
Exactly!
>
> And, as I said it's a lot of work. And I don't imagine many
> applications would use this kind of plugin. And if this was done as an
> InputManager hack that replaces nstextfields in general, it has to be
> incredibly hacky and would break with each software upgrade.
>
> To me this sounds like of the things that look good on paper but
> aren't used in practice (and even if they are used, they don't work).
Nico, you may sound negative sometimes but I have to agree. ;-)
/Björn
Jakub Piotr Cłapa
> To summarize: adding a "plugin architecture" to MacVim is something I
> can wrap my head around (it will be difficult/time consuming enough),
> making MacVim into a "plugin"
> (or a view) is beyond me.
There is something like this for Linux called pida[1]. It seems to use
GTK plugs and sockets to make an IDE with vim embeded as an editor. I
suppose this is something close to what the original poster had in mind.
Unfortunately I don't know whether such thing (embedding windows between
apps) is possible in Cocoa.
[1]: http://pida.co.uk/
--
regards,
Jakub Piotr Cłapa
Tim Allen
> I might have misunderstood your suggestion, but my idea for plugins
> differs from yours in that it simply is "a way to add custom views to
> a MacVim window" (more or less). As such, it has nothing to do with
> Vim...it's just Cocoa (except for the fact that they'd be able to do
> nifty things like evaluate Vim expressions with [MMVimController
> evaluateVimExpression:] and modify the Vim state with [MMVimController
> addVimInput:]). I've said it before, but I really do not want to
> modify the Vim source at all, if possible.
with the Python/Perl/Tcl/etc. bindings?
As I think someone eles mentioned, if that scripting language were F-
Script[1], then people could make Cocoa calls and build their own
extra windows and everything without further support.
[1]: http://www.fscript.org/
björn
I do not want to add support for another scripting language. Call me
stubborn, but all I want is loadable bundles (as in NSBundle) written
in Objective-C. That would be extremely powerful and would require
the least amount of work for me. I really want to avoid having to
learn a new scripting language (sorry for sounding like a broken
record).
/Björn
Morel David
Le 23 févr. 08 à 12:50, björn a écrit :
You could also say "Send me the patches". People usually shut the fuck
up when you do ;-)
D.Morel
travis
want it) and then submit the patch to trunk themselves, not MacVim
actually becoming a patch. That 7.1.242 that you see when you open up
Vim represents the version and patch number.
On Feb 27, 4:19 pm, wishi...@googlemail.com wrote:
> 1KDownload