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

Re: fullscreen sluggish

Expand Messages
  • dv1445@wayne.edu
    ... My fuoptions are maxvert, maxhorz. It happens on all kinds of files. And also on the empty window. And also on a 13 Macbook, so it s not just my
    Message 1 of 26 , May 9, 2008
    • 0 Attachment
      Thus spake Nico Weber [05/09/08 @ 12.16.57 +0200]:
      > > I just git-pulled about 20 minutes ago, glad to see an update!
      > > However, on this newest build the fullscreen is acting sluggish.
      >
      > it's as smooth as usual over here. What are your fuoptions? What kind
      > of file are you editing? Does it also happen if you enter fullscreen
      > in an empty window (ie. ⌘N ⇧⌘F)?

      My fuoptions are maxvert, maxhorz. It happens on all kinds of files. And also on the empty window. And also on a 13" Macbook, so it's not just my platform.

      I tried a bunch of different colorschemes, but it never varies.
      -gmn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • dv1445@wayne.edu
      ... I just did some testing with the fuoptions. That annoying sequence happens also with fuoptions=maxvert, but not with fuoptions=maxhorz. Of course, the
      Message 2 of 26 , May 9, 2008
      • 0 Attachment
        Thus spake Nico Weber [05/09/08 @ 12.16.57 +0200]:
        > > I just git-pulled about 20 minutes ago, glad to see an update!
        > > However, on this newest build the fullscreen is acting sluggish.
        >
        > it's as smooth as usual over here. What are your fuoptions? What kind
        > of file are you editing? Does it also happen if you enter fullscreen
        > in an empty window (ie. ⌘N ⇧⌘F)?

        I just did some testing with the fuoptions. That annoying sequence happens also with fuoptions=maxvert, but not with fuoptions=maxhorz. Of course, the original combo of fuoptions=maxhorz,maxvert causes the sequence too. So it looks like something with maxvert.
        -gmn

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Nico Weber
        Hi, ... I still cannot see this. I skimmed through the recent code changes, and I couldn t find anything that could ve caused this, either. Does it also happen
        Message 3 of 26 , May 10, 2008
        • 0 Attachment
          Hi,

          > I just did some testing with the fuoptions. That annoying sequence
          > happens also with fuoptions=maxvert, but not with
          > fuoptions=maxhorz. Of course, the original combo of
          > fuoptions=maxhorz,maxvert causes the sequence too. So it looks like
          > something with maxvert.

          I still cannot see this. I skimmed through the recent code changes,
          and I couldn't find anything that could've caused this, either. Does
          it also happen if you temporarily remove your _vimrc/_gvimrc?

          Nico


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... I am also stumped...nothing that was recently added should cause this. Also, I cannot reproduce it (I ve tried Intel/Leopard, PPC/Tiger). The PPC is an
          Message 4 of 26 , May 10, 2008
          • 0 Attachment
            2008/5/10 Nico Weber <nicolasweber@...>:
            >
            > Hi,
            >
            >> I just did some testing with the fuoptions. That annoying sequence
            >> happens also with fuoptions=maxvert, but not with
            >> fuoptions=maxhorz. Of course, the original combo of
            >> fuoptions=maxhorz,maxvert causes the sequence too. So it looks like
            >> something with maxvert.
            >
            > I still cannot see this. I skimmed through the recent code changes,
            > and I couldn't find anything that could've caused this, either. Does
            > it also happen if you temporarily remove your _vimrc/_gvimrc?

            I am also stumped...nothing that was recently added should cause this.
            Also, I cannot reproduce it (I've tried Intel/Leopard, PPC/Tiger).
            The PPC is an iBook 1.33 GHz so it does not seem related to how
            fast/slow the CPU is.

            Can you try moving your .vimrc/.gvimrc out of the way and see if it
            still happens with a blank window?

            Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • dv1445@wayne.edu
            ... I renamed .gvimrc and tested. With all permutations of fuoptions, MacVim still goes through the shorter of the two sequences I mentioned in the first
            Message 5 of 26 , May 10, 2008
            • 0 Attachment
              Thus spake Nico Weber [05/10/08 @ 11.14.14 +0200]:
              > > I just did some testing with the fuoptions. That annoying sequence
              > > happens also with fuoptions=maxvert, but not with
              > > fuoptions=maxhorz. Of course, the original combo of
              > > fuoptions=maxhorz,maxvert causes the sequence too. So it looks like
              > > something with maxvert.
              >
              > I still cannot see this. I skimmed through the recent code changes,
              > and I couldn't find anything that could've caused this, either. Does
              > it also happen if you temporarily remove your _vimrc/_gvimrc?

              I renamed .gvimrc and tested. With all permutations of fuoptions, MacVim still goes through the shorter of the two sequences I mentioned in the first message of this thread. However, it goes through that sequence more quickly with .gvimrc out of the way.

              (Although, I think I found a different bug while doing this testing. Namely, MacVim with no .gvimrc starts up at size 80x24. If I set fuoptions to maxhorz or maxhorz-and-maxvert, then if I go to fullscreen and then leave fullscreen, MacVim is no longer at 80x24. Rather, it's at screen-width x 24. Maxhorz is sticking when it shouldn't. Strangely, this problem does not appear when my .gvimrc is in place, and when my set co/lines commands in it are commented out.)

              I also determined that placement of the "set fuoptions" in my .gvimrc --- i.e., first line, last line, middle --- does not affect the sequence of flickering and apparent redraws.

              Also, renaming .vimrc has no effect.

              In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen

              As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
              -gmn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... It would be tremendously helpful if you could (re-)confirm this by checking out and compiling both the commit before that one and that commit itself, then
              Message 6 of 26 , May 10, 2008
              • 0 Attachment
                2008/5/10 <dv1445@...>:
                >
                > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                >
                > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.

                It would be tremendously helpful if you could (re-)confirm this by
                checking out and compiling both the commit before that one and that
                commit itself, then see if there is any difference between the two.
                I'm sorry to have to ask this of you, but I have no other option since
                I can't recreate the problem myself.

                Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • dv1445@wayne.edu
                ... Yep, I ll do this, but I don t know how to go back and get old versions. -gmn --~--~---------~--~----~------------~-------~--~----~ You received this
                Message 7 of 26 , May 10, 2008
                • 0 Attachment
                  Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                  > > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                  > >
                  > > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                  >
                  > It would be tremendously helpful if you could (re-)confirm this by
                  > checking out and compiling both the commit before that one and that
                  > commit itself, then see if there is any difference between the two.
                  > I'm sorry to have to ask this of you, but I have no other option since
                  > I can't recreate the problem myself.

                  Yep, I'll do this, but I don't know how to go back and get old versions.
                  -gmn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... Great. You should be able to checkout an old commit to a new branch and switch to that branch all in one go by typing git-checkout -b old fdcce91b That
                  Message 8 of 26 , May 10, 2008
                  • 0 Attachment
                    2008/5/10 <dv1445@...>:
                    >
                    > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                    >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                    >> >
                    >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                    >>
                    >> It would be tremendously helpful if you could (re-)confirm this by
                    >> checking out and compiling both the commit before that one and that
                    >> commit itself, then see if there is any difference between the two.
                    >> I'm sorry to have to ask this of you, but I have no other option since
                    >> I can't recreate the problem myself.
                    >
                    > Yep, I'll do this, but I don't know how to go back and get old versions.
                    > -gmn

                    Great. You should be able to checkout an old commit to a new branch
                    and switch to that branch all in one go by typing

                    git-checkout -b old fdcce91b

                    That command would create a branch called "old" from the commit
                    starting with fdcce91b (that's the commit "Only cascade from windows
                    belonging to Vim process") and switch to that branch. You only need
                    to type the beginning of the commit id and not all of it.

                    When you're done with that one you can create another branch for the
                    commit after in a similar manner.

                    Finally, to get rid of the branches you've created:

                    git-checkout master
                    git-branch -d old
                    ...

                    Let me know if you need more help.

                    Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • dv1445@wayne.edu
                    ... Until I know how to get old commits with git, I downloaded old snapshots from around that time. Snap24 doesn t allow fuoptions. Snap25 does, and the
                    Message 9 of 26 , May 10, 2008
                    • 0 Attachment
                      Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                      > > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                      > >
                      > > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                      >
                      > It would be tremendously helpful if you could (re-)confirm this by
                      > checking out and compiling both the commit before that one and that
                      > commit itself, then see if there is any difference between the two.
                      > I'm sorry to have to ask this of you, but I have no other option since
                      > I can't recreate the problem myself.

                      Until I know how to get old commits with git, I downloaded old snapshots from around that time. Snap24 doesn't allow fuoptions. Snap25 does, and the "sequence" is present there, too. So it must have been around even before the commit that fixed the starting window position.

                      In a previous message, I said I found a side-bug in which maxhorz sticks even after exit of fullscreen. In Snap25, max*vert* sticks in this manner.

                      I did some experimenting with the latest git pull. If I set lines=10, and then enter fullscreen, the "sequence" occurs, but the statusline position flickers way up high (where it would be if lines=10 and the window anchored in the northwest corner of the screen) before going to where it should be. I think that in going to fullscreen, MacVim is first extending its spread horizontally, leaving the status line "up high", then flickering, then extending its spread vertically, ending up in the proper position. So going to fullscreen is like first doing 'set co=the screenwidth', and then separately doing 'set lines=the screen height', but not fast enough to make it look like one big move. Perhaps if MacVim could first figure out what its lines and columns should be, and then do 'set lines=x co=y' in one step?
                      -gmn

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • dv1445@wayne.edu
                      ... OK, I did that. ... How do I switch to the branch old ? I tried git pull after doing the step above, but git complained that I didn t specify which
                      Message 10 of 26 , May 10, 2008
                      • 0 Attachment
                        Thus spake björn [05/10/08 @ 21.38.19 +0200]:
                        > > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                        > >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                        > >> >
                        > >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                        > >>
                        > >> It would be tremendously helpful if you could (re-)confirm this by
                        > >> checking out and compiling both the commit before that one and that
                        > >> commit itself, then see if there is any difference between the two.
                        > >> I'm sorry to have to ask this of you, but I have no other option since
                        > >> I can't recreate the problem myself.
                        > >
                        > > Yep, I'll do this, but I don't know how to go back and get old versions.
                        > > -gmn
                        >
                        > Great. You should be able to checkout an old commit to a new branch
                        > and switch to that branch all in one go by typing
                        >
                        > git-checkout -b old fdcce91b

                        OK, I did that.


                        > That command would create a branch called "old" from the commit
                        > starting with fdcce91b (that's the commit "Only cascade from windows
                        > belonging to Vim process") and switch to that branch. You only need
                        > to type the beginning of the commit id and not all of it.

                        How do I "switch" to the branch "old"? I tried git pull after doing the step above, but git complained that I didn't specify which branch I want to pull. I have no idea how to do so.
                        -gmn

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • björn
                        ... You use git-checkout to switch branches...so git-checkout old goes to the branch named old . There is no need to pull anything, that s only to update
                        Message 11 of 26 , May 10, 2008
                        • 0 Attachment
                          2008/5/10 <dv1445@...>:
                          >
                          > Thus spake björn [05/10/08 @ 21.38.19 +0200]:
                          >> > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                          >> >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                          >> >> >
                          >> >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                          >> >>
                          >> >> It would be tremendously helpful if you could (re-)confirm this by
                          >> >> checking out and compiling both the commit before that one and that
                          >> >> commit itself, then see if there is any difference between the two.
                          >> >> I'm sorry to have to ask this of you, but I have no other option since
                          >> >> I can't recreate the problem myself.
                          >> >
                          >> > Yep, I'll do this, but I don't know how to go back and get old versions.
                          >> > -gmn
                          >>
                          >> Great. You should be able to checkout an old commit to a new branch
                          >> and switch to that branch all in one go by typing
                          >>
                          >> git-checkout -b old fdcce91b
                          >
                          > OK, I did that.
                          >
                          >
                          >> That command would create a branch called "old" from the commit
                          >> starting with fdcce91b (that's the commit "Only cascade from windows
                          >> belonging to Vim process") and switch to that branch. You only need
                          >> to type the beginning of the commit id and not all of it.
                          >
                          > How do I "switch" to the branch "old"? I tried git pull after doing the step above, but git complained that I didn't specify which branch I want to pull. I have no idea how to do so.
                          > -gmn

                          You use git-checkout to switch branches...so "git-checkout old" goes
                          to the branch named "old". There is no need to pull anything, that's
                          only to update to the latest version...git-checkout is all you need to
                          jump between revisions.

                          To summarize (assuming you are on branch 'master'):

                          check out old versions of macvim in branches called old#:
                          git-checkout -b old1 fdcce91b
                          ...build macvim and test...
                          git-checkout -b old2 XXXXXX <-- replace with the SHA1 of the next commit
                          ...build macvim and test...
                          etc.

                          jump between branches:
                          git-checkout old1
                          ...test old1 again...
                          git-checkout old2
                          ...test old2 again...
                          etc.

                          when done:
                          git-checkout master
                          git-branch -d old1 <-- delete branch called old1
                          git-branch -d old2
                          etc.


                          Björn

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • dv1445@wayne.edu
                          ... OK, I did this, but I was unable to build a functioning MacVim. MacVim would start, but no window would appear. -gmn
                          Message 12 of 26 , May 10, 2008
                          • 0 Attachment
                            Thus spake björn [05/10/08 @ 22.16.35 +0200]:
                            >
                            > 2008/5/10 <dv1445@...>:
                            > >
                            > > Thus spake björn [05/10/08 @ 21.38.19 +0200]:
                            > >> > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                            > >> >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                            > >> >> >
                            > >> >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                            > >> >>
                            > >> >> It would be tremendously helpful if you could (re-)confirm this by
                            > >> >> checking out and compiling both the commit before that one and that
                            > >> >> commit itself, then see if there is any difference between the two.
                            > >> >> I'm sorry to have to ask this of you, but I have no other option since
                            > >> >> I can't recreate the problem myself.
                            > >> >
                            > >> > Yep, I'll do this, but I don't know how to go back and get old versions.
                            > >> > -gmn
                            > >>
                            > >> Great. You should be able to checkout an old commit to a new branch
                            > >> and switch to that branch all in one go by typing
                            > >>
                            > >> git-checkout -b old fdcce91b
                            > >
                            > > OK, I did that.
                            > >
                            > >
                            > >> That command would create a branch called "old" from the commit
                            > >> starting with fdcce91b (that's the commit "Only cascade from windows
                            > >> belonging to Vim process") and switch to that branch. You only need
                            > >> to type the beginning of the commit id and not all of it.
                            > >
                            > > How do I "switch" to the branch "old"? I tried git pull after doing the step above, but git complained that I didn't specify which branch I want to pull. I have no idea how to do so.
                            > > -gmn
                            >
                            > You use git-checkout to switch branches...so "git-checkout old" goes
                            > to the branch named "old". There is no need to pull anything, that's
                            > only to update to the latest version...git-checkout is all you need to
                            > jump between revisions.

                            OK, I did this, but I was unable to build a functioning MacVim. MacVim would start, but no window would appear.
                            -gmn

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • björn
                            ... This almost certainly happens because you forgot to pass --enable-gui=macvim to configure. The build sequence is (in vim7/src/ folder): ./configure
                            Message 13 of 26 , May 10, 2008
                            • 0 Attachment
                              2008/5/10 <dv1445@...>:
                              >
                              > Thus spake björn [05/10/08 @ 22.16.35 +0200]:
                              >>
                              >> 2008/5/10 <dv1445@...>:
                              >> >
                              >> > Thus spake björn [05/10/08 @ 21.38.19 +0200]:
                              >> >> > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                              >> >> >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                              >> >> >> >
                              >> >> >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                              >> >> >>
                              >> >> >> It would be tremendously helpful if you could (re-)confirm this by
                              >> >> >> checking out and compiling both the commit before that one and that
                              >> >> >> commit itself, then see if there is any difference between the two.
                              >> >> >> I'm sorry to have to ask this of you, but I have no other option since
                              >> >> >> I can't recreate the problem myself.
                              >> >> >
                              >> >> > Yep, I'll do this, but I don't know how to go back and get old versions.
                              >> >> > -gmn
                              >> >>
                              >> >> Great. You should be able to checkout an old commit to a new branch
                              >> >> and switch to that branch all in one go by typing
                              >> >>
                              >> >> git-checkout -b old fdcce91b
                              >> >
                              >> > OK, I did that.
                              >> >
                              >> >
                              >> >> That command would create a branch called "old" from the commit
                              >> >> starting with fdcce91b (that's the commit "Only cascade from windows
                              >> >> belonging to Vim process") and switch to that branch. You only need
                              >> >> to type the beginning of the commit id and not all of it.
                              >> >
                              >> > How do I "switch" to the branch "old"? I tried git pull after doing the step above, but git complained that I didn't specify which branch I want to pull. I have no idea how to do so.
                              >> > -gmn
                              >>
                              >> You use git-checkout to switch branches...so "git-checkout old" goes
                              >> to the branch named "old". There is no need to pull anything, that's
                              >> only to update to the latest version...git-checkout is all you need to
                              >> jump between revisions.
                              >
                              > OK, I did this, but I was unable to build a functioning MacVim. MacVim would start, but no window would appear.

                              This almost certainly happens because you forgot to pass
                              "--enable-gui=macvim" to configure. The build sequence is (in
                              vim7/src/ folder):

                              ./configure --enable-gui=macvim
                              make clean; make
                              cd MacVim; xcodebuild clean; xcodebuild

                              I've added the two cleaning steps just to be extra cautious.

                              Björn

                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • dv1445@wayne.edu
                              ... I didn t forget to pass it, but I did make a typo. In fact, I did the same typo twice, since I tried building the old branch twice. Sheesh. Testing is
                              Message 14 of 26 , May 10, 2008
                              • 0 Attachment
                                Thus spake björn [05/10/08 @ 22.53.59 +0200]:
                                >
                                > 2008/5/10 <dv1445@...>:
                                > >
                                > > Thus spake björn [05/10/08 @ 22.16.35 +0200]:
                                > >>
                                > >> 2008/5/10 <dv1445@...>:
                                > >> >
                                > >> > Thus spake björn [05/10/08 @ 21.38.19 +0200]:
                                > >> >> > Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                                > >> >> >> > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                                > >> >> >> >
                                > >> >> >> > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                                > >> >> >>
                                > >> >> >> It would be tremendously helpful if you could (re-)confirm this by
                                > >> >> >> checking out and compiling both the commit before that one and that
                                > >> >> >> commit itself, then see if there is any difference between the two.
                                > >> >> >> I'm sorry to have to ask this of you, but I have no other option since
                                > >> >> >> I can't recreate the problem myself.
                                > >> >> >
                                > >> >> > Yep, I'll do this, but I don't know how to go back and get old versions.
                                > >> >> > -gmn
                                > >> >>
                                > >> >> Great. You should be able to checkout an old commit to a new branch
                                > >> >> and switch to that branch all in one go by typing
                                > >> >>
                                > >> >> git-checkout -b old fdcce91b
                                > >> >
                                > >> > OK, I did that.
                                > >> >
                                > >> >
                                > >> >> That command would create a branch called "old" from the commit
                                > >> >> starting with fdcce91b (that's the commit "Only cascade from windows
                                > >> >> belonging to Vim process") and switch to that branch. You only need
                                > >> >> to type the beginning of the commit id and not all of it.
                                > >> >
                                > >> > How do I "switch" to the branch "old"? I tried git pull after doing the step above, but git complained that I didn't specify which branch I want to pull. I have no idea how to do so.
                                > >> > -gmn
                                > >>
                                > >> You use git-checkout to switch branches...so "git-checkout old" goes
                                > >> to the branch named "old". There is no need to pull anything, that's
                                > >> only to update to the latest version...git-checkout is all you need to
                                > >> jump between revisions.
                                > >
                                > > OK, I did this, but I was unable to build a functioning MacVim. MacVim would start, but no window would appear.
                                >
                                > This almost certainly happens because you forgot to pass
                                > "--enable-gui=macvim" to configure. The build sequence is (in
                                > vim7/src/ folder):

                                I didn't forget to pass it, but I did make a typo. In fact, I did the same typo twice, since I tried building the old branch twice. Sheesh. Testing is underway.
                                -gmn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • dv1445@wayne.edu
                                ... I got the checkouts to work, and I see there s no difference between the two. So perhaps I was merely late in noticing the turn to sluggishness? To test
                                Message 15 of 26 , May 10, 2008
                                • 0 Attachment
                                  Thus spake björn [05/10/08 @ 21.06.51 +0200]:
                                  > > In the first message of this thread, I noted that although the annoying sequence just got worse, a less annoying form of it has been around for a while. Just how long? I looked through my archive, and I posted a message about this on April 8: http://article.gmane.org/gmane.editors.vim.mac/3049/match=window+middle+screen
                                  > >
                                  > > As you can see from the link, the apparent problem first appeared when a fix for a separate issue was introduced.
                                  >
                                  > It would be tremendously helpful if you could (re-)confirm this by
                                  > checking out and compiling both the commit before that one and that
                                  > commit itself, then see if there is any difference between the two.
                                  > I'm sorry to have to ask this of you, but I have no other option since
                                  > I can't recreate the problem myself.

                                  I got the checkouts to work, and I see there's no difference between the two. So perhaps I was merely late in noticing the turn to sluggishness? To test that hypothesis, I tried to checkout an even older commit and then apply the original fuoptions patches sent to this list. When I did the git-am, it told me "previous dotest directory .dotest still exists but mbox given", and refused to apply the patch. I tried this with the second round of fuoptions patches, same thing.
                                  -gmn

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Nico Weber
                                  Hi, ... you can probably do `rm -rf .dotest` and then it should work. Else, you can apply the patch by saving it to a file and doing `git apply
                                  Message 16 of 26 , May 10, 2008
                                  • 0 Attachment
                                    Hi,

                                    > I got the checkouts to work, and I see there's no difference between
                                    > the two. So perhaps I was merely late in noticing the turn to
                                    > sluggishness? To test that hypothesis, I tried to checkout an even
                                    > older commit and then apply the original fuoptions patches sent to
                                    > this list. When I did the git-am, it told me "previous dotest
                                    > directory .dotest still exists but mbox given", and refused to apply
                                    > the patch. I tried this with the second round of fuoptions patches,
                                    > same thing.

                                    you can probably do `rm -rf .dotest` and then it should work. Else,
                                    you can apply the patch by saving it to a file and doing `git apply
                                    path/to/patch/file`.

                                    Does that work?

                                    Nico

                                    ps: Could you perhaps do a short screencast of the problem and post a
                                    link to that? Seeing the problem could help us see the cause…


                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • dv1445@wayne.edu
                                    ... No, didn t work, not with either of the fuoptions.zip patches or with 3 different commits in the area of March 12. Kept getting a string of patch does
                                    Message 17 of 26 , May 10, 2008
                                    • 0 Attachment
                                      Thus spake Nico Weber [05/10/08 @ 23.59.12 +0200]:
                                      > > I got the checkouts to work, and I see there's no difference between
                                      > > the two. So perhaps I was merely late in noticing the turn to
                                      > > sluggishness? To test that hypothesis, I tried to checkout an even
                                      > > older commit and then apply the original fuoptions patches sent to
                                      > > this list. When I did the git-am, it told me "previous dotest
                                      > > directory .dotest still exists but mbox given", and refused to apply
                                      > > the patch. I tried this with the second round of fuoptions patches,
                                      > > same thing.
                                      >
                                      > you can probably do `rm -rf .dotest` and then it should work. Else,
                                      > you can apply the patch by saving it to a file and doing `git apply
                                      > path/to/patch/file`.
                                      >
                                      > Does that work?

                                      No, didn't work, not with either of the fuoptions.zip patches or with 3 different commits in the area of March 12. Kept getting a string of "patch does not apply".

                                      > ps: Could you perhaps do a short screencast of the problem and post a
                                      > link to that? Seeing the problem could help us see the cause...

                                      I just poked around for apps that do this. Found one free one, which I can't get to work properly. This is more effort than I can put in.

                                      Thanks for the help.
                                      -gmn

                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_mac" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    • björn
                                      ... Well, that makes sense to me...it would have been more confusing if that commit had made any difference. Thank you for putting in the effort to try these
                                      Message 18 of 26 , May 11, 2008
                                      • 0 Attachment
                                        2008/5/10 <dv1445@...>:
                                        >
                                        > I got the checkouts to work, and I see there's no difference between the two. So perhaps I was merely late in noticing the turn to sluggishness?

                                        Well, that makes sense to me...it would have been more confusing if
                                        that commit had made any difference. Thank you for putting in the
                                        effort to try these things out.

                                        I'm still trying to figure out why you see this flickering but me and
                                        Nico don't. Could it be that you have some plugin installed that
                                        interferes? Can you try

                                        mvim --noplugin -u NONE -U NONE

                                        Then type

                                        :set fu

                                        to enter full-screen (Cmd-S-f won't work) and

                                        :set nofu

                                        to exit.

                                        Thanks,
                                        Björn

                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_mac" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • dv1445@wayne.edu
                                        ... OK, I did this but there s no difference. Perhaps some of the problem is my description of the phenomenon. In particular, perhaps ``flicker is the
                                        Message 19 of 26 , May 11, 2008
                                        • 0 Attachment
                                          Thus spake björn [05/11/08 @ 10.44.36 +0200]:
                                          > > I got the checkouts to work, and I see there's no difference between the two. So perhaps I was merely late in noticing the turn to sluggishness?
                                          >
                                          > Well, that makes sense to me...it would have been more confusing if
                                          > that commit had made any difference. Thank you for putting in the
                                          > effort to try these things out.
                                          >
                                          > I'm still trying to figure out why you see this flickering but me and
                                          > Nico don't. Could it be that you have some plugin installed that
                                          > interferes? Can you try
                                          >
                                          > mvim --noplugin -u NONE -U NONE
                                          >
                                          > Then type
                                          >
                                          > :set fu
                                          >
                                          > to enter full-screen (Cmd-S-f won't work) and
                                          >
                                          > :set nofu
                                          >
                                          > to exit.

                                          OK, I did this but there's no difference. Perhaps some of the problem is my description of the phenomenon. In particular, perhaps ``flicker'' is the wrong word.

                                          When I go into fullscreen, what I see is this:
                                          1. The entirety of my screen fades to black.
                                          2. Very quickly MacVim appears ``on top'' of the black, only the status bar is up far higher than it should be. In fact, it's not only higher than where it should be once in fullscreen, it's also higher than it was *before* I even told it to go into fullscreen. I also note that this "too high" statusline does not extend to the full width of the screen, but seems to only be as wide as the pre-fullscreen-command MacVim window (which in my case is 80 columns). However, MacVim *is* covering the full width of the screen at this point. I tested this with colo=morning, so that the black fade of fullscreen would be distinguishable from the ``spreading'' of MacVim. In other words, after the fade to black, my entire screen is light-gray (as per colo=morning) even though the statusline does not extend across the full width of the screen.
                                          3. A fraction of a second later, the status line appears in the proper vertical position, and also spans the full screen width.

                                          I note that sometimes there appears to be a very rapid step 1.5, in which everything is as I said in step 2 except that the short status line is equally high as the status line was before I told MacVim to go fullscreen.

                                          I also note that normally I have MacVim windows start in the northwest-most corner of my screen. I decided to see what'd happen if I made a new MacVim window anchored northeast-most go into fullscreen. Two weird things happened. (1) The statusline was still not spanning the fullwidth in step 2, but instead of extending from the right edge of the screen to 80 columns to the right (as one would expect of a northeasterly anchored window), it extended from the left edge to somewhere shy of the right edge, i.e., 80 columns, exactly as a northwesterly anchored window behaves in this sequence. (2) When I exited fullscreen, the ``maxvert'' setting stuck, and non-fullscreen window went all the way to the bottom of the screen. That's not correct, since it should've returned to my original dimensions, which were 80x41.

                                          Hope this helps.
                                          -gmn

                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_mac" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • Nico Weber
                                          ... If this takes a fraction of a second, then this is somewhat expected. I though you said that it takes several seconds in a former mail. Fractions of
                                          Message 20 of 26 , May 11, 2008
                                          • 0 Attachment
                                            > When I go into fullscreen, what I see is this:
                                            > 1. The entirety of my screen fades to black.
                                            > 2. Very quickly MacVim appears ``on top'' of the black, only the
                                            > status bar is up far higher than it should be. In fact, it's not
                                            > only higher than where it should be once in fullscreen, it's also
                                            > higher than it was *before* I even told it to go into fullscreen. I
                                            > also note that this "too high" statusline does not extend to the
                                            > full width of the screen, but seems to only be as wide as the pre-
                                            > fullscreen-command MacVim window (which in my case is 80 columns).
                                            > However, MacVim *is* covering the full width of the screen at this
                                            > point. I tested this with colo=morning, so that the black fade of
                                            > fullscreen would be distinguishable from the ``spreading'' of
                                            > MacVim. In other words, after the fade to black, my entire screen
                                            > is light-gray (as per colo=morning) even though the statusline does
                                            > not extend across the full width of the screen.
                                            > 3. A fraction of a second later, the status line appears in the
                                            > proper vertical position, and also spans the full screen width.

                                            If this takes a fraction of a second, then this is somewhat expected.
                                            I though you said that it takes several seconds in a former mail.
                                            Fractions of seconds are ok.

                                            I'll see if I can reproduce the other problem.

                                            Nico


                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_mac" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • dv1445@wayne.edu
                                            ... Yes, step three takes a fraction, in that it s between zero and one. The size of the fraction varies, but it s usually more like .75. Plus, that s just
                                            Message 21 of 26 , May 11, 2008
                                            • 0 Attachment
                                              Thus spake Nico Weber [05/11/08 @ 21.24.04 +0200]:
                                              >
                                              > > When I go into fullscreen, what I see is this:
                                              > > 1. The entirety of my screen fades to black.
                                              > > 2. Very quickly MacVim appears ``on top'' of the black, only the
                                              > > status bar is up far higher than it should be. In fact, it's not
                                              > > only higher than where it should be once in fullscreen, it's also
                                              > > higher than it was *before* I even told it to go into fullscreen. I
                                              > > also note that this "too high" statusline does not extend to the
                                              > > full width of the screen, but seems to only be as wide as the pre-
                                              > > fullscreen-command MacVim window (which in my case is 80 columns).
                                              > > However, MacVim *is* covering the full width of the screen at this
                                              > > point. I tested this with colo=morning, so that the black fade of
                                              > > fullscreen would be distinguishable from the ``spreading'' of
                                              > > MacVim. In other words, after the fade to black, my entire screen
                                              > > is light-gray (as per colo=morning) even though the statusline does
                                              > > not extend across the full width of the screen.
                                              > > 3. A fraction of a second later, the status line appears in the
                                              > > proper vertical position, and also spans the full screen width.
                                              >
                                              > If this takes a fraction of a second, then this is somewhat expected.
                                              > I though you said that it takes several seconds in a former mail.
                                              > Fractions of seconds are ok.

                                              Yes, step three takes a fraction, in that it's between zero and one. The size of the fraction varies, but it's usually more like .75. Plus, that's just step three; when the other two are added, the whole sequence is between 1-2 seconds, which is what I originally said. I should have written `less than' instead of `a fraction of', sorry :)

                                              If not much can be done on the specifically MacVim end of things, then if the ``fade'' part of going to fullscreen could be eliminated (or made optional), that would be a big help.

                                              When I recall MacVim not going through this sequence in the past, I must be thinking of the earliest fuoptions patches, before they were included in the main part. Either that or I'm confused.
                                              -gmn

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_mac" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • Nico Weber
                                              ... It s fast over here: http://amnoid.de/tmp/gofull.mov (captured with Snapz Pro, I believe it has a trial period where it s fully functional. For some
                                              Message 22 of 26 , May 11, 2008
                                              • 0 Attachment
                                                > If not much can be done on the specifically MacVim end of things

                                                It's fast over here: http://amnoid.de/tmp/gofull.mov (captured with
                                                Snapz Pro, I believe it has a trial period where it's fully
                                                functional. For some reason, the fade wasn't captured though).

                                                > then if the ``fade'' part of going to fullscreen could be eliminated
                                                > (or made optional), that would be a big help.

                                                The fade takes only a very short amount of time, and I'd rather keep
                                                it in. If it really bothers you, you can remove it from your build by
                                                removing the lines

                                                // fade to black
                                                Boolean didBlend = NO;
                                                CGDisplayFadeReservationToken token;
                                                if (CGAcquireDisplayFadeReservation(.5, &token) ==
                                                kCGErrorSuccess) {
                                                CGDisplayFade(token, .25, kCGDisplayBlendNormal,
                                                kCGDisplayBlendSolidColor, .0, .0, .0, true);
                                                didBlend = YES;
                                                }

                                                and

                                                // fade back in
                                                if (didBlend) {
                                                CGDisplayFade(token, .25, kCGDisplayBlendSolidColor,
                                                kCGDisplayBlendNormal, .0, .0, .0, false);
                                                CGReleaseDisplayFadeReservation(token);
                                                }

                                                from MMFullscreen.m (they are present twice each (the second time,
                                                they look slightly different).

                                                Nico

                                                --~--~---------~--~----~------------~-------~--~----~
                                                You received this message from the "vim_mac" maillist.
                                                For more information, visit http://www.vim.org/maillist.php
                                                -~----------~----~----~----~------~----~------~--~---
                                              • dv1445@wayne.edu
                                                ... That is indeed fast. However, mine is fast too if my fuoptions are not maxhorz,maxvert. (In the movie it looks like only maxvert). The ``sequence is
                                                Message 23 of 26 , May 11, 2008
                                                • 0 Attachment
                                                  Thus spake Nico Weber [05/11/08 @ 22.26.43 +0200]:
                                                  > > If not much can be done on the specifically MacVim end of things
                                                  >
                                                  > It's fast over here: http://amnoid.de/tmp/gofull.mov (captured with
                                                  > Snapz Pro, I believe it has a trial period where it's fully
                                                  > functional. For some reason, the fade wasn't captured though).

                                                  That is indeed fast. However, mine is fast too if my fuoptions are not maxhorz,maxvert. (In the movie it looks like only maxvert). The ``sequence'' is most pronounced with total maximization set. With only maxvert, some steps of the sequence are not there, and the entire remaining sequence occurs so quickly (except the fade) as to not bother me. Same with only maxhorz.

                                                  > The fade takes only a very short amount of time, and I'd rather keep
                                                  > it in. If it really bothers you, you can remove it from your build by
                                                  > removing the lines
                                                  [snip]

                                                  Wow, thanks, I'll try this! Hallelujah (hopefully).
                                                  -gmn

                                                  --~--~---------~--~----~------------~-------~--~----~
                                                  You received this message from the "vim_mac" maillist.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                  -~----------~----~----~----~------~----~------~--~---
                                                • dv1445@wayne.edu
                                                  ... Hallelujah indeed! Much, much better sans fade. The rest of the sequence is still there of course, but I can live with it. Fading makes a huge diff.
                                                  Message 24 of 26 , May 11, 2008
                                                  • 0 Attachment
                                                    Thus spake Nico Weber [05/11/08 @ 22.26.43 +0200]:
                                                    > > then if the ``fade'' part of going to fullscreen could be eliminated
                                                    > > (or made optional), that would be a big help.
                                                    >
                                                    > The fade takes only a very short amount of time, and I'd rather keep
                                                    > it in. If it really bothers you, you can remove it from your build by
                                                    > removing the lines

                                                    Hallelujah indeed! Much, much better sans fade. The rest of the sequence is still there of course, but I can live with it. Fading makes a huge diff.
                                                    -gmn

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