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

New MacVim Snapshot (r83)

Expand Messages
  • björn
    I have posted a new snapshot of MacVim at: http://code.google.com/p/macvim/ Changes this time around are: - Window resizing: The code logic has changed in that
    Message 1 of 10 , Aug 5, 2007
      I have posted a new snapshot of MacVim at:

      http://code.google.com/p/macvim/

      Changes this time around are:

      - Window resizing: The code logic has changed in that MacVim does no actual resizing of the MMTextStorage without permission from Vim; if the user drags to resize, MacVim tells Vim that the dimensions should change and waits for Vim to acknowledge that the dimensions have changed.  Furthermore, no resizing is performed on NSLayoutManager delegate messages (apparently this is bad practice).  Hopefully this will fix the bug where nothing got drawn after zooming, as well as the bug where MacVim crashed when resizing the window (please Nico...tell me it's ok now ;-).  Also, the window won't go completely blank when you drag to resize.  A negative side-effect is that the window might be too small if multi-byte chars are being drawn...this will be addressed in the future.
       
      - Menus: It is now possible to set key equivalents (via ":menukeyequiv" command).  I have started making changes to the menus to make them follow the HIG more closely, all changes to the menus are done in the system gvimrc file " MacVim.app/Contents/Resources/vim/gvimrc".  This is a work in progress, I appreciate any help with making the menus better (the current menus and their bindings are temporary!).  Check the menus for what bindings are currently in place (note that if you have previous ":map" commands which bind to the same values as the menus, then your ":map" will be ignored).

      - ":action" command: This executes an obj-c action message (allowed messages are in Actions.plist), used for instance by the "New Window" menu item.

      - Tabline bug: I've implemented Nico's suggested change to fix the tabline drawing bug (the toolbar baseline is always hidden, when tabs are hidden, a 1px baseline is drawn instead)

      - Zoom button defaults to "height-zoom only", hold down Cmd to zoom to fill window.

      - Enable "terminateafterlastwindowclosed" user default to quit MacVim when last window is closed (disabled by default)

      - Ability to change the text view inset via user defaults "inset[left|right|top|bottom]" (currently a 2px margin on the left, the others have a 1px margin)

      - ...and more


      If you want to change user defaults options, open the terminal and type
         defaults write org.vim.MacVim optionname value
      where 'optionname' can be any of the options listed in the beginning of MMAppController.m and 'value' is the value of the option you want to set (boolean values should work with 0/1 as well as yes/no).  Be careful when editing these options...at the moment there are no sanity checks in place.  You will need to restart MacVim before they take effect.



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

    • Jjgod Jiang
      Hi Björn, ... I just finished the gui_mch_dialog() part in my vim-cocoa project, which you may find interesting. For dialogs without text field, I simply
      Message 2 of 10 , Aug 5, 2007
        Hi Björn,

        2007/8/5, björn <bjorn.winckler@...>:
        > I have posted a new snapshot of MacVim at:
        >
        > http://code.google.com/p/macvim/

        I just finished the gui_mch_dialog() part in my vim-cocoa project,
        which you may find interesting.

        For dialogs without text field, I simply create NSAlert, then runs
        that window as a modal sheet.

        The most tricky part is handling dialogs with a text field (it's used
        in menu "Help | Find...", "Edit | Global Settings | Search Path..."),
        because in this condition, we have to create a custom window as
        sheet, but it's hard to layout GUI elements in that window to make
        them fit the text and buttons provided. It's hard to create a tidy
        window conformance to HID programmatically. So my current
        approach use a NIB created by Interface Builder. Both text field
        and buttons in that NIB have fixed sizes and locations.

        - Jiang

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... Nice. But does it work to navigate through the sheets using the keyboard? I think this is one of the biggest annoyances with the Carbon Vim port. /Björn
        Message 3 of 10 , Aug 5, 2007
          > I have posted a new snapshot of MacVim at:
          >
          >
          http://code.google.com/p/macvim/

          I just finished the gui_mch_dialog() part in my vim-cocoa project,
          which you may find interesting.

          For dialogs without text field, I simply create NSAlert, then runs
          that window as a modal sheet.

          The most tricky part is handling dialogs with a text field (it's used
          in menu "Help | Find...", "Edit | Global Settings | Search Path..."),
          because in this condition, we have to create a custom window as
          sheet, but it's hard to layout GUI elements in that window to make
          them fit the text and buttons provided. It's hard to create a tidy
          window conformance to HID programmatically. So my current
          approach use a NIB created by Interface Builder. Both text field
          and buttons in that NIB have fixed sizes and locations.

          Nice.  But does it work to navigate through the sheets using the keyboard?  I think this is one of the biggest annoyances with the Carbon Vim port.


          /Björn

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

        • Nico Weber
          Hi, ... If I hit Cmd-Zoombutton, drawing is still broken (and all keystrokes are ignored from that point in time, and I haven t found a way to restore vim back
          Message 4 of 10 , Aug 5, 2007
            Hi,

            > - Window resizing: The code logic has changed in that MacVim does
            > no actual resizing of the MMTextStorage without permission from
            > Vim; if the user drags to resize, MacVim tells Vim that the
            > dimensions should change and waits for Vim to acknowledge that the
            > dimensions have changed. Furthermore, no resizing is performed on
            > NSLayoutManager delegate messages (apparently this is bad
            > practice). Hopefully this will fix the bug where nothing got drawn
            > after zooming, as well as the bug where MacVim crashed when
            > resizing the window (please Nico...tell me it's ok now ;-). Also,
            > the window won't go completely blank when you drag to resize. A
            > negative side-effect is that the window might be too small if multi-
            > byte chars are being drawn...this will be addressed in the future.

            If I hit Cmd-Zoombutton, drawing is still broken (and all keystrokes
            are ignored from that point in time, and I haven't found a way to
            restore vim back to normal behaviour yet). I'll take a look at that
            now. "Normal" zooming works.

            I was no longer able to kill vim by ferocious window resizing.

            If I resize the window but keep the mouse button pressed after I'm
            done, it takes about 0.5 seconds until the internal vim window adapts
            the size of the gui window. Perhaps you can use a timer that checks
            for resizes every 0.1 seconds while resizing is in progress? (or
            you're currently ignoring some event -- or the internal vim window
            size is "one event late" due to implementation details. It could
            probably be fixed somehow anyways).

            In carbon vim, cmd-w means "Close current (vim) window"; I had a
            mapping in my vimrc that made it say "close current gui window if
            current gui has more than one window, otherwise close current tab. if
            there's only one tab as well, close vim". Do you think that's a more
            useful mapping? (it's especially strange that cmd-w doesn't close the
            window when only one tab page is open. cmd-w does that in every other
            app).

            > - Tabline bug: I've implemented Nico's suggested change to fix the
            > tabline drawing bug (the toolbar baseline is always hidden, when
            > tabs are hidden, a 1px baseline is drawn instead)

            Looks good.

            Great work :-)

            - Nico

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Nico Weber
            ... Well, my mapping is `:map :q ` iirc (I m not at my main box atm) :-P --~--~---------~--~----~------------~-------~--~----~ You received this
            Message 5 of 10 , Aug 5, 2007
              > In carbon vim, cmd-w means "Close current (vim) window"; I had a
              > mapping in my vimrc that made it say "close current gui window if
              > current gui has more than one window, otherwise close current tab. if
              > there's only one tab as well, close vim". Do you think that's a more
              > useful mapping? (it's especially strange that cmd-w doesn't close the
              > window when only one tab page is open. cmd-w does that in every other
              > app).
              >
              > Yes! My intentions was to have Cmd-w close a tab if there is more
              > than one open, otherwise it should close the window. I was hoping
              > to do this with vim script...but I'm not sure how (have to learn
              > more vim script first to see if it is possible to query how many
              > tabs are open). Would your mapping be able to do that? Also, in
              > order for this to work properly I need to fix the implementation of
              > ':menukeyequiv' so that the menu item is updated whenever the key
              > equivalent changes (so that the text on the right hand side of the
              > menu item is updated to say Cmd-w next to "Close Tab" or next to
              > "Close Window" depending on whether more than one tab is open or not).

              Well, my mapping is `:map <D-w> :q<cr>` iirc (I'm not at my main box
              atm) :-P


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... Hehe, ok a little bit too low-tech for my needs...lets see if anybody else can help out with this mapping. (The Cmd-Zoom bug is fixed now by the way...as
              Message 6 of 10 , Aug 5, 2007
                > In carbon vim, cmd-w means "Close current (vim) window"; I had a
                > mapping in my vimrc that made it say "close current gui window if
                > current gui has more than one window, otherwise close current tab. if
                > there's only one tab as well, close vim". Do you think that's a more
                > useful mapping? (it's especially strange that cmd-w doesn't close the
                > window when only one tab page is open. cmd-w does that in every other
                > app).
                >
                > Yes!  My intentions was to have Cmd-w close a tab if there is more
                > than one open, otherwise it should close the window.  I was hoping
                > to do this with vim script...but I'm not sure how (have to learn
                > more vim script first to see if it is possible to query how many
                > tabs are open).  Would your mapping be able to do that?  Also, in
                > order for this to work properly I need to fix the implementation of
                > ':menukeyequiv' so that the menu item is updated whenever the key
                > equivalent changes (so that the text on the right hand side of the
                > menu item is updated to say Cmd-w next to "Close Tab" or next to
                > "Close Window" depending on whether more than one tab is open or not).

                Well, my mapping is `:map <D-w> :q<cr>` iirc (I'm not at my main box
                atm) :-P

                Hehe, ok a little bit too "low-tech" for my needs...lets see if anybody else can help out with this mapping.

                (The Cmd-Zoom bug is fixed now by the way...as I suspected %255c doesn't work that well as a format string to printf and relatives...)


                /Björn

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

              • Nico Weber
                ... I can confirm this is fixed (tested with svn revision 86 iirc). --~--~---------~--~----~------------~-------~--~----~ You received this message from the
                Message 7 of 10 , Aug 5, 2007
                  > (The Cmd-Zoom bug is fixed now by the way...as I suspected %255c
                  > doesn't work that well as a format string to printf and relatives...)

                  I can confirm this is fixed (tested with svn revision 86 iirc).


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Jjgod Jiang
                  Hi, ... Yes, you can navigate between each buttons with tab key and use space key to confirm. But it seems the first button added automatically became the
                  Message 8 of 10 , Aug 5, 2007
                    Hi,

                    2007/8/6, björn <bjorn.winckler@...>:
                    > Nice. But does it work to navigate through the sheets using the keyboard?
                    > I think this is one of the biggest annoyances with the Carbon Vim port.

                    Yes, you can navigate between each buttons with tab key and use space
                    key to confirm. But it seems the first button added automatically became
                    the default button of that alert dialog (press Enter equals to hit that button).
                    While the initial first responder is the last button added, this behavior needs
                    to be corrected.

                    For the input dialog window created by Interface Builder, do you know what's
                    the "official" way to make a button default? Now I do this by setting it's key
                    equiv. to \R.

                    - Jiang

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • björn
                    ... Let me know when you fixed this problem and I will try to adapt your code to MacVim. For the input dialog window created by Interface Builder, do you know
                    Message 9 of 10 , Aug 6, 2007

                      2007/8/6, björn <bjorn.winckler@... >:
                      > Nice.  But does it work to navigate through the sheets using the keyboard?
                      > I think this is one of the biggest annoyances with the Carbon Vim port.

                      Yes, you can navigate between each buttons with tab key and use space
                      key to  confirm. But it seems the first button added automatically became
                      the default button of that alert dialog (press Enter equals to hit that button).
                      While the initial first responder is the last button added, this behavior needs
                      to be corrected.

                      Let me know when you fixed this problem and I will try to adapt your code to MacVim. 

                      For the input dialog window created by Interface Builder, do you know what's
                      the "official" way to make a button default? Now I do this by setting it's key
                      equiv. to \R.

                      I looked at the Cocoa application tutorial at Apple's dev center and they also do this by setting "Enter" as the key equiv of the default button.  So I guess that makes it the "official" way. :)


                      /Björn

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

                    • Nico Weber
                      ... Untested: drag a connection from the enclosing window to the control and set it as the initialFirstResponder.
                      Message 10 of 10 , Aug 7, 2007
                        > For the input dialog window created by Interface Builder, do you
                        > know what's
                        > the "official" way to make a button default? Now I do this by
                        > setting it's key
                        > equiv. to \R.

                        Untested: drag a connection from the enclosing window to the control
                        and set it as the initialFirstResponder.


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