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

Re: [ANN] MacVim.app Google code page

Expand Messages
  • Jeremy Conlin
    ... I just wanted to say it looks very nice! I haven t downloaded it yet, but it looks great from the screenshots. I can t wait to try it out. Jeremy
    Message 1 of 17 , Jul 25, 2007
      On 7/25/07, bjorn.winckler <bjorn.winckler@...> wrote:
      >
      > I am happy to announce MacVim.app - a new port of Vim to Mac OS X.
      > This is a project I have been working on for almost a year now and it
      > is finally in such a state that I believe it might be usable for
      > others than just me.
      >
      > The goal of MacVim is to look better and integrate more seamlessly
      > with the Mac than the existing Carbon port of Vim. Its main features
      > are:
      >
      > - Multiple windows (Exposé works with the MacVim windows)
      > - Safari-style tabs (using PSMTabBarControl from Positive Spin Media)
      > - Toolbar
      >
      > I will be adding things as time goes on, but for now I would like some
      > people to test it out and focus on getting rid of all bugs that are
      > sure to be discovered.
      >
      > Go to http://code.google.com/p/macvim/ to download the latest
      > snapshot. Source code is also available to download, but please note
      > that it only works to build the GUI and not Vim itself at the moment.
      > Build instructions are available on the project page.
      >
      > So far MacVim has only been tested by me on my iBook G4, so I am not
      > even sure if it will run on an Intel (the snapshot is a univeral
      > binary though). Before running the snapshot, please take the time to
      > gloss over the README that comes with it.
      >
      >
      > Have fun with MacVim and please let me know if (how) it works for you,
      > Björn Winckler
      >
      >
      > >
      >

      I just wanted to say it looks very nice! I haven't downloaded it yet,
      but it looks great from the screenshots. I can't wait to try it out.

      Jeremy

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Niklas Lindström
      Hi Björn! I as well find this very promising; great work! I hope that you can continue this, and that your and Jiangs efforts (which I also applaud) will be
      Message 2 of 17 , Jul 26, 2007
        Hi Björn!

        I as well find this very promising; great work! I hope that you can
        continue this, and that your and Jiangs efforts (which I also applaud)
        will be possible to coordinate/integrate in some way.

        > As for the multi-window feature: each window runs its own Vim process. So
        > each time you open a new window MacVim uses NSTask to execute
        > MacVim.app/Contents/MacOS/Vim, which is just your regular Vim. Then I've
        > set it up so the GUI and Vim communicates via Mach ports. Effectively, you
        > are running several instances of Vim but it is all coordinated by the one
        > GUI app. Obviously, this is a solution that might not work that well in the
        > end, but for me it has been good so far.

        I can only speak for myself, but I actually find this very good. As
        long as gvim itself doesn't support multiple GUI windows, I think that
        this is more sound. And for that matter, I wouldn't need multiple
        windows; I use multiple vim windows and tabs combined, and I feel this
        is perfect. I often have several vim instances running with different
        sessions and settings altogether. Your solution makes it all work much
        better in the OS X environment without changing these premises.

        As for tabs. Your solution looks very good indeed, and I like that
        they are draggable. I really like Nico Webers' slide drawer
        implementation *a lot* as well though. If at all possible, how about
        something along the lines of a 'tabmode' option to control this? I
        guess that's not in the near future, but just to suggest it.

        Again, thanks for this!

        Best regards,
        Niklas

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... This might not come as a big surprise...but this is exactly how I want Vim to behave as well, and I dislike the idea of having several instances of the
        Message 3 of 17 , Jul 26, 2007
          > As for the multi-window feature: each window runs its own Vim process.  So
          > each time you open a new window MacVim uses NSTask to execute
          > MacVim.app/Contents/MacOS/Vim, which is just your regular Vim.  Then I've
          > set it up so the GUI and Vim communicates via Mach ports.  Effectively, you
          > are running several instances of Vim but it is all coordinated by the one
          > GUI app.  Obviously, this is a solution that might not work that well in the
          > end, but for me it has been good so far.

          I can only speak for myself, but I actually find this very good. As
          long as gvim itself doesn't support multiple GUI windows, I think that
          this is more sound. And for that matter, I wouldn't need multiple
          windows; I use multiple vim windows and tabs combined, and I feel this
          is perfect. I often have several vim instances running with different
          sessions and settings altogether. Your solution makes it all work much
          better in the OS X environment without changing these premises.

          This might not come as a big surprise...but this is exactly how I want Vim to behave as well, and I dislike the idea of having several instances of the same app running with several copies of the same icon cluttering up the dock.  Apparently, this is the only 'unique' feature of MacVim at the moment, and I am anxious to see how it will work out in the long run.  I'm glad you like it.

          As for tabs. Your solution looks very good indeed, and I like that
          they are draggable. I really like Nico Webers' slide drawer
          implementation *a lot* as well though. If at all possible, how about
          something along the lines of a 'tabmode' option to control this? I
          guess that's not in the near future, but just to suggest it.

          Thank John Pannell at positivespinmedia.com for the tabs...I only used his framework.  :)

          As for Nico's slide drawer;  I have not used this myself, but I can see how it makes sense in that you'll be able to see a lot more "tabs" at once.  It would be easy enough to abstract the tab code slightly to allow the user to choose how tabs are rendered, but yeah, not right now.


          /Björn


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---

        • Nico Weber
          ... Of course it s right to have only one instance of vim. I just hoped that you had added support for several top level gui frames ( windows how you normally
          Message 4 of 17 , Jul 26, 2007
            > This might not come as a big surprise...but this is exactly how I
            > want Vim to behave as well, and I dislike the idea of having
            > several instances of the same app running with several copies of
            > the same icon cluttering up the dock. Apparently, this is the only
            > 'unique' feature of MacVim at the moment, and I am anxious to see
            > how it will work out in the long run. I'm glad you like it.

            Of course it's right to have only one instance of vim. I just hoped
            that you had added support for several top level gui frames
            ("windows" how you normally call them, but that term is taken in vim
            already) to core vim -- that's something I've been doing some (very
            little) work on (needs less memory, completion works accross windows,
            etc.. Perhaps I can finish it one day. Until then, your way of doing
            this is very nice.
            >
            > As for Nico's slide drawer; I have not used this myself, but I can
            > see how it makes sense in that you'll be able to see a lot more
            > "tabs" at once. It would be easy enough to abstract the tab code
            > slightly to allow the user to choose how tabs are rendered, but
            > yeah, not right now.

            Maybe have a "taboverflow" behaviour that switches from the tabs-at-
            the-top to drawer-style tabs if more than X tabs are open. But not
            right now :-)

            Nico



            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bram Moolenaar
            ... I think we can discuss about the tab label implementation forever. It s a personal choice. Would it be possible to make this an option somehow? Or would
            Message 5 of 17 , Jul 26, 2007
              Niklas Linström wrote:

              > As for tabs. Your solution looks very good indeed, and I like that
              > they are draggable. I really like Nico Webers' slide drawer
              > implementation *a lot* as well though. If at all possible, how about
              > something along the lines of a 'tabmode' option to control this? I
              > guess that's not in the near future, but just to suggest it.

              I think we can discuss about the tab label implementation forever. It's
              a personal choice. Would it be possible to make this an option somehow?
              Or would that be too complicated, implementing both. It could be an
              option that is only used the moment the GUI is started and can't be
              changed later.

              --
              You have the right to remain silent. Anything you say will be
              misquoted, then used against you.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Nico Weber
              ... IMO we should have a taboverflow option with the values nodrawer , draweronoverflow and alwaysdrawer (well, or similar), that controls which tab
              Message 6 of 17 , Jul 26, 2007
                > I think we can discuss about the tab label implementation forever.
                > It's
                > a personal choice. Would it be possible to make this an option
                > somehow?
                > Or would that be too complicated, implementing both. It could be an
                > option that is only used the moment the GUI is started and can't be
                > changed later.

                IMO we should have a "taboverflow" option with the values "nodrawer",
                "draweronoverflow" and "alwaysdrawer" (well, or similar), that
                controls which tab style is used based on how many tabs are currently
                open. This should be changable at runtime.

                But as Bjorn said, not now. I guess I'd have to reimplement the
                drawer in Cocoa anyways.

                Nico


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... I would say having both tabs & drawer is quite feasible, but to make it nice would require some work. Adding a hack that will let you choose between the
                Message 7 of 17 , Jul 27, 2007
                  > > I think we can discuss about the tab label implementation forever.
                  > > It's
                  > > a personal choice. Would it be possible to make this an option
                  > > somehow?
                  > > Or would that be too complicated, implementing both. It could be an
                  > > option that is only used the moment the GUI is started and can't be
                  > > changed later.
                  >
                  > IMO we should have a "taboverflow" option with the values "nodrawer",
                  > "draweronoverflow" and "alwaysdrawer" (well, or similar), that
                  > controls which tab style is used based on how many tabs are currently
                  > open. This should be changable at runtime.

                  I would say having both tabs & drawer is quite feasible, but to make
                  it "nice" would require some work. Adding a hack that will let you
                  choose between the two would not take me that long (granted that Nico
                  would help me transfer his existing code to MacVim), but do you judge
                  this feature important enough for such "dirty" work at the moment?

                  The "right" way (this is a guess...I haven't thought about it that
                  much) would be to make Nico's drawer a delegate of the NSTabView (this
                  is what PSMTabBarControl does) and handle things from there. This
                  would require almost no change to the MacVim code (!) but I think it
                  would be a bit of an effort. If you have the time and inclination
                  Nico, then check out PSMTabBarControl (it's under MacVim/
                  PSMTabBarControl) and see if you can figure out how it deals with the
                  NSTabView delegate methods. (Note that there is always an 'invisible'
                  NSTabView present which holds all the NSTabViewItems, PSMTabBarControl
                  simply looks at this to decide which tabs to draw.) With this
                  approach it would be simple to add options to let you choose if/how/
                  when you want the drawer or the tabs---just change whether
                  PSMTabBarControl or the drawer is the delegate of the NSTabView, and
                  hide one or the other (but it would be unfeasible to have _both_
                  visible at the same time).

                  There are some much more pressing user interface issues I would rather
                  focus my time on at the moment though (I will start a discussion on
                  this soon), so unless people find this to be a make or break issue, I
                  will let it rest until further notice.


                  /Björn


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Ryan Phillips
                  ... Bjorn, Excellent work. Is the main editor window double buffered? Thank you, Ryan --~--~---------~--~----~------------~-------~--~----~ You received this
                  Message 8 of 17 , Jul 27, 2007
                    "bjorn.winckler" <bjorn.winckler@...> said:
                    >
                    > I am happy to announce MacVim.app - a new port of Vim to Mac OS X.
                    > This is a project I have been working on for almost a year now and it
                    > is finally in such a state that I believe it might be usable for
                    > others than just me.
                    >
                    > The goal of MacVim is to look better and integrate more seamlessly
                    > with the Mac than the existing Carbon port of Vim. Its main features
                    > are:
                    >
                    > - Multiple windows (Expos? works with the MacVim windows)
                    > - Safari-style tabs (using PSMTabBarControl from Positive Spin Media)
                    > - Toolbar
                    >
                    > I will be adding things as time goes on, but for now I would like some
                    > people to test it out and focus on getting rid of all bugs that are
                    > sure to be discovered.
                    >

                    Bjorn,

                    Excellent work. Is the main editor window double buffered?

                    Thank you,
                    Ryan

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Nico Weber
                    ... The main editor window seems to be the default Cocoa text component which is double buffered (like everything in OS X (if you don t use legacy apis ;-)
                    Message 9 of 17 , Jul 27, 2007
                      > Excellent work. Is the main editor window double buffered?

                      The main editor window seems to be the default Cocoa text component
                      which is double buffered (like everything in OS X (if you don't use
                      legacy apis ;-) )).


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Nico Weber
                      ... So I decided to delete MacVim and wait for the next version (too buggy for usage, and not enough time to hack on it), and couldn t delete it because it was
                      Message 10 of 17 , Jul 28, 2007
                        > Memory usage is something that is on my TODO list; I expect there
                        > to be quite a bit of memory leaking at this point in time.

                        So I decided to delete MacVim and wait for the next version (too
                        buggy for usage, and not enough time to hack on it), and couldn't
                        delete it because it was still "in use" . Turns out there were still
                        two Vim processes running MacVim had started when I tested it a few
                        days ago. So you're leaking processes as well :-P

                        Bye,
                        Nico

                        ps: I don't like the name MacVim (mainly because the mac version of
                        vim is hosted at macvim.org, so the current version is already
                        associated with Mac Vim (at least for me). What about AquaVim? ;-)



                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • björn
                        ... Haha...you do find all the nasty problems, but it is a _snapshot_ after all. ... I fixed this issue and some of the memory leaks last night, and will
                        Message 11 of 17 , Jul 29, 2007
                          > Memory usage is something that is on my TODO list;  I expect there
                          > to be quite a bit of memory leaking at this point in time.

                          So I decided to delete MacVim and wait for the next version (too
                          buggy for usage, and not enough time to hack on it), and couldn't
                          delete it because it was still "in use" . Turns out there were still
                          two Vim processes running MacVim had started when I tested it a few
                          days ago. So you're leaking processes as well :-P

                          Haha...you do find all the nasty problems, but it is a _snapshot_ after all. :)
                          I fixed this issue and some of the memory leaks last night, and will probably upload a new snapshot tonight.

                          ps: I don't like the name MacVim (mainly because the mac version of
                          vim is hosted at macvim.org, so the current version is already
                          associated with Mac Vim (at least for me). What about AquaVim? ;-)

                          Coming up with a name is hard, but changing the name is a lot or work, and I have already set up the googlepage so I will not change it now.  If I get enough complaints about the name, I will change it before releasing a proper (non-snapshot) version.  However, I like the name and don't really mind if there is a macvim.org...I envision that a version of MacVim will be available there one day.  Once I iron out the serious bugs in MacVim and get most of the features in there I hope there will be no reason to use the old Carbon version anymore.  And if it never reach that stage, well, we'll see what happens.


                          /Björn

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