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

Re: Integration with Eclim

Expand Messages
  • Nicholas Clark
    I ve done some more considerable digging around in docs but I haven t gotten around to actually doing any code testing. Here s what I have found so far: -
    Message 1 of 11 , Feb 15, 2010
    • 0 Attachment
      I've done some more considerable digging around in docs but I haven't
      gotten around to actually doing any code testing. Here's what I have
      found so far:

      - Currently Eclim uses reflection to find fields on the
      current 'view' that is to house the vim instance. These fields
      evidently come directly from the local platform API. If this is
      correct, then finding the OS X equivalent will at least get us this
      number. According to this page [1] , possible candidates would be
      windowHandle, windowNum, or windowRef.

      - The other piece of the puzzle, then would be take this
      number in MacVim, and bind to the window it returns, possibly using a
      method signature similar to the one here [2].

      This would all have to assume that two things, neither of which I
      know:

      1. That the id retrievable from Eclim, is a window ID.
      2. NSApplication windowWithWindowId: can retrieve a
      window from anywhere, even outside of the same app.
      3. That you could reparent MacVim to this retreived window
      instead of the default NSApplication.

      Unfortunately I don't see this being possible, since most likely the
      only Id we could get in Eclim would be maybe a NSView(although
      documentation does not list such an id). Also, Id have to agree with
      Ben in saying that this probably would not be the "Mac" way. I started
      out hoping we could just do a reparenting operation, but I haven't
      programmed in Cocoa enough to see this limitation.



      [1] http://www.gnu.org/software/gnustep/resources/documentation/Developer/Gui/Reference/NSWindow.html#method$NSWindow-windowHandle
      [2]
      http://developer.apple.com/Mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/doc/uid/20000012-DontLinkElementID_103

      --
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Ben Schmidt
      ... I think this second part is likely to be where a different approach is needed. Looking at the Internet Plug-Ins docs [3], windowRef is a good candidate for
      Message 2 of 11 , Feb 16, 2010
      • 0 Attachment
        On 16/02/10 1:38 PM, Nicholas Clark wrote:
        > I've done some more considerable digging around in docs but I haven't
        > gotten around to actually doing any code testing. Here's what I have
        > found so far:
        >
        > - Currently Eclim uses reflection to find fields on the
        > current 'view' that is to house the vim instance. These fields
        > evidently come directly from the local platform API. If this is
        > correct, then finding the OS X equivalent will at least get us this
        > number. According to this page [1] , possible candidates would be
        > windowHandle, windowNum, or windowRef.
        >
        > - The other piece of the puzzle, then would be take this
        > number in MacVim, and bind to the window it returns, possibly using a
        > method signature similar to the one here [2].

        I think this second part is likely to be where a different approach is
        needed. Looking at the Internet Plug-Ins docs [3], windowRef is a good
        candidate for being able to make this work, treating MacVim like a kind
        of 'out of process' plugin using the Netscape API. If Eclipse is truly
        Cocoa, though, perhaps even the WebKit Plug-In API is a possibility,
        which would probably be easier.

        So I think this fits firmly in the 'possible but difficult' category.

        Ben.



        [1]
        http://www.gnu.org/software/gnustep/resources/documentation/Developer/Gui/Reference/NSWindow.html#method$NSWindow-windowHandle
        [2]
        http://developer.apple.com/Mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/doc/uid/20000012-DontLinkElementID_103
        [3]
        http://developer.apple.com/mac/library/documentation/InternetWeb/Conceptual/WebKit_PluginProgTopic/WebKitPluginTopics.html




        --
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
      • Nico Weber
        ... Maybe something like that can be hacked together using IOSurfaces on OS X = 10.6. Nico -- You received this message from the vim_mac maillist. For more
        Message 3 of 11 , Feb 16, 2010
        • 0 Attachment
          > As far as I can tell there is some kind of feature in gtk that allows
          > you to embed a "view" from one app in another (how does this work? do
          > both apps have to be running simultaneously?). To my knowledge there
          > is no similar technology in Cocoa

          Maybe something like that can be hacked together using IOSurfaces on
          OS X >= 10.6.

          Nico

          --
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
        • björn
          ... Actually (I only just realized), MacVim is already ready for the kind of situation you are after...although it will require substantial amounts of code
          Message 4 of 11 , Feb 19, 2010
          • 0 Attachment
            On 16 February 2010 03:38, Nicholas Clark wrote:
            > I've done some more considerable digging around in docs but I haven't
            > gotten around to actually doing any code testing. Here's what I have
            > found so far:
            >
            > -         Currently Eclim uses reflection to find fields on the
            > current 'view' that is to house the vim instance. These fields
            > evidently come directly from the local platform API. If this is
            > correct, then finding the OS X equivalent will at least get us this
            > number. According to this page [1] , possible candidates would be
            > windowHandle, windowNum, or windowRef.
            >
            > -         The other piece of the puzzle, then would be take this
            > number in MacVim, and bind to the window it returns, possibly using a
            > method signature similar to the one here [2].
            >
            > This would all have to assume that two things, neither of which I
            > know:
            >
            > 1.       That the id retrievable from Eclim, is a window ID.
            > 2.       NSApplication windowWithWindowId:        can retrieve a
            > window from anywhere, even outside of the same app.
            > 3.       That you could reparent MacVim to this retreived window
            > instead of the default NSApplication.
            >
            > Unfortunately I don't see this being possible, since most likely the
            > only Id we could get in Eclim would be maybe a NSView(although
            > documentation does not list such an id). Also, Id have to agree with
            > Ben in saying that this probably would not be the "Mac" way. I started
            > out hoping we could just do a reparenting operation, but I haven't
            > programmed in Cocoa enough to see this limitation.

            Actually (I only just realized), MacVim is already "ready" for the
            kind of situation you are after...although it will require substantial
            amounts of code added to whichever program you want to embed a Vim
            view in. Basically, MacVim.app is such an app already: Vim processes
            run in the background and send output to MacVim.app to display inside
            an NSView.

            This is (more or less) what you need to do:

            1. Inside -[MMBackend connection] you need to pass the name of the
            connection you want to connect to (this is using Distributed Objects
            so you might need to read up on that). At the moment it always
            connects to the same connection (based on the path of MacVim.app).
            You'll want to be able to pass the connection name as a parameter to
            Vim (analogous to the --socketid parameter for gtk). Your GUI app
            will have to register this name (look at -[MMAppController init]).

            2. Copy all the relevant code from MacVim.app into your app
            (MMVimController/MMVimView/MMWindowController/and many more...). This
            will require a lot of code to be imported into your app and in order
            to modify it to suit your app you'll need to get to know the source
            code intimately (although the source code is fairly well abstracted
            into different modules so it is far from impossible). The biggest
            hurdle will be picking out the "right" bits of code from
            MMAppController.


            I'm not saying that this is a good solution, but at least it is
            possible to embed Vim in whatever app you wish using this method.
            Maybe in some distant future I'll come up with a good way of
            modularizing the MacVim code so that it will be possible to simply
            pull some sort of MacVim.framework into another app and be done, but
            the keyword is _distant_ here. ;-)

            Björn

            --
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
          • Steven Michalske
            ... Me dreams of vim in xcode! Make that framework commercially acceptable please! -- You received this message from the vim_mac maillist. For more
            Message 5 of 11 , Feb 22, 2010
            • 0 Attachment
              On Feb 19, 2010, at 5:24 PM, björn wrote:

              > I'm not saying that this is a good solution, but at least it is
              > possible to embed Vim in whatever app you wish using this method.
              > Maybe in some distant future I'll come up with a good way of
              > modularizing the MacVim code so that it will be possible to simply
              > pull some sort of MacVim.framework into another app and be done, but
              > the keyword is _distant_ here. ;-)

              Me dreams of vim in xcode!

              Make that framework commercially acceptable please!

              --
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
            • björn
              ... What is less likely? a) that I actually write such a framework or b) that the the Xcode devs would add a Vim view feature if such a framework existed My
              Message 6 of 11 , Feb 23, 2010
              • 0 Attachment
                On 22 February 2010 20:20, Steven Michalske wrote:
                >
                > On Feb 19, 2010, at 5:24 PM, björn wrote:
                >
                >> I'm not saying that this is a good solution, but at least it is
                >> possible to embed Vim in whatever app you wish using this method.
                >> Maybe in some distant future I'll come up with a good way of
                >> modularizing the MacVim code so that it will be possible to simply
                >> pull some sort of MacVim.framework into another app and be done, but
                >> the keyword is _distant_ here. ;-)
                >
                > Me dreams of vim in xcode!
                >
                > Make that framework commercially acceptable please!

                What is less likely?

                a) that I actually write such a framework

                or

                b) that the the Xcode devs would add a "Vim view" feature if such a
                framework existed

                My estimate is that (a) has about 1 chance in [enter arbitrarily large
                number here] to ever happen, but that it still is likelier than (b).
                ;-)

                Björn

                --
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
              • Christopher S Martin
                ... Hash: SHA1 ... I actually have Xcode set up to use MacVim as the external editor. With the cocoa.vim bundle it s surprisingly good. The AutoComplete isn t
                Message 7 of 11 , Feb 23, 2010
                • 0 Attachment
                  -----BEGIN PGP SIGNED MESSAGE-----
                  Hash: SHA1

                  On Tue, Feb 23, 2010 at 12:18 PM, björn wrote:
                  > On 22 February 2010 20:20, Steven Michalske wrote:
                  >>
                  >> On Feb 19, 2010, at 5:24 PM, björn wrote:
                  >>
                  >>> I'm not saying that this is a good solution, but at least it is
                  >>> possible to embed Vim in whatever app you wish using this method.
                  >>> Maybe in some distant future I'll come up with a good way of
                  >>> modularizing the MacVim code so that it will be possible to simply
                  >>> pull some sort of MacVim.framework into another app and be done, but
                  >>> the keyword is _distant_ here. ;-)
                  >>
                  >> Me dreams of vim in xcode!
                  >>
                  >> Make that framework commercially acceptable please!
                  >
                  > What is less likely?
                  >
                  > a) that I actually write such a framework
                  >
                  > or
                  >
                  > b) that the the Xcode devs would add a "Vim view" feature if such a
                  > framework existed
                  >
                  > My estimate is that (a) has about 1 chance in [enter arbitrarily large
                  > number here] to ever happen, but that it still is likelier than (b).
                  > ;-)
                  >
                  > Björn
                  >

                  I actually have Xcode set up to use MacVim as the external editor.
                  With the cocoa.vim bundle it's surprisingly good. The AutoComplete
                  isn't as robust as in normal Xcode, but it gets the job done. I'll
                  take my muscle memory vim movements with "good enough" autocomplete
                  any day of the week. Add in the snipMate vim bundle (written by the
                  same guy) and you have an almost perfect environment.



                  -----BEGIN PGP SIGNATURE-----
                  Version: GnuPG v1.4.10 (MingW32)
                  Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

                  iEUEARECAAYFAkuERusACgkQFA24T+fkP2sDEQCdEKk8Qa2NXqsLDOm7MngtdZL0
                  HHwAmMvwQV86rhL3M6HY3uED+fVYZw4=
                  =bJyu
                  -----END PGP SIGNATURE-----

                  --
                  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.