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

too snappy?

Expand Messages
  • dv1445@wayne.edu
    Hello, I ve been mostly enjoying the snappy functionality. However, the snappiness patch becomes really annoying when trying to test changes to one s
    Message 1 of 23 , Jul 23, 2008
    • 0 Attachment
      Hello,

      I've been mostly enjoying the snappy functionality.

      However, the snappiness patch becomes really annoying when trying to test changes to one's .vimrc/.gvimrc. If I use MacVim to change one of these files and then hit command-N, I can't examine the changes because MacVim's snappy feature has already preloaded a few cases with the "old" .*vimrc. So I have to hit command-N several times quickly to drain the reserve of snappy Vims. That's a pain, plus there's a bunch of MacVim windows open when I don't want that; when going back to close them it becomes easy to forget which one has loaded the new .vimrc I'm trying to test.

      Is there a way to temporarily turn the snappiness off, without building anew? Maybe a .plist file change? If not, *could* there be a way? (E.g., something like command-shift-N to start a genuinely new instance). Am I missing a way to simply sidestep the issue?
      -gmn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • björn
      ... Matt reported that this would be a problem a while back so I am aware of it although not entirely sure how to handle it. Matt s suggestion was to
      Message 2 of 23 , Jul 24, 2008
      • 0 Attachment
        2008/7/23 <dv1445@...>:
        >
        > I've been mostly enjoying the snappy functionality.
        >
        > However, the snappiness patch becomes really annoying when trying to test changes to one's .vimrc/.gvimrc. If I use MacVim to change one of these files and then hit command-N, I can't examine the changes because MacVim's snappy feature has already preloaded a few cases with the "old" .*vimrc. So I have to hit command-N several times quickly to drain the reserve of snappy Vims. That's a pain, plus there's a bunch of MacVim windows open when I don't want that; when going back to close them it becomes easy to forget which one has loaded the new .vimrc I'm trying to test.
        >
        > Is there a way to temporarily turn the snappiness off, without building anew? Maybe a .plist file change? If not, *could* there be a way? (E.g., something like command-shift-N to start a genuinely new instance). Am I missing a way to simply sidestep the issue?

        Matt reported that this would be a problem a while back so I am aware
        of it although not entirely sure how to handle it. Matt's suggestion
        was to basically monitor changes to the rc-files and trash the cache
        if they were updated. This seems effective enough but what if the
        user adds something to the ~/.vim folder? Well, I guess we'd have to
        monitor changes to this as well. I have an inkling of an idea of how
        to do this but I have to read up on it first.

        Having a different key combo to disable using a cached process is
        something I was thinking of as well, but it seems rather confusing now
        that I think of it. If you go to the trouble of pressing Cmd-Shift-N
        to open a new window with the latest .[g]vimrc then what do you do
        once you've finished modifying that file? Well, you'd have to "clear
        the cache" again by pressing Cmd-N a couple of times and closing the
        windows like you just described. This seems to indicate that we'll
        have to do something along the lines of Matt's idea.

        Anyway, I'll have to think about this a bit more. For now, the only
        way to ensure that the cache won't be used is by starting a new window
        from the command line with the "mvim" command. :-(

        Björn

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bem Jones-Bey
        ... Wouldn t it make sense to blow away (and recreate the cache) if a user opens a window with something like Cmd-Shift-N? That s the behavior I would expect,
        Message 3 of 23 , Jul 24, 2008
        • 0 Attachment
          björn wrote:
          > Having a different key combo to disable using a cached process is
          > something I was thinking of as well, but it seems rather confusing now
          > that I think of it. If you go to the trouble of pressing Cmd-Shift-N
          > to open a new window with the latest .[g]vimrc then what do you do
          > once you've finished modifying that file? Well, you'd have to "clear
          > the cache" again by pressing Cmd-N a couple of times and closing the
          > windows like you just described. This seems to indicate that we'll
          > have to do something along the lines of Matt's idea.

          Wouldn't it make sense to blow away (and recreate the cache) if a user
          opens a window with something like Cmd-Shift-N? That's the behavior I
          would expect, at least. (Or is there something I'm missing here?)

          --
          Bem Jones-Bey (bem@...)

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... Of course, that s a good idea. However, I do think that having such a key combo is a somewhat dubious design decision since it is forcing users to take
          Message 4 of 23 , Jul 24, 2008
          • 0 Attachment
            2008/7/24 Bem Jones-Bey <bem@...>:
            >
            > björn wrote:
            >> Having a different key combo to disable using a cached process is
            >> something I was thinking of as well, but it seems rather confusing now
            >> that I think of it. If you go to the trouble of pressing Cmd-Shift-N
            >> to open a new window with the latest .[g]vimrc then what do you do
            >> once you've finished modifying that file? Well, you'd have to "clear
            >> the cache" again by pressing Cmd-N a couple of times and closing the
            >> windows like you just described. This seems to indicate that we'll
            >> have to do something along the lines of Matt's idea.
            >
            > Wouldn't it make sense to blow away (and recreate the cache) if a user
            > opens a window with something like Cmd-Shift-N? That's the behavior I
            > would expect, at least. (Or is there something I'm missing here?)

            Of course, that's a good idea.

            However, I do think that having such a key combo is a somewhat dubious
            design decision since it is forcing users to take action because the
            developer was too incompetent (or lazy) to solve the issue. (And
            could lead to situations where users hold down Shift every time they
            press Cmd-N simply because they've noticed that sometimes things do
            not work as they expect when they are not holding Shift.)

            Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • dv1445@wayne.edu
            ... Well, I think the key combo sounds nice to me as a temporary stopgap. (In principle, anyway; if it s a ton of work, it s probably not worth it). One could
            Message 5 of 23 , Jul 24, 2008
            • 0 Attachment
              Thus spake björn [07/24/08 @ 19.06.02 +0200]:
              > 2008/7/24 Bem Jones-Bey <bem@...>:
              > > björn wrote:
              > >> Having a different key combo to disable using a cached process is
              > >> something I was thinking of as well, but it seems rather confusing now
              > >> that I think of it. If you go to the trouble of pressing Cmd-Shift-N
              > >> to open a new window with the latest .[g]vimrc then what do you do
              > >> once you've finished modifying that file? Well, you'd have to "clear
              > >> the cache" again by pressing Cmd-N a couple of times and closing the
              > >> windows like you just described. This seems to indicate that we'll
              > >> have to do something along the lines of Matt's idea.
              > >
              > > Wouldn't it make sense to blow away (and recreate the cache) if a user
              > > opens a window with something like Cmd-Shift-N? That's the behavior I
              > > would expect, at least. (Or is there something I'm missing here?)
              >
              > Of course, that's a good idea.
              >
              > However, I do think that having such a key combo is a somewhat dubious
              > design decision since it is forcing users to take action because the
              > developer was too incompetent (or lazy) to solve the issue. (And
              > could lead to situations where users hold down Shift every time they
              > press Cmd-N simply because they've noticed that sometimes things do
              > not work as they expect when they are not holding Shift.)

              Well, I think the key combo sounds nice to me as a temporary stopgap. (In principle, anyway; if it's a ton of work, it's probably not worth it). One could even have a hidden preference to enable/disable that feature.
              -gmn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Steven Michalske
              Use the FSEvents notifications. http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html Have fun
              Message 6 of 23 , Jul 24, 2008
              • 0 Attachment
                Use the FSEvents notifications.

                http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html


                Have fun :-)

                On Jul 24, 2008, at 8:33 AM, björn wrote:

                >
                > 2008/7/23 <dv1445@...>:
                >>
                >> I've been mostly enjoying the snappy functionality.
                >>
                >> However, the snappiness patch becomes really annoying when trying
                >> to test changes to one's .vimrc/.gvimrc. If I use MacVim to change
                >> one of these files and then hit command-N, I can't examine the
                >> changes because MacVim's snappy feature has already preloaded a few
                >> cases with the "old" .*vimrc. So I have to hit command-N several
                >> times quickly to drain the reserve of snappy Vims. That's a pain,
                >> plus there's a bunch of MacVim windows open when I don't want that;
                >> when going back to close them it becomes easy to forget which one
                >> has loaded the new .vimrc I'm trying to test.
                >>
                >> Is there a way to temporarily turn the snappiness off, without
                >> building anew? Maybe a .plist file change? If not, *could* there
                >> be a way? (E.g., something like command-shift-N to start a
                >> genuinely new instance). Am I missing a way to simply sidestep the
                >> issue?
                >
                > Matt reported that this would be a problem a while back so I am aware
                > of it although not entirely sure how to handle it. Matt's suggestion
                > was to basically monitor changes to the rc-files and trash the cache
                > if they were updated. This seems effective enough but what if the
                > user adds something to the ~/.vim folder? Well, I guess we'd have to
                > monitor changes to this as well. I have an inkling of an idea of how
                > to do this but I have to read up on it first.
                >
                > Having a different key combo to disable using a cached process is
                > something I was thinking of as well, but it seems rather confusing now
                > that I think of it. If you go to the trouble of pressing Cmd-Shift-N
                > to open a new window with the latest .[g]vimrc then what do you do
                > once you've finished modifying that file? Well, you'd have to "clear
                > the cache" again by pressing Cmd-N a couple of times and closing the
                > windows like you just described. This seems to indicate that we'll
                > have to do something along the lines of Matt's idea.
                >
                > Anyway, I'll have to think about this a bit more. For now, the only
                > way to ensure that the cache won't be used is by starting a new window
                > from the command line with the "mvim" command. :-(
                >
                > Björn
                >
                > >


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... Thanks for the link! I had a look and using FSEvents seems very simple...but it requires 10.5. As far as I understand, to support 10.4 I d have to use
                Message 7 of 23 , Jul 24, 2008
                • 0 Attachment
                  2008/7/24 Steven Michalske <smichalske@...>:
                  >
                  > On Jul 24, 2008, at 8:33 AM, björn wrote:
                  >
                  >>
                  >> 2008/7/23 <dv1445@...>:
                  >>>
                  >>> I've been mostly enjoying the snappy functionality.
                  >>>
                  >>> However, the snappiness patch becomes really annoying when trying
                  >>> to test changes to one's .vimrc/.gvimrc. If I use MacVim to change
                  >>> one of these files and then hit command-N, I can't examine the
                  >>> changes because MacVim's snappy feature has already preloaded a few
                  >>> cases with the "old" .*vimrc. So I have to hit command-N several
                  >>> times quickly to drain the reserve of snappy Vims. That's a pain,
                  >>> plus there's a bunch of MacVim windows open when I don't want that;
                  >>> when going back to close them it becomes easy to forget which one
                  >>> has loaded the new .vimrc I'm trying to test.
                  >>>
                  >>> Is there a way to temporarily turn the snappiness off, without
                  >>> building anew? Maybe a .plist file change? If not, *could* there
                  >>> be a way? (E.g., something like command-shift-N to start a
                  >>> genuinely new instance). Am I missing a way to simply sidestep the
                  >>> issue?
                  >>
                  >> Matt reported that this would be a problem a while back so I am aware
                  >> of it although not entirely sure how to handle it. Matt's suggestion
                  >> was to basically monitor changes to the rc-files and trash the cache
                  >> if they were updated. This seems effective enough but what if the
                  >> user adds something to the ~/.vim folder? Well, I guess we'd have to
                  >> monitor changes to this as well. I have an inkling of an idea of how
                  >> to do this but I have to read up on it first.
                  >>
                  >> Having a different key combo to disable using a cached process is
                  >> something I was thinking of as well, but it seems rather confusing now
                  >> that I think of it. If you go to the trouble of pressing Cmd-Shift-N
                  >> to open a new window with the latest .[g]vimrc then what do you do
                  >> once you've finished modifying that file? Well, you'd have to "clear
                  >> the cache" again by pressing Cmd-N a couple of times and closing the
                  >> windows like you just described. This seems to indicate that we'll
                  >> have to do something along the lines of Matt's idea.
                  >>
                  >> Anyway, I'll have to think about this a bit more. For now, the only
                  >> way to ensure that the cache won't be used is by starting a new window
                  >> from the command line with the "mvim" command. :-(
                  >
                  > Use the FSEvents notifications.
                  >
                  > http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html
                  >
                  >
                  > Have fun :-)

                  Thanks for the link!

                  I had a look and using FSEvents seems very simple...but it requires
                  10.5. As far as I understand, to support 10.4 I'd have to use kqueues
                  which seems slightly more involved...or did I miss something?

                  Björn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Steven Michalske
                  this should work with tiger as well, i think it involves the stuff bolted into the kernel for spotlight. two tiger applications that log file changes.
                  Message 8 of 23 , Jul 24, 2008
                  • 0 Attachment
                    this should work with tiger as well, i think it involves the stuff
                    bolted into the kernel for spotlight.


                    two tiger applications that log file changes.

                    http://www.kernelthread.com/software/fslogger/

                    http://www.cocoadev.com/index.pl?FileSystemNotifications

                    as a corner case..... i would just not support the jaguar installs
                    for simplicity.

                    i am not sure how this stuff works because i am a hardware guy, but
                    try to register for the notification, it would fail, then implement
                    the kqueues stuff i guess.

                    Steve

                    On Jul 24, 2008, at 1:35 PM, björn wrote:

                    >
                    > 2008/7/24 Steven Michalske <smichalske@...>:
                    >>
                    >> On Jul 24, 2008, at 8:33 AM, björn wrote:
                    >>
                    >>>
                    >>> 2008/7/23 <dv1445@...>:
                    >>>>
                    >>>> I've been mostly enjoying the snappy functionality.
                    >>>>
                    >>>> However, the snappiness patch becomes really annoying when trying
                    >>>> to test changes to one's .vimrc/.gvimrc. If I use MacVim to change
                    >>>> one of these files and then hit command-N, I can't examine the
                    >>>> changes because MacVim's snappy feature has already preloaded a few
                    >>>> cases with the "old" .*vimrc. So I have to hit command-N several
                    >>>> times quickly to drain the reserve of snappy Vims. That's a pain,
                    >>>> plus there's a bunch of MacVim windows open when I don't want that;
                    >>>> when going back to close them it becomes easy to forget which one
                    >>>> has loaded the new .vimrc I'm trying to test.
                    >>>>
                    >>>> Is there a way to temporarily turn the snappiness off, without
                    >>>> building anew? Maybe a .plist file change? If not, *could* there
                    >>>> be a way? (E.g., something like command-shift-N to start a
                    >>>> genuinely new instance). Am I missing a way to simply sidestep the
                    >>>> issue?
                    >>>
                    >>> Matt reported that this would be a problem a while back so I am
                    >>> aware
                    >>> of it although not entirely sure how to handle it. Matt's
                    >>> suggestion
                    >>> was to basically monitor changes to the rc-files and trash the cache
                    >>> if they were updated. This seems effective enough but what if the
                    >>> user adds something to the ~/.vim folder? Well, I guess we'd have
                    >>> to
                    >>> monitor changes to this as well. I have an inkling of an idea of
                    >>> how
                    >>> to do this but I have to read up on it first.
                    >>>
                    >>> Having a different key combo to disable using a cached process is
                    >>> something I was thinking of as well, but it seems rather confusing
                    >>> now
                    >>> that I think of it. If you go to the trouble of pressing Cmd-
                    >>> Shift-N
                    >>> to open a new window with the latest .[g]vimrc then what do you do
                    >>> once you've finished modifying that file? Well, you'd have to
                    >>> "clear
                    >>> the cache" again by pressing Cmd-N a couple of times and closing the
                    >>> windows like you just described. This seems to indicate that we'll
                    >>> have to do something along the lines of Matt's idea.
                    >>>
                    >>> Anyway, I'll have to think about this a bit more. For now, the only
                    >>> way to ensure that the cache won't be used is by starting a new
                    >>> window
                    >>> from the command line with the "mvim" command. :-(
                    >>
                    >> Use the FSEvents notifications.
                    >>
                    >> http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html
                    >>
                    >>
                    >> Have fun :-)
                    >
                    > Thanks for the link!
                    >
                    > I had a look and using FSEvents seems very simple...but it requires
                    > 10.5. As far as I understand, to support 10.4 I'd have to use kqueues
                    > which seems slightly more involved...or did I miss something?
                    >
                    > Björn
                    >
                    > >


                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Matt Tolton
                    Bjorn, I think that using Shift + Cmd + N to create a fresh instance (and close and reopen any background instances) might be a cleaner solution. It seems
                    Message 9 of 23 , Jul 24, 2008
                    • 0 Attachment
                      Bjorn,

                      I think that using Shift + Cmd + N to create a "fresh" instance (and
                      close and reopen any background instances) might be a cleaner
                      solution. It seems like you can't really know all of the files that
                      affect vim when it starts up. What if the .vimrc sources some file
                      someplace else in the file system? (don't think this is far fetched
                      -- it happens in the vim configuration here at work).

                      Anyway, I think that it adds unneeded complication to do this and it's
                      not really necessary. Also, I think that you should be sure to make
                      available in the preferences a default parameter to allow folks to
                      tune the number of cached instances to their liking (including setting
                      it to 0).

                      Just my 2 cents.

                      Thanks,
                      Matt

                      On Thu, Jul 24, 2008 at 5:39 PM, Steven Michalske <smichalske@...> wrote:
                      >
                      >
                      > this should work with tiger as well, i think it involves the stuff
                      > bolted into the kernel for spotlight.
                      >
                      >
                      > two tiger applications that log file changes.
                      >
                      > http://www.kernelthread.com/software/fslogger/
                      >
                      > http://www.cocoadev.com/index.pl?FileSystemNotifications
                      >
                      > as a corner case..... i would just not support the jaguar installs
                      > for simplicity.
                      >
                      > i am not sure how this stuff works because i am a hardware guy, but
                      > try to register for the notification, it would fail, then implement
                      > the kqueues stuff i guess.
                      >
                      > Steve
                      >
                      > On Jul 24, 2008, at 1:35 PM, björn wrote:
                      >
                      >>
                      >> 2008/7/24 Steven Michalske <smichalske@...>:
                      >>>
                      >>> On Jul 24, 2008, at 8:33 AM, björn wrote:
                      >>>
                      >>>>
                      >>>> 2008/7/23 <dv1445@...>:
                      >>>>>
                      >>>>> I've been mostly enjoying the snappy functionality.
                      >>>>>
                      >>>>> However, the snappiness patch becomes really annoying when trying
                      >>>>> to test changes to one's .vimrc/.gvimrc. If I use MacVim to change
                      >>>>> one of these files and then hit command-N, I can't examine the
                      >>>>> changes because MacVim's snappy feature has already preloaded a few
                      >>>>> cases with the "old" .*vimrc. So I have to hit command-N several
                      >>>>> times quickly to drain the reserve of snappy Vims. That's a pain,
                      >>>>> plus there's a bunch of MacVim windows open when I don't want that;
                      >>>>> when going back to close them it becomes easy to forget which one
                      >>>>> has loaded the new .vimrc I'm trying to test.
                      >>>>>
                      >>>>> Is there a way to temporarily turn the snappiness off, without
                      >>>>> building anew? Maybe a .plist file change? If not, *could* there
                      >>>>> be a way? (E.g., something like command-shift-N to start a
                      >>>>> genuinely new instance). Am I missing a way to simply sidestep the
                      >>>>> issue?
                      >>>>
                      >>>> Matt reported that this would be a problem a while back so I am
                      >>>> aware
                      >>>> of it although not entirely sure how to handle it. Matt's
                      >>>> suggestion
                      >>>> was to basically monitor changes to the rc-files and trash the cache
                      >>>> if they were updated. This seems effective enough but what if the
                      >>>> user adds something to the ~/.vim folder? Well, I guess we'd have
                      >>>> to
                      >>>> monitor changes to this as well. I have an inkling of an idea of
                      >>>> how
                      >>>> to do this but I have to read up on it first.
                      >>>>
                      >>>> Having a different key combo to disable using a cached process is
                      >>>> something I was thinking of as well, but it seems rather confusing
                      >>>> now
                      >>>> that I think of it. If you go to the trouble of pressing Cmd-
                      >>>> Shift-N
                      >>>> to open a new window with the latest .[g]vimrc then what do you do
                      >>>> once you've finished modifying that file? Well, you'd have to
                      >>>> "clear
                      >>>> the cache" again by pressing Cmd-N a couple of times and closing the
                      >>>> windows like you just described. This seems to indicate that we'll
                      >>>> have to do something along the lines of Matt's idea.
                      >>>>
                      >>>> Anyway, I'll have to think about this a bit more. For now, the only
                      >>>> way to ensure that the cache won't be used is by starting a new
                      >>>> window
                      >>>> from the command line with the "mvim" command. :-(
                      >>>
                      >>> Use the FSEvents notifications.
                      >>>
                      >>> http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html
                      >>>
                      >>>
                      >>> Have fun :-)
                      >>
                      >> Thanks for the link!
                      >>
                      >> I had a look and using FSEvents seems very simple...but it requires
                      >> 10.5. As far as I understand, to support 10.4 I'd have to use kqueues
                      >> which seems slightly more involved...or did I miss something?
                      >>
                      >> Björn
                      >>
                      >> >
                      >
                      >
                      > >
                      >

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • björn
                      ... I have decided to go with this option since it is a bit too finicky to monitor if the rc-files have been modified. It is now possible to press Cmd-Shift-n
                      Message 10 of 23 , Aug 1 12:52 PM
                      • 0 Attachment
                        2008/7/25 Matt Tolton <matt@...>:
                        >
                        > I think that using Shift + Cmd + N to create a "fresh" instance (and
                        > close and reopen any background instances) might be a cleaner
                        > solution. It seems like you can't really know all of the files that
                        > affect vim when it starts up. What if the .vimrc sources some file
                        > someplace else in the file system? (don't think this is far fetched
                        > -- it happens in the vim configuration here at work).
                        >
                        > Anyway, I think that it adds unneeded complication to do this and it's
                        > not really necessary. Also, I think that you should be sure to make
                        > available in the preferences a default parameter to allow folks to
                        > tune the number of cached instances to their liking (including setting
                        > it to 0).

                        I have decided to go with this option since it is a bit too finicky to
                        monitor if the rc-files have been modified. It is now possible to
                        press Cmd-Shift-n to open a new window and clear the cache at the same
                        time (I called it "Force New Window" because I was too unimaginative
                        to come up with a nicer name).

                        The public repo now contains the "quickstart" feature but it is
                        disabled by default because I have noticed intermittent (but rare)
                        problems with opening/closing windows (nothing fatal, just annoying
                        log messages and problems with windows never opening). Despite this I
                        myself have it enabled all the time and it is working fine under
                        normal circumstances. To enable, open up Terminal and enter

                        defaults write org.vim.MacVim MMPreloadCacheSize 2

                        The biggest reason why I am pushing this patch is not the quickstart
                        but the added file opening options in the preferences panel (I posted
                        some screenshots a while back). Still, it would be nice if some of
                        you would pull and try it out a bit (and enable quickstart).

                        Thanks,
                        Björn

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Nico Weber
                        Hi, ... is the 0.4 seconds less startup-time really worth the conceptual overhead of another menu entry and another keyboard shortcut? Worse, the new keyboard
                        Message 11 of 23 , Aug 1 1:24 PM
                        • 0 Attachment
                          Hi,

                          > I have decided to go with this option since it is a bit too finicky to
                          > monitor if the rc-files have been modified. It is now possible to
                          > press Cmd-Shift-n to open a new window and clear the cache at the same
                          > time (I called it "Force New Window" because I was too unimaginative
                          > to come up with a nicer name).

                          is the 0.4 seconds less startup-time really worth the conceptual
                          overhead of another menu entry and another keyboard shortcut? Worse,
                          the new keyboard entry really only exposes implementation details.
                          Currently, the "Force new window" is hidden behind the "New window"
                          item, so users have no chance of discovering it (and chances that
                          users understand what that does are really low, even if they find it.
                          "New uncached window" is slightly better, but not much). The menu item
                          is even there if preloading is disabled.

                          I understand that you put a lot of work into this, but I'd vote
                          against having a MMPreloadCacheSize value greater than 0 by default.
                          That means most people won't use this functionality, but it also means
                          that less people will be confused why changes in their _vimrc are not
                          picked up or why newly installed plugins are not recognized.

                          > The biggest reason why I am pushing this patch is not the quickstart
                          > but the added file opening options in the preferences panel (I posted
                          > some screenshots a while back). Still, it would be nice if some of
                          > you would pull and try it out a bit (and enable quickstart).

                          I like the UI of this, though :-)

                          Nico

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • dv1445@wayne.edu
                          ... Works so far, though I do notice the minor problems you mention. I can get a delayed or failed open almost every time by doing the following: open my
                          Message 12 of 23 , Aug 1 1:27 PM
                          • 0 Attachment
                            Thus spake björn [08/01/08 @ 21.52.18 +0200]:
                            >
                            > 2008/7/25 Matt Tolton <matt@...>:
                            > >
                            > > I think that using Shift + Cmd + N to create a "fresh" instance (and
                            > > close and reopen any background instances) might be a cleaner
                            > > solution. It seems like you can't really know all of the files that
                            > > affect vim when it starts up. What if the .vimrc sources some file
                            > > someplace else in the file system? (don't think this is far fetched
                            > > -- it happens in the vim configuration here at work).
                            > >
                            > > Anyway, I think that it adds unneeded complication to do this and it's
                            > > not really necessary. Also, I think that you should be sure to make
                            > > available in the preferences a default parameter to allow folks to
                            > > tune the number of cached instances to their liking (including setting
                            > > it to 0).
                            >
                            > I have decided to go with this option since it is a bit too finicky to
                            > monitor if the rc-files have been modified. It is now possible to
                            > press Cmd-Shift-n to open a new window and clear the cache at the same
                            > time (I called it "Force New Window" because I was too unimaginative
                            > to come up with a nicer name).
                            >
                            > The public repo now contains the "quickstart" feature but it is
                            > disabled by default because I have noticed intermittent (but rare)
                            > problems with opening/closing windows (nothing fatal, just annoying
                            > log messages and problems with windows never opening). Despite this I
                            > myself have it enabled all the time and it is working fine under
                            > normal circumstances. To enable, open up Terminal and enter
                            >
                            > defaults write org.vim.MacVim MMPreloadCacheSize 2
                            >
                            > The biggest reason why I am pushing this patch is not the quickstart
                            > but the added file opening options in the preferences panel (I posted
                            > some screenshots a while back). Still, it would be nice if some of
                            > you would pull and try it out a bit (and enable quickstart).

                            Works so far, though I do notice the minor problems you mention. I can get a delayed or failed "open" almost every time by doing the following: open my .gvimrc and change the colorscheme (so I can see whether the cache has been bypassed or not); hit save; hit shift-cmd-n; behold the new colorscheme; hit cmd-w; hit plain old cmd-n; behold one of the following: either a delayed opening comparable to a quickstartless MacVim, or a non-opening of anything at all until a press cmd-n again.

                            I notice that there is no "Force New Window" in the File Menu unless I'm already holding down Shift-Cmd. Is that on purpose? I don't care one way or the other; I just thought perhaps there was supposed to have been an additional item rather than a hidden one.
                            -gmn

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • dv1445@wayne.edu
                            ... I should add: many thanks for this quickstart feature, Björn. It is a huge help to me, and I suspect to those of us who don t have the very latest and
                            Message 13 of 23 , Aug 1 1:33 PM
                            • 0 Attachment
                              Thus spake björn [08/01/08 @ 21.52.18 +0200]:
                              > I have decided to go with this option since it is a bit too finicky to
                              > monitor if the rc-files have been modified. It is now possible to
                              > press Cmd-Shift-n to open a new window and clear the cache at the same
                              > time (I called it "Force New Window" because I was too unimaginative
                              > to come up with a nicer name).
                              >
                              > The public repo now contains the "quickstart" feature but it is
                              > disabled by default because I have noticed intermittent (but rare)
                              > problems with opening/closing windows (nothing fatal, just annoying
                              > log messages and problems with windows never opening). Despite this I
                              > myself have it enabled all the time and it is working fine under
                              > normal circumstances. To enable, open up Terminal and enter

                              I should add: many thanks for this quickstart feature, Björn. It is a huge help to me, and I suspect to those of us who don't have the very latest and fastest machines. The cmd-n lag was one of the reasons I still mostly use console vim rather than MacVim. That lag was so bloody annoying! But with that out of the way, I'm much closer to becoming a mostly-MacVim man.
                              -gmn

                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • dv1445@wayne.edu
                              ... Ah, I just noticed that when MacVim occasionally fails to open a new window (one of the minor problems mentioned above), it still *thinks* they re open.
                              Message 14 of 23 , Aug 1 1:37 PM
                              • 0 Attachment
                                Thus spake björn [08/01/08 @ 21.52.18 +0200]:
                                > The public repo now contains the "quickstart" feature but it is
                                > disabled by default because I have noticed intermittent (but rare)
                                > problems with opening/closing windows (nothing fatal, just annoying
                                > log messages and problems with windows never opening). Despite this I
                                > myself have it enabled all the time and it is working fine under
                                > normal circumstances. To enable, open up Terminal and enter
                                >
                                > defaults write org.vim.MacVim MMPreloadCacheSize 2

                                Ah, I just noticed that when MacVim occasionally fails to open a new window (one of the minor problems mentioned above), it still *thinks* they're open. To see this, just try Cmd-Q after a failed open when no windows are visible. MacVim gives a dialog that says something like "are you sure you want to quit even with 2 windows still open?".

                                I can live with these issues until they gradually fall away as MacVim evolves.
                                -gmn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • björn
                                ... As you may or may not have guessed, these are more or less exactly the reasons why this feature is disabled by default. Until I manage to resolve the
                                Message 15 of 23 , Aug 1 2:09 PM
                                • 0 Attachment
                                  2008/8/1 Nico Weber <nicolasweber@...>:
                                  >
                                  >> I have decided to go with this option since it is a bit too finicky to
                                  >> monitor if the rc-files have been modified. It is now possible to
                                  >> press Cmd-Shift-n to open a new window and clear the cache at the same
                                  >> time (I called it "Force New Window" because I was too unimaginative
                                  >> to come up with a nicer name).
                                  >
                                  > is the 0.4 seconds less startup-time really worth the conceptual
                                  > overhead of another menu entry and another keyboard shortcut? Worse,
                                  > the new keyboard entry really only exposes implementation details.
                                  > Currently, the "Force new window" is hidden behind the "New window"
                                  > item, so users have no chance of discovering it (and chances that
                                  > users understand what that does are really low, even if they find it.
                                  > "New uncached window" is slightly better, but not much). The menu item
                                  > is even there if preloading is disabled.
                                  >
                                  > I understand that you put a lot of work into this, but I'd vote
                                  > against having a MMPreloadCacheSize value greater than 0 by default.
                                  > That means most people won't use this functionality, but it also means
                                  > that less people will be confused why changes in their _vimrc are not
                                  > picked up or why newly installed plugins are not recognized.

                                  As you may or may not have guessed, these are more or less exactly the
                                  reasons why this feature is disabled by default. Until I manage to
                                  resolve the current problems this is how I intend to keep things
                                  (although I will try to completely get rid of the above mentioned menu
                                  entry if the cache size is 0). I strongly dislike the added menu
                                  entry and am at a bit of a loss as to what can be done to get rid of
                                  it. I really want this feature to be transparent to the user -- if I
                                  can't make it that way it will most likely stay disabled indefinitely.

                                  However, I think you underestimate the "psychological" effects of
                                  getting rid of the loading times. I know that if I hadn't written
                                  MacVim myself I would frown upon the fact that there is a delay
                                  between pressing Cmd-n and a window appearing (hey, it's instantaneous
                                  in pretty much every other app). If somebody then told be the reason
                                  why this happens I would probably go "aha" and forget about the
                                  delay. Also, as gmn mentioned, opening a new window can take a lot
                                  longer than .4 s on older hardware (something that will make less and
                                  less of a difference as time passes and people upgrade, but...).

                                  >
                                  >> The biggest reason why I am pushing this patch is not the quickstart
                                  >> but the added file opening options in the preferences panel (I posted
                                  >> some screenshots a while back). Still, it would be nice if some of
                                  >> you would pull and try it out a bit (and enable quickstart).
                                  >
                                  > I like the UI of this, though :-)

                                  I'm glad you like it. This really is the main point of this patch.
                                  It would have been pushed a lot sooner if it wasn't for the fact that
                                  I stupidly implemented the quickstart feature simultaneously and the
                                  commits were too intertwined to "untangle" and push this separately.
                                  (I've been holding it off because of the above mentioned problems with
                                  the quickstart code.)

                                  Anyway, the quickstart feature must be considered "experimental" for
                                  now and it will stay disabled until further notice. (I will however
                                  keep the user default so that anybody brave enough can enable it
                                  themselves.)

                                  Björn

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • björn
                                  ... Yes, I recognize the problem. The last time I saw this problem it was because a malformed .viminfo file caused Vim to output an error message and wait for
                                  Message 16 of 23 , Aug 1 2:17 PM
                                  • 0 Attachment
                                    2008/8/1 <dv1445@...>:
                                    >
                                    > Thus spake björn [08/01/08 @ 21.52.18 +0200]:
                                    >> The public repo now contains the "quickstart" feature but it is
                                    >> disabled by default because I have noticed intermittent (but rare)
                                    >> problems with opening/closing windows (nothing fatal, just annoying
                                    >> log messages and problems with windows never opening). Despite this I
                                    >> myself have it enabled all the time and it is working fine under
                                    >> normal circumstances. To enable, open up Terminal and enter
                                    >>
                                    >> defaults write org.vim.MacVim MMPreloadCacheSize 2
                                    >
                                    > Ah, I just noticed that when MacVim occasionally fails to open a new window (one of the minor problems mentioned above), it still *thinks* they're open. To see this, just try Cmd-Q after a failed open when no windows are visible. MacVim gives a dialog that says something like "are you sure you want to quit even with 2 windows still open?".

                                    Yes, I recognize the problem. The last time I saw this problem it was
                                    because a malformed .viminfo file caused Vim to output an error
                                    message and wait for the user to press a key. This happened before
                                    the window was actually displayed so it kept waiting forever with no
                                    way of getting out of this deadlock. Do you think you can figure out
                                    if there is something similar happening for you? (I only ask, because
                                    I could not reliably recreate the problem with the steps you
                                    outlined.)

                                    By the way, I'm glad you like this feature....hopefully I'll be able
                                    to sort out the problems with it.

                                    (Oh, in case this wasn't clear from my other post: the "Force New
                                    Window" menu is hidden on purpose since it was only put in there as a
                                    temporary measure and I really want to get rid of it.)

                                    Björn

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • Ben Schmidt
                                    ... I agree that it really needs to be completely transparent and with no side effects if it is to be enabled by default. 1. Do we have any real evidence of
                                    Message 17 of 23 , Aug 1 6:02 PM
                                    • 0 Attachment
                                      >> is the 0.4 seconds less startup-time really worth the conceptual
                                      >> overhead of another menu entry and another keyboard shortcut? Worse,
                                      >> the new keyboard entry really only exposes implementation details.
                                      >> Currently, the "Force new window" is hidden behind the "New window"
                                      >> item, so users have no chance of discovering it (and chances that
                                      >> users understand what that does are really low, even if they find it.
                                      >> "New uncached window" is slightly better, but not much). The menu item
                                      >> is even there if preloading is disabled.
                                      >>
                                      >> I understand that you put a lot of work into this, but I'd vote
                                      >> against having a MMPreloadCacheSize value greater than 0 by default.
                                      >> That means most people won't use this functionality, but it also means
                                      >> that less people will be confused why changes in their _vimrc are not
                                      >> picked up or why newly installed plugins are not recognized.
                                      >
                                      > As you may or may not have guessed, these are more or less exactly the
                                      > reasons why this feature is disabled by default. Until I manage to
                                      > resolve the current problems this is how I intend to keep things
                                      > (although I will try to completely get rid of the above mentioned menu
                                      > entry if the cache size is 0). I strongly dislike the added menu
                                      > entry and am at a bit of a loss as to what can be done to get rid of
                                      > it. I really want this feature to be transparent to the user -- if I
                                      > can't make it that way it will most likely stay disabled indefinitely.
                                      >
                                      > However, I think you underestimate the "psychological" effects of
                                      > getting rid of the loading times. I know that if I hadn't written
                                      > MacVim myself I would frown upon the fact that there is a delay
                                      > between pressing Cmd-n and a window appearing (hey, it's instantaneous
                                      > in pretty much every other app). If somebody then told be the reason
                                      > why this happens I would probably go "aha" and forget about the
                                      > delay. Also, as gmn mentioned, opening a new window can take a lot
                                      > longer than .4 s on older hardware (something that will make less and
                                      > less of a difference as time passes and people upgrade, but...).

                                      I agree that it really needs to be completely transparent and with no
                                      side effects if it is to be enabled by default.

                                      1. Do we have any real evidence of what the bottleneck is? Are we
                                      assuming it's the loading of the rc files when it's some other aspect of
                                      startup which can be optimised without the side effects that occur if we
                                      pre-read rc files, or at least where we could get the same benefit by
                                      optimising something else? My experience is that often the first
                                      instance takes close to a second, but after that (presumably because
                                      files are cached) it only takes about 0.35 seconds. (This is without
                                      quickstart.) But in the terminal, where almost as many rc files are read
                                      (no menus, but otherwise pretty much the same), it takes something like
                                      0.15 seconds (after they're cached). So, apart from a cold start, on
                                      this evidence, the non-menu rc file reading at worst can account for
                                      0.15 seconds of loading time, and thus a very insignificant speed up. If
                                      larger differences are seen in MacVim, perhaps it's an indication that
                                      :menu commands should be optimised.

                                      2. Could a compromise be something like this: when you choose New
                                      Window, MacVim immediately opens a new GUI window, but with no content
                                      (just a grey background or something); that window is just a placeholder
                                      waiting for a Vim process. Then alter MacVim so that when a Vim process
                                      connects to it, it uses an existing 'waiting' window if one exists, and
                                      if not, opens a new one (so mvim would still work, etc.). There would be
                                      no need to associate waiting windows with specific Vim processes--any
                                      Vim process could get assigned to any waiting window and it wouldn't
                                      matter. The point is that the user would get immediate visual feedback
                                      that they'd successfully pressed Command-N/chosen the menu item, even
                                      though the Vim process would take a little while to load before the
                                      window gets content. It acts like a "Loading. Please wait." message but
                                      without the tackiness. Much like starting an app in OS X--you get the
                                      immediate feedback of the bouncing dock icon, and once you see that,
                                      you're happy to wait for the app to appear: you know it's on its way.
                                      What's more, if MacVim has a bunch of GUI initialisation that needs to
                                      be done and can be done independently of Vim, it could happen in
                                      parallel with Vim startup this way which might help, too, particularly
                                      when Vim is blocking for file reads.

                                      > The biggest reason why I am pushing this patch is not the quickstart
                                      > but the added file opening options in the preferences panel (I posted
                                      > some screenshots a while back). Still, it would be nice if some of
                                      > you would pull and try it out a bit (and enable quickstart).

                                      OK, I'll give it a go. Pulling is much easier than dealing with all that
                                      patch stuff, which I still haven't managed. And the repo should be
                                      smaller now, so I can reclone and still not lose too much disk space.

                                      Ben.



                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_mac" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    • björn
                                      ... I don t think menu loading slows things down that much since disabling all menu loading did not noticeably cut down on the startup times. I could be wrong
                                      Message 18 of 23 , Aug 2 2:56 AM
                                      • 0 Attachment
                                        2008/8/2 Ben Schmidt <mail_ben_schmidt@...>:
                                        >
                                        > 1. Do we have any real evidence of what the bottleneck is? Are we
                                        > assuming it's the loading of the rc files when it's some other aspect of
                                        > startup which can be optimised without the side effects that occur if we
                                        > pre-read rc files, or at least where we could get the same benefit by
                                        > optimising something else? My experience is that often the first
                                        > instance takes close to a second, but after that (presumably because
                                        > files are cached) it only takes about 0.35 seconds. (This is without
                                        > quickstart.) But in the terminal, where almost as many rc files are read
                                        > (no menus, but otherwise pretty much the same), it takes something like
                                        > 0.15 seconds (after they're cached). So, apart from a cold start, on
                                        > this evidence, the non-menu rc file reading at worst can account for
                                        > 0.15 seconds of loading time, and thus a very insignificant speed up. If
                                        > larger differences are seen in MacVim, perhaps it's an indication that
                                        > :menu commands should be optimised.

                                        I don't think menu loading slows things down that much since disabling
                                        all menu loading did not noticeably cut down on the startup times. I
                                        could be wrong since I did not test this very carefully (and I did a
                                        while back).

                                        > 2. Could a compromise be something like this: when you choose New
                                        > Window, MacVim immediately opens a new GUI window, but with no content
                                        > (just a grey background or something); that window is just a placeholder
                                        > waiting for a Vim process. Then alter MacVim so that when a Vim process
                                        > connects to it, it uses an existing 'waiting' window if one exists, and
                                        > if not, opens a new one (so mvim would still work, etc.). There would be
                                        > no need to associate waiting windows with specific Vim processes--any
                                        > Vim process could get assigned to any waiting window and it wouldn't
                                        > matter. The point is that the user would get immediate visual feedback
                                        > that they'd successfully pressed Command-N/chosen the menu item, even
                                        > though the Vim process would take a little while to load before the
                                        > window gets content. It acts like a "Loading. Please wait." message but
                                        > without the tackiness. Much like starting an app in OS X--you get the
                                        > immediate feedback of the bouncing dock icon, and once you see that,
                                        > you're happy to wait for the app to appear: you know it's on its way.
                                        > What's more, if MacVim has a bunch of GUI initialisation that needs to
                                        > be done and can be done independently of Vim, it could happen in
                                        > parallel with Vim startup this way which might help, too, particularly
                                        > when Vim is blocking for file reads.

                                        This is something I have been thinking about too and it doesn't seem
                                        like such a bad idea. The only thing that stopped me from going down
                                        this road was that I'm not sure what the initial window size should
                                        be. It will probably look silly if the window has to resize as soon
                                        as the Vim process finishes loading. Also, if the :winpos command is
                                        implemented, the window may also "jump" when the process finishes
                                        loading. These two issues makes me wonder if this solution is ever
                                        going to work very well.

                                        Björn

                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_mac" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • Ben Schmidt
                                        ... OK. My MacVim clone/convert/etc. was taking ages so I left it unattended and then forgot about it, but I ve got it moving again now, so soon I ll be able
                                        Message 19 of 23 , Aug 2 3:26 AM
                                        • 0 Attachment
                                          björn wrote:
                                          > 2008/8/2 Ben Schmidt <mail_ben_schmidt@...>:
                                          >> 1. Do we have any real evidence of what the bottleneck is? Are we
                                          >> assuming it's the loading of the rc files when it's some other aspect of
                                          >> startup which can be optimised without the side effects that occur if we
                                          >> pre-read rc files, or at least where we could get the same benefit by
                                          >> optimising something else? My experience is that often the first
                                          >> instance takes close to a second, but after that (presumably because
                                          >> files are cached) it only takes about 0.35 seconds. (This is without
                                          >> quickstart.) But in the terminal, where almost as many rc files are read
                                          >> (no menus, but otherwise pretty much the same), it takes something like
                                          >> 0.15 seconds (after they're cached). So, apart from a cold start, on
                                          >> this evidence, the non-menu rc file reading at worst can account for
                                          >> 0.15 seconds of loading time, and thus a very insignificant speed up. If
                                          >> larger differences are seen in MacVim, perhaps it's an indication that
                                          >> :menu commands should be optimised.
                                          >
                                          > I don't think menu loading slows things down that much since disabling
                                          > all menu loading did not noticeably cut down on the startup times. I
                                          > could be wrong since I did not test this very carefully (and I did a
                                          > while back).

                                          OK. My MacVim clone/convert/etc. was taking ages so I left it unattended
                                          and then forgot about it, but I've got it moving again now, so soon I'll
                                          be able to see the snappiness of that patch with my own eyes. Still, I
                                          wonder why (1) the preloading makes such a large difference and (2) it's
                                          so much slower in MacVim vs. console Vim anyway. It sure would be nice
                                          to really know for sure what the bottleneck is.

                                          >> 2. Could a compromise be something like this: when you choose New
                                          >> Window, MacVim immediately opens a new GUI window, but with no content
                                          >> (just a grey background or something); that window is just a placeholder
                                          >> waiting for a Vim process. Then alter MacVim so that when a Vim process
                                          >> connects to it, it uses an existing 'waiting' window if one exists, and
                                          >> if not, opens a new one (so mvim would still work, etc.). There would be
                                          >> no need to associate waiting windows with specific Vim processes--any
                                          >> Vim process could get assigned to any waiting window and it wouldn't
                                          >> matter. The point is that the user would get immediate visual feedback
                                          >> that they'd successfully pressed Command-N/chosen the menu item, even
                                          >> though the Vim process would take a little while to load before the
                                          >> window gets content. It acts like a "Loading. Please wait." message but
                                          >> without the tackiness. Much like starting an app in OS X--you get the
                                          >> immediate feedback of the bouncing dock icon, and once you see that,
                                          >> you're happy to wait for the app to appear: you know it's on its way.
                                          >> What's more, if MacVim has a bunch of GUI initialisation that needs to
                                          >> be done and can be done independently of Vim, it could happen in
                                          >> parallel with Vim startup this way which might help, too, particularly
                                          >> when Vim is blocking for file reads.
                                          >
                                          > This is something I have been thinking about too and it doesn't seem
                                          > like such a bad idea. The only thing that stopped me from going down
                                          > this road was that I'm not sure what the initial window size should
                                          > be. It will probably look silly if the window has to resize as soon
                                          > as the Vim process finishes loading. Also, if the :winpos command is
                                          > implemented, the window may also "jump" when the process finishes
                                          > loading. These two issues makes me wonder if this solution is ever
                                          > going to work very well.

                                          I personally don't think window jumping/resizing is a problem,
                                          particularly since it would only occur with user intervention (i.e. if
                                          you installed a plugin to make use of winpos/columns/lines or use them
                                          in your vimrc or such). I'm sure I see other apps do this to their
                                          windows, too, and it doesn't bother me; I can't think of an example off
                                          the top of my head, though, and it may well not be a native Mac app.
                                          Where does MacVim get the size from currently? The lines and columns
                                          options, along with the guifont? I think it's fair enough to use either
                                          the lines, columns and font from the previously opened window, or
                                          (Mac)Vim defaults for this and let it change when Vim connects if
                                          necessary.

                                          Another option would be showing a small progress window (e.g. one of
                                          those stripy progress bars) that then expands to full size when Vim
                                          connects. I'd suggest still making that small progress window the actual
                                          MacVim window, though, so that any Cocoa initialisation, etc. can be
                                          done on that window, rather than needing to close that one and open a
                                          new one when Vim connects. Though perhaps initialising a hidden window
                                          and showing a generic progress window is another option.

                                          Ben.



                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_mac" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • dv1445@wayne.edu
                                          ... Hmmm... well, I certainly don t just forget about the delay, and I knew pretty early on from this list that the delay couldn t be fixed. Perhaps I m a
                                          Message 20 of 23 , Aug 2 8:47 AM
                                          • 0 Attachment
                                            Thus spake Ben Schmidt [08/02/08 @ 11.02.24 +1000]:
                                            > > If somebody then told be the reason why this happens I would probably go
                                            > > "aha" and forget about the delay.
                                            > > Also, as gmn mentioned, opening a new window can take a lot longer than .4
                                            > > s on older hardware (something that will make less and less of a difference
                                            > > as time passes and people upgrade, but...).

                                            Hmmm... well, I certainly don't just forget about the delay, and I knew pretty early on from this list that the delay couldn't be fixed. Perhaps I'm a special case because of older hardware. The delay, for instance, can be up to 2.5 seconds here, and is never less than about 1.5. But with quickstart: snappy!

                                            (Side note: I think that knowing that nothing can be done about some negative aspect of a program is more conducive to giving up on it, not less so. If I know that work is being done and eventually it will improve, I'm more likely to stick it out. Case in point: the slow rendering in MacVim. I know people are working on a fast one, so that makes it worthwhile to stick with MacVim [even if there weren't other good reasons to stick with it].)

                                            > I agree that it really needs to be completely transparent and with no
                                            > side effects if it is to be enabled by default.

                                            I agree too, especially if it's mainly people like me with rusty G4's who hate the lag. (That said, rusty G4's can still run TextWrangler with zero delays. And how come Carbon Vim runs with no lags?).

                                            > 1. Do we have any real evidence of what the bottleneck is? Are we
                                            > assuming it's the loading of the rc files when it's some other aspect of
                                            > startup which can be optimised without the side effects that occur if we
                                            > pre-read rc files, or at least where we could get the same benefit by
                                            > optimising something else? My experience is that often the first
                                            > instance takes close to a second, but after that (presumably because
                                            > files are cached) it only takes about 0.35 seconds. (This is without
                                            > quickstart.) But in the terminal, where almost as many rc files are read
                                            > (no menus, but otherwise pretty much the same), it takes something like
                                            > 0.15 seconds (after they're cached). So, apart from a cold start, on
                                            > this evidence, the non-menu rc file reading at worst can account for
                                            > 0.15 seconds of loading time, and thus a very insignificant speed up. If
                                            > larger differences are seen in MacVim, perhaps it's an indication that
                                            > :menu commands should be optimised.

                                            I don't notice an increase in snappiness when I move my ~/.vim stuff out of the way. But I don't have much in there besides colorschemes and NERDTree.

                                            > 2. Could a compromise be something like this: when you choose New
                                            > Window, MacVim immediately opens a new GUI window, but with no content
                                            > (just a grey background or something); that window is just a placeholder
                                            > waiting for a Vim process. Then alter MacVim so that when a Vim process
                                            > connects to it, it uses an existing 'waiting' window if one exists, and
                                            > if not, opens a new one (so mvim would still work, etc.). There would be
                                            > no need to associate waiting windows with specific Vim processes--any
                                            > Vim process could get assigned to any waiting window and it wouldn't
                                            > matter. The point is that the user would get immediate visual feedback
                                            > that they'd successfully pressed Command-N/chosen the menu item, even
                                            > though the Vim process would take a little while to load before the
                                            > window gets content. It acts like a "Loading. Please wait." message but
                                            > without the tackiness. Much like starting an app in OS X--you get the
                                            > immediate feedback of the bouncing dock icon, and once you see that,
                                            > you're happy to wait for the app to appear: you know it's on its way.

                                            I don't see the benefit of this. It's the lag that's annoying, and it doesn't get any shorter when one is notified that a lag is underway. I don't think I've ever wondered whether I *really* pressed cmd-N. NeoOffice, for instance, has a splash screen with a progress bar inside of it, and it's sluggishness is no more tolerable for it.

                                            Besides, we *do* get visual notification that cmd-N has been pressed: the word "File" in the menubar gets highlighted in blue (or "graphite", if that's your pref).

                                            Quickstart-enabled MacVim seems to solve the problem nicely, and will be even better when the little issues get ironed out. If people are really opposed to it lurking there, perhaps it can be a compile-time option.
                                            -gmn



                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_mac" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • Matt Tolton
                                            ... I disagree here. I think that it would be a bit odd to have the window jump around/resize after it opened up. I can t think of a single app that I use
                                            Message 21 of 23 , Aug 2 12:20 PM
                                            • 0 Attachment
                                              > I personally don't think window jumping/resizing is a problem,
                                              > particularly since it would only occur with user intervention (i.e. if
                                              > you installed a plugin to make use of winpos/columns/lines or use them
                                              > in your vimrc or such). I'm sure I see other apps do this to their
                                              > windows, too, and it doesn't bother me; I can't think of an example off
                                              > the top of my head, though, and it may well not be a native Mac app.

                                              I disagree here. I think that it would be a bit odd to have the
                                              window jump around/resize after it opened up. I can't think of a
                                              single app that I use that does that.

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_mac" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • dv1445@wayne.edu
                                              ... I can: MacVim! :) Look at what happens when you go into fullscreen mode. Your starting normal sized MacVim window centers itself on the screen, then
                                              Message 22 of 23 , Aug 2 1:42 PM
                                              • 0 Attachment
                                                Thus spake Matt Tolton [08/02/08 @ 12.20.48 -0700]:
                                                >
                                                > > I personally don't think window jumping/resizing is a problem,
                                                > > particularly since it would only occur with user intervention (i.e. if
                                                > > you installed a plugin to make use of winpos/columns/lines or use them
                                                > > in your vimrc or such). I'm sure I see other apps do this to their
                                                > > windows, too, and it doesn't bother me; I can't think of an example off
                                                > > the top of my head, though, and it may well not be a native Mac app.
                                                >
                                                > I disagree here. I think that it would be a bit odd to have the
                                                > window jump around/resize after it opened up. I can't think of a
                                                > single app that I use that does that.

                                                I can: MacVim! :)

                                                Look at what happens when you go into fullscreen mode. Your starting "normal" sized MacVim window centers itself on the screen, then resizes itself to span the screen provided you have fuoptions=maxhorz,maxvert. I agree however that this is odd for a Mac app; it's probably unavoidably built into vim.

                                                This is not to defend the idea of what amounts to a splash screen shaped liked a MacVim window; in a previous post I said I didn't see the point. But to be picky, MacVim already has jumparounds. :)
                                                -gmn

                                                --~--~---------~--~----~------------~-------~--~----~
                                                You received this message from the "vim_mac" maillist.
                                                For more information, visit http://www.vim.org/maillist.php
                                                -~----------~----~----~----~------~----~------~--~---
                                              • Matt Tolton
                                                ... Actually, I can t duplicate this behavior. I see no jumpiness. I see the screen fade to black, and then the macvim window fades in spread across the
                                                Message 23 of 23 , Aug 2 2:18 PM
                                                • 0 Attachment
                                                  > I can: MacVim! :)
                                                  >
                                                  > Look at what happens when you go into fullscreen mode. Your starting "normal" sized MacVim window centers itself on the screen, then resizes itself to span the screen provided you have fuoptions=maxhorz,maxvert. I agree however that this is odd for a Mac app; it's probably unavoidably built into vim.
                                                  >
                                                  > This is not to defend the idea of what amounts to a splash screen shaped liked a MacVim window; in a previous post I said I didn't see the point. But to be picky, MacVim already has jumparounds. :)

                                                  Actually, I can't duplicate this behavior. I see no jumpiness. I see
                                                  the screen fade to black, and then the macvim window fades in spread
                                                  across the entire screen. So...to be picky...my statement stands. :)

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