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

Re: too snappy?

Expand Messages
  • 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 1 of 23 , Aug 1, 2008
    • 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 2 of 23 , Aug 1, 2008
      • 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 3 of 23 , Aug 1, 2008
        • 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 4 of 23 , Aug 1, 2008
          • 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 5 of 23 , Aug 1, 2008
            • 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 6 of 23 , Aug 1, 2008
              • 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 7 of 23 , Aug 2, 2008
                • 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 8 of 23 , Aug 2, 2008
                  • 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 9 of 23 , Aug 2, 2008
                    • 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 10 of 23 , Aug 2, 2008
                      • 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 11 of 23 , Aug 2, 2008
                        • 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 12 of 23 , Aug 2, 2008
                          • 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.