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

[ANN] MacVim.app Google code page

Expand Messages
  • bjorn.winckler
    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
    Message 1 of 17 , Jul 25 12:51 AM
    • 0 Attachment
      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


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Nico Weber
      ... Nice :-) For some reason, I prefer the current tabs-in-a-slider approach ( ;-) ), but otherwise it looks good. ... I nearly killed my system by clicking
      Message 2 of 17 , Jul 25 1:57 AM
      • 0 Attachment
        > 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

        Nice :-) For some reason, I prefer the current tabs-in-a-slider
        approach ( ;-) ), but otherwise it looks good.

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

        I nearly killed my system by clicking into the zoom button three
        times and then trying to resize the window by dragging the resize
        handle. That made the app use all processing power of my laptop, it
        was really hard to kill it. This is reproducible (hit cmd-opt-escape
        _before_ you try this!): Hit the zoom button once, then pull the
        resize handle up and wiggle the mouse until the status bar disappears
        (why is there a separate status bar anyways?)

        Anyways, the zoom button is broken too. There are drawing problems
        with the toolbar. And antialiasing doesn't work.

        If you close a window by pressing the red button, it won't ask if you
        want to save your changes.

        How is the multi-window feature implemented? If I type something in
        one window, and hit C-p in another window, the stuff from the first
        window doesn't show up in the completion list. Furthermore, every
        time I open a new window, memory usage goes up by a whole meg and
        doesn't go down if I close the window again. This feels more like a
        hack than a general solution...

        But all in all, this looks like this could become something I'll use
        a lot :-)

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

        It runs on an intel.

        You should talk with Jigod; as far as I understand he's working on
        something similar, so you should probably work together.

        Bye,
        Nico


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... Zooming turns out to be kind of hard to implement, so I am not surprised that you are experiencing problems...I will look into this. As for the toolbar
        Message 3 of 17 , Jul 25 2:23 AM
        • 0 Attachment
          > 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.

          I nearly killed my system by clicking into the zoom button three
          times and then trying to resize the window by dragging the resize
          handle. That made the app use all processing power of my laptop, it
          was really hard to kill it. This is reproducible (hit cmd-opt-escape
          _before_ you try this!): Hit the zoom button once, then pull the
          resize handle up and wiggle the mouse until the status bar disappears
          (why is there a separate status bar anyways?)

          Anyways, the zoom button is broken too. There are drawing problems
          with the toolbar. And antialiasing doesn't work.

          Zooming turns out to be kind of hard to implement, so I am not surprised that you are experiencing problems...I will look into this.  As for the toolbar and antialiasing;  I am using Cocoa's NSToolbar for the toolbar and NSTextView for the text rendering...so I am not quite sure what you mean by 'drawing problems with the toolbar'.  As for antialiasing---this is handled by NSTextView, at the moment I don't know how to control it to be quite honest. ;)

          If you close a window by pressing the red button, it won't ask if you
          want to save your changes.

          Oops...forgot that one.  I only implemented this for when you quit so far (i.e. Cmd+Q or choosing Quit on the MacVim menu)!

          How is the multi-window feature implemented? If I type something in
          one window, and hit C-p in another window, the stuff from the first
          window doesn't show up in the completion list. Furthermore, every
          time I open a new window, memory usage goes up by a whole meg and
          doesn't go down if I close the window again. This feels more like a
          hack than a general solution...

          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.

          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. 

          Integrating Cocoa and Vim is not easy---both Vim and Cocoa expects to be in charge of the main thread.  I have tried several solutions, including the "Vim way" i.e. letting Vim start up Cocoa and calling Cocoa to update every now and then.  For some reason that is lost to me at this point in time I could not get this to work very well.  However, I think Jiang is attempting this approach now (is that so Jiang?) and maybe he'll get that to work.  I know that there is a port of Emacs to Cocoa that does this, so it is surely possible.

          But all in all, this looks like this could become something I'll use
          a lot :-)

          Thanks!  I actually use MacVim for all my MacVim development, so it is my main editor at the moment. :)

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

          It runs on an intel.

          That is good to know.

          You should talk with Jigod; as far as I understand he's working on
          something similar, so you should probably work together.

          We are discussing this matter presently.


          /Björn

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

        • Jjgod Jiang
          Hi, ... As you can see from current vim-cocoa source code, I m trying a lower level approach, do the drawing by myself. It looks like a more straightforward
          Message 4 of 17 , Jul 25 2:55 AM
          • 0 Attachment
            Hi,

            2007/7/25, björn <bjorn.winckler@...>:
            >
            > Zooming turns out to be kind of hard to implement, so I am not surprised
            > that you are experiencing problems...I will look into this. As for the
            > toolbar and antialiasing; I am using Cocoa's NSToolbar for the toolbar and
            > NSTextView for the text rendering...so I am not quite sure what you mean by
            > 'drawing problems with the toolbar'. As for antialiasing---this is handled
            > by NSTextView, at the moment I don't know how to control it to be quite
            > honest. ;)

            As you can see from current vim-cocoa source code, I'm trying a lower
            level approach, do the drawing by myself. It looks like a more
            straightforward approach than modify the buffer of a NSTextView, but
            it still has it's own limitations, the most important one is, regularly, you
            can only do the drawing in -drawRect:, because in other places, the
            code executing may not own the current screen, and should not draw
            at that time.

            There are two workaround I found to solve this problem, one of them
            is using an image whose size equals to the content view as a buffer,
            then draw this image (or part of it) on to screen in -drawRect:.

            Another solution is adding all drawing operations into a queue, then
            perform these operations one by one in -drawRect:.

            One of the advantages of doing all the drawings by myself is to have
            more control over the rendering effect, including font, character width,
            etc. Thus have better support for wide characters in turn.

            The bad thing is, I also have to optimize all the drawing by myself,
            so at present scrolling in vim-cocoa is not as smooth as Björn's
            MacVim.

            > Integrating Cocoa and Vim is not easy---both Vim and Cocoa expects to be in
            > charge of the main thread. I have tried several solutions, including the
            > "Vim way" i.e. letting Vim start up Cocoa and calling Cocoa to update every
            > now and then. For some reason that is lost to me at this point in time I
            > could not get this to work very well. However, I think Jiang is attempting
            > this approach now (is that so Jiang?) and maybe he'll get that to work. I
            > know that there is a port of Emacs to Cocoa that does this, so it is surely
            > possible.

            Yep, that's the most different place I found, my approach is to break
            -[NSApplication run] into fetching events and dispatching, it's
            integrated into Vim (just like the Carbon port does), and I have to
            maintain all the places that will cause the current run loop stop. But
            as far as I can see from Björn's code, it use a NSRunLoop, GUI and
            vim are loosely coupled by message port. But in vim-cocoa, almost
            all incoming calls from vim are performed directly.

            So, at present merging code seems to be a very difficult job, IMHO.

            - Jiang

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... Yep, this queuing is what MacVim does too...actually _all_ incoming calls from Vim (i.e. gui_mch_* stuff) are put onto a queue, which is consequently
            Message 5 of 17 , Jul 25 3:29 AM
            • 0 Attachment
              > Zooming turns out to be kind of hard to implement, so I am not surprised
              > that you are experiencing problems...I will look into this.  As for the
              > toolbar and antialiasing;  I am using Cocoa's NSToolbar for the toolbar and
              > NSTextView for the text rendering...so I am not quite sure what you mean by
              > 'drawing problems with the toolbar'.  As for antialiasing---this is handled
              > by NSTextView, at the moment I don't know how to control it to be quite
              > honest. ;)

              As you can see from current vim-cocoa source code, I'm trying a lower
              level approach, do the drawing by myself. It looks like a more
              straightforward approach than modify the buffer of a NSTextView, but
              it still has it's own limitations, the most important one is, regularly, you
              can only do the drawing in -drawRect:, because in other places, the
              code executing may not own the current screen, and should not draw
              at that time.

              There are two workaround I found to solve this problem, one of them
              is using an image whose size equals to the content view as a buffer,
              then draw this image (or part of it) on to screen in -drawRect:.

              Another solution is adding all drawing operations into a queue, then
              perform these operations one by one in -drawRect:.

              Yep, this queuing is what MacVim does too...actually _all_ incoming calls from Vim ( i.e. gui_mch_* stuff) are put onto a queue, which is consequently flushed when gui_mch_wait_for_chars() is called.  In this same method I also block on [NSRunloop run] waiting for mach port messages to arrive from MacVim.  (All this is in gui_macvim.m and MMBackend.m.)

              One of the advantages of doing all the drawings by myself is to have
              more control over the rendering effect, including font, character width,
              etc. Thus have better support for wide characters in turn.

              The bad thing is, I also have to optimize all the drawing by myself,
              so at present scrolling in vim-cocoa is not as smooth as Björn's
              MacVim.

              Yep, I ran into that problem too when I tried using the AppKit NSStringDrawing extensions.  The only way I can think of fixing this is to set up a permament NSLayoutManager (without NSTextView) and use that for drawing (this is what the AppKit drawing extensions do every time you call drawAtPoint: etc.).  However, that leads you directly to the same swamp that I am stuck in---you have to look into overriding NSTypesetter to get control over the layout of glyphs.  It doesn't seem impossible (check out the iTerm project...they do this), but I haven't had the time to investigate it yet.

              In any case, whenever one of us manages to do this properly, the other can benefit from it.  (I can easily adapt MacVim to use your drawing model and you could use mine by doing what I outlined above.)

              > Integrating Cocoa and Vim is not easy---both Vim and Cocoa expects to be in
              > charge of the main thread.  I have tried several solutions, including the
              > "Vim way" i.e. letting Vim start up Cocoa and calling Cocoa to update every
              > now and then.  For some reason that is lost to me at this point in time I
              > could not get this to work very well.  However, I think Jiang is attempting
              > this approach now (is that so Jiang?) and maybe he'll get that to work.  I
              > know that there is a port of Emacs to Cocoa that does this, so it is surely
              > possible.

              Yep, that's the most different place I found, my approach is to break
              -[NSApplication run] into fetching events and dispatching, it's
              integrated into Vim (just like the Carbon port does), and I have to
              maintain all the places that will cause the current run loop stop. But
              as far as I can see from Björn's code, it use a NSRunLoop, GUI and
              vim are loosely coupled by message port. But in vim-cocoa, almost
              all incoming calls from vim are performed directly.

              So, at present merging code seems to be a very difficult job, IMHO.

              You are right, of course.  However, MacVim has gone through several iterations, each with a new approach, so I know that it is possible to adapt it.  I will pursue the current approach until I realise it simply will not work (or be too slow...this is one of my biggest concerns).  Hopefully if more people try MacVim out I can get a more realistic estimate on how well it works.

              In any case, at the moment the best we can do is to benefit from the experiences of the other's attempt at implementing a certain feature and once we find a way that works well with Cocoa, we can perhaps integrate our two applications into one.  I am more than willing to do this as I know that I do not have that much time for working on this project and I think that the only way to get a working port is to have more than one person working on it.  That being said, I welcome all and any developers who want to join in on the MacVim effort.


              /Björn

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

            • Bram Moolenaar
              I inderstand that there are different ways to use Cocoa for Vim. I hardly know anything about this GUI, thus I have no opinion about what would be a better
              Message 6 of 17 , Jul 25 12:30 PM
              • 0 Attachment
                I inderstand that there are different ways to use Cocoa for Vim. I
                hardly know anything about this GUI, thus I have no opinion about what
                would be a better approach.

                I don't think we need to merge different versions at this point.
                Actually, it is good to try out different approaches and find out which
                one works best.

                This does require working on the difficult problems. I know it's
                tempting to work on things you know you can make work and make it look
                nice. But once these things get done you may find out that there is
                some basic problem that can't be solved without changing lots of things
                again. Thus it's important to first figure out the things that you
                don't know how to fix. E.g., the resizing, key focus problems, event
                handling and things like that.

                It's exciting to see substantial progress in the Mac version!

                --
                hundred-and-one symptoms of being an internet addict:
                38. You wake up at 3 a.m. to go to the bathroom and stop and check your e-mail
                on the way back to bed.

                /// 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
                -~----------~----~----~----~------~----~------~--~---
              • 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 7 of 17 , Jul 25 1:24 PM
                • 0 Attachment
                  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 8 of 17 , Jul 26 7:21 AM
                  • 0 Attachment
                    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 9 of 17 , Jul 26 11:31 AM
                    • 0 Attachment
                      > 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 10 of 17 , Jul 26 1:17 PM
                      • 0 Attachment
                        > 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 11 of 17 , Jul 26 1:38 PM
                        • 0 Attachment
                          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 12 of 17 , Jul 26 5:44 PM
                          • 0 Attachment
                            > 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 13 of 17 , Jul 27 12:19 AM
                            • 0 Attachment
                              > > 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 14 of 17 , Jul 27 11:12 PM
                              • 0 Attachment
                                "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 15 of 17 , Jul 27 11:16 PM
                                • 0 Attachment
                                  > 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 16 of 17 , Jul 28 5:08 PM
                                  • 0 Attachment
                                    > 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 17 of 17 , Jul 29 2:39 AM
                                    • 0 Attachment
                                      > 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.