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

Re: maxvert doesn't always "maxvert"

Expand Messages
  • Björn Winckler
    ... I seem to have forgotten to reply to this post. Anyway, I tried going through the steps you mention, but failed to reproduce the problem. Does it also
    Message 1 of 17 , Feb 20, 2011
    • 0 Attachment
      On Feb 13, 2011, at 6:57 PM, David Whetstone wrote:

      > Using MacVim snapshot 57 on OS X 10.6.6
      >
      > I've got this in my .gvimrc:
      >
      > set fuoptions=maxhorz,maxvert,background:Normal
      > set fullscreen
      >
      > I like to have my non-fullscreen windows at 90x50, roughly in the center of the screen, and my fullscreen windows to cover the screen (maxhorz, maxvert). However, maxvert doesn't always work.
      >
      > To reproduce:
      >
      > 1. Open MacVim, create one window. (Cmd-N)
      > 2. switch out of fullscreen mode. (Cmd-Shft-F)
      > 3. resize the window to 90x50 and center it.
      > 4. Close MacVim and restart. (Cmd-Q)
      > 5. Create a new window (Cmd-N)
      >
      > This window is perfect. It briefly appears in its 90x50 centered position, then switches to fullscreen, covering the window. If I switch out of fullscreen, it returns to its 90x50 centered position.
      >
      > 6. Create another new window (Cmd-N).
      >
      > This second window shows up in full screen stretched to the width of the screen, but its vertical size is not stretched to the full height of the screen. If I switch out of fullscreen mode, the window keeps these incorrect proportions (basically full width x 50 lines), and when I switch back to fullscreen, it now covers the screen as it should.
      >
      >
      >
      > What do I need to do to make this work? Is there some other setting that I've missed?

      I seem to have forgotten to reply to this post. Anyway, I tried going through the steps you mention, but failed to reproduce the problem. Does it also occur if you don't have "set fullscreen" in you .gvimrc? If so, I think you'll have to leave it that way for now.

      I did notice some weirdness however -- like the normal window showing up before fullscreen is actually entered, which is not supposed to happen. I have put a note in my todo list to take a look at this.

      By the way, one thing you could try is to add the line

      au GUIEnter * set fullscreen

      to your .gvimrc instead of "set fullscreen". If you're lucky that will work and you can use it as a workaround until I get time to look at this.

      Björn

      --
      You received this message from the "vim_mac" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • David Whetstone
      ... Thanks for the reply. Any time I manually make a window fullscreen, it works properly. It s only with set fullscreen that the problem appears, and only
      Message 2 of 17 , Feb 20, 2011
      • 0 Attachment
        On Feb 20, 2011, at 9:47 AM, Björn Winckler wrote:

        > On Feb 13, 2011, at 6:57 PM, David Whetstone wrote:
        >
        >> Using MacVim snapshot 57 on OS X 10.6.6
        >>
        >> I've got this in my .gvimrc:
        >>
        >> set fuoptions=maxhorz,maxvert,background:Normal
        >> set fullscreen
        >>
        >> I like to have my non-fullscreen windows at 90x50, roughly in the center of the screen, and my fullscreen windows to cover the screen (maxhorz, maxvert). However, maxvert doesn't always work.
        >>
        >> To reproduce:
        >>
        >> 1. Open MacVim, create one window. (Cmd-N)
        >> 2. switch out of fullscreen mode. (Cmd-Shft-F)
        >> 3. resize the window to 90x50 and center it.
        >> 4. Close MacVim and restart. (Cmd-Q)
        >> 5. Create a new window (Cmd-N)
        >>
        >> This window is perfect. It briefly appears in its 90x50 centered position, then switches to fullscreen, covering the window. If I switch out of fullscreen, it returns to its 90x50 centered position.
        >>
        >> 6. Create another new window (Cmd-N).
        >>
        >> This second window shows up in full screen stretched to the width of the screen, but its vertical size is not stretched to the full height of the screen. If I switch out of fullscreen mode, the window keeps these incorrect proportions (basically full width x 50 lines), and when I switch back to fullscreen, it now covers the screen as it should.
        >>
        >>
        >>
        >> What do I need to do to make this work? Is there some other setting that I've missed?
        >
        > I seem to have forgotten to reply to this post. Anyway, I tried going through the steps you mention, but failed to reproduce the problem. Does it also occur if you don't have "set fullscreen" in you .gvimrc? If so, I think you'll have to leave it that way for now.
        >
        > I did notice some weirdness however -- like the normal window showing up before fullscreen is actually entered, which is not supposed to happen. I have put a note in my todo list to take a look at this.
        >
        > By the way, one thing you could try is to add the line
        >
        > au GUIEnter * set fullscreen
        >
        > to your .gvimrc instead of "set fullscreen". If you're lucky that will work and you can use it as a workaround until I get time to look at this.
        >
        > Björn

        Thanks for the reply. Any time I manually make a window fullscreen, it works properly. It's only with "set fullscreen" that the problem appears, and only after the first window. "au GUIEnter * set fullscreen" exhibits exactly the same problematic behavior.

        Since you can't reproduce the problem, but I can on demand, I'm willing to look into it further myself if you could just point me to the relevant code. Can't guarantee I'll figure it out, but it can't hurt to have a look.

        Thanks,
        - David

        --
        You received this message from the "vim_mac" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • Björn Winckler
        ... OK, I did not expect there to be any difference. ... That would be great. You should trace the EnterFullscreenMsgID and SetTextDimensionsMsgID messages as
        Message 3 of 17 , Feb 20, 2011
        • 0 Attachment
          On Feb 20, 2011, at 7:09 PM, David Whetstone wrote:
          >
          > Thanks for the reply. Any time I manually make a window fullscreen, it works properly. It's only with "set fullscreen" that the problem appears, and only after the first window. "au GUIEnter * set fullscreen" exhibits exactly the same problematic behavior.

          OK, I did not expect there to be any difference.

          > Since you can't reproduce the problem, but I can on demand, I'm willing to look into it further myself if you could just point me to the relevant code. Can't guarantee I'll figure it out, but it can't hurt to have a look.

          That would be great. You should trace the EnterFullscreenMsgID and SetTextDimensionsMsgID messages as they are handled inside MMVimController. When you enter full screen on startup the actual presentation of the full screen window is delayed -- this happens inside MMWindowController (search for windowPresented). You may also have to look at MMFullscreenWindow, which does the actual resizing of the view when you have maxvert enabled.

          Björn

          --
          You received this message from the "vim_mac" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • David Whetstone
          ... Thanks for the info. Building now. I ll let you know how it goes. -- You received this message from the vim_mac maillist. Do not top-post! Type your
          Message 4 of 17 , Feb 20, 2011
          • 0 Attachment
            On Feb 20, 2011, at 10:20 AM, Björn Winckler wrote:

            > That would be great. You should trace the EnterFullscreenMsgID and SetTextDimensionsMsgID messages as they are handled inside MMVimController. When you enter full screen on startup the actual presentation of the full screen window is delayed -- this happens inside MMWindowController (search for windowPresented). You may also have to look at MMFullscreenWindow, which does the actual resizing of the view when you have maxvert enabled.
            >
            > Björn

            Thanks for the info. Building now. I'll let you know how it goes.

            --
            You received this message from the "vim_mac" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • David Whetstone
            ... Hi Björn, I m still looking into this - but I have a quick question. Is there any specific reason why MMVimController::handleMessage:data: is implemented
            Message 5 of 17 , Feb 20, 2011
            • 0 Attachment
              On Feb 20, 2011, at 10:20 AM, Björn Winckler wrote:

              > That would be great. You should trace the EnterFullscreenMsgID and SetTextDimensionsMsgID messages as they are handled inside MMVimController. When you enter full screen on startup the actual presentation of the full screen window is delayed -- this happens inside MMWindowController (search for windowPresented). You may also have to look at MMFullscreenWindow, which does the actual resizing of the view when you have maxvert enabled.
              >
              > Björn

              Hi Björn,

              I'm still looking into this - but I have a quick question. Is there any specific reason why MMVimController::handleMessage:data: is implemented as a bunch of `if/else if` statements instead of `switch/case`? Also, the msgid parameter is an int, while its value is always (AFAICT) an enum. If I change the type of this parameter to the enum, I can see the mnemonic in the debugger, which is helpful. Would you accept these minor changes if I made them?

              - David

              --
              You received this message from the "vim_mac" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Björn Winckler
              ... No specific reason that I can remember (or think of). However, I d rather avoid changing code unless there is a real problem with it. Björn -- You
              Message 6 of 17 , Feb 21, 2011
              • 0 Attachment
                On Feb 21, 2011, at 3:43 AM, David Whetstone wrote:
                >
                > I'm still looking into this - but I have a quick question. Is there any specific reason why MMVimController::handleMessage:data: is implemented as a bunch of `if/else if` statements instead of `switch/case`? Also, the msgid parameter is an int, while its value is always (AFAICT) an enum. If I change the type of this parameter to the enum, I can see the mnemonic in the debugger, which is helpful. Would you accept these minor changes if I made them?

                No specific reason that I can remember (or think of). However, I'd rather avoid changing code unless there is a real problem with it.

                Björn

                --
                You received this message from the "vim_mac" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • David Whetstone
                ... Ah, that s too bad. I understand not wanting to fix what isn t considered broken, but I d like to make a small attempt to persuade you reconsider. Here
                Message 7 of 17 , Feb 21, 2011
                • 0 Attachment
                  On Feb 21, 2011, at 8:53 AM, Björn Winckler wrote:

                  > No specific reason that I can remember (or think of). However, I'd rather avoid changing code unless there is a real problem with it.
                  >
                  > Björn

                  Ah, that's too bad. I understand not wanting to fix what isn't considered broken, but I'd like to make a small attempt to persuade you reconsider. Here are three reasons why I think it's a good idea:

                  1. A large switch statement is more efficient than an
                  equivalent if-else if ladder (O(1) vs. O(n)).

                  2. Debugging a large switch statement is much less tedious
                  than the if-else ladder, which, unless you know which
                  branch you want ahead of time, requires either a lot of
                  stepping, or a lot of searching for the right branch to
                  in which to set a temporary breakpoint.

                  3. As I previously mentioned, using the enum as a type
                  rather than an int allows the debugger to display the
                  mnemonic rather than a cryptic integer value. In
                  addition, compliers often offer warnings for missing
                  enum values when an enumeration is used as the
                  condition for a switch (e.g. gcc's –Wswitch-enum), as
                  well as warnings for values not in the enumeration.

                  2 and 3 are things that make it easier for people new to the code base (like me) to trace and begin to understand the complex coordination between MacVim and Vim. I think the benefits outweigh the risks for this minor change.

                  Will you reconsider?

                  - David

                  --
                  You received this message from the "vim_mac" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Ben Schmidt
                  ... +1 for the change, from me, though I shouldn t carry much weight. However, these are good reasons, IMHO, and as long as a couple of people read the changes
                  Message 8 of 17 , Feb 21, 2011
                  • 0 Attachment
                    On 22/02/11 7:02 AM, David Whetstone wrote:
                    > On Feb 21, 2011, at 8:53 AM, Björn Winckler wrote:
                    >
                    >> No specific reason that I can remember (or think of). However, I'd rather avoid changing code unless there is a real problem with it.
                    >>
                    >> Björn
                    >
                    > Ah, that's too bad. I understand not wanting to fix what isn't considered broken, but I'd like to make a small attempt to persuade you reconsider. Here are three reasons why I think it's a good idea:
                    >
                    > 1. A large switch statement is more efficient than an
                    > equivalent if-else if ladder (O(1) vs. O(n)).
                    >
                    > 2. Debugging a large switch statement is much less tedious
                    > than the if-else ladder, which, unless you know which
                    > branch you want ahead of time, requires either a lot of
                    > stepping, or a lot of searching for the right branch to
                    > in which to set a temporary breakpoint.
                    >
                    > 3. As I previously mentioned, using the enum as a type
                    > rather than an int allows the debugger to display the
                    > mnemonic rather than a cryptic integer value. In
                    > addition, compliers often offer warnings for missing
                    > enum values when an enumeration is used as the
                    > condition for a switch (e.g. gcc's –Wswitch-enum), as
                    > well as warnings for values not in the enumeration.

                    +1 for the change, from me, though I shouldn't carry much weight.
                    However, these are good reasons, IMHO, and as long as a couple of people
                    read the changes rather than blindly committing them, dumb things
                    shouldn't happen.

                    Ben.



                    --
                    You received this message from the "vim_mac" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  • David Whetstone
                    Björn, Ok, I m swimming in message flows. My hat s off to you for keeping this stuff straight. I ve seen a number of anomalies between when the fullscreen
                    Message 9 of 17 , Feb 21, 2011
                    • 0 Attachment
                      Björn,

                      Ok, I'm swimming in message flows. My hat's off to you for keeping this stuff straight. I've seen a number of anomalies between when the fullscreen window comes up correct and when it doesn't. But I still don't understand enough of the interaction to know if the disparity I see is a cause or an effect of the problem.

                      But one thing that I can point out pretty clearly is somewhat illustrated below. These are two excerpts of logging output. The first one (Good) is what I see when the window shows up correctly, while the second (Borked) is the incorrect version.

                      Good

                      -[MMWindowController enterFullscreen:backgroundColor:]@660: Delay enter full screen
                      -[MMWindowController setTextDimensionsWithRows:columns:isLive:keepOnScreen:]@311: setTextDimensionsWithRows:76 columns:239 isLive:0 keepOnScreen:1
                      -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                      -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                      -[MMFullscreenWindow enterFullscreen]@136: Enter full screen now

                      Borked

                      -[MMWindowController enterFullscreen:backgroundColor:]@660: Delay enter full screen
                      -[MMWindowController setTextDimensionsWithRows:columns:isLive:keepOnScreen:]@311: setTextDimensionsWithRows:80 columns:239 isLive:0 keepOnScreen:1
                      -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                      -[MMVimView(Private) frameSizeMayHaveChanged]@891: Notify Vim that text dimensions changed from 239x80 to 239x76 (SetTextDimensionsMsgID)
                      -[MMVimController sendMessage:data:]@336: msg=SetTextDimensionsMsgID (isInitialized=1)
                      -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                      -[MMFullscreenWindow enterFullscreen]@136: Enter full screen now

                      It's consistent. There are two cases:

                      1. If I start up MacVim with MMAutosaveRows = 76 in my prefs
                      file, the first fullscreen window shows up ok, and subsequent
                      windows are borked. MMAutosaveRows changes to 80.

                      2. If instead I start up with MMAutosaveRows = 80, the first
                      fullscreen window shows up borked, and subsequent windows are
                      good. And, you guessed it, MMAutosaveRows goes back to 76.

                      So, at this point I'm in need of a little guidance. There's a lot more I can say but as I implied above, I'm not sure which information is relevant. If any of this gives you any ideas of where to look, let me know.

                      - David


                      --
                      You received this message from the "vim_mac" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                    • Björn Winckler
                      ... You seem to be using the :winpos command somewhere in your .[g]vimrc file or plugin. The problem may go away if you remove this command. Where/how do you
                      Message 10 of 17 , Feb 22, 2011
                      • 0 Attachment
                        On Feb 21, 2011, at 11:44 PM, David Whetstone wrote:
                        > Good
                        >
                        > -[MMWindowController enterFullscreen:backgroundColor:]@660: Delay enter full screen
                        > -[MMWindowController setTextDimensionsWithRows:columns:isLive:keepOnScreen:]@311: setTextDimensionsWithRows:76 columns:239 isLive:0 keepOnScreen:1
                        > -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                        > -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                        > -[MMFullscreenWindow enterFullscreen]@136: Enter full screen now
                        >
                        > Borked
                        >
                        > -[MMWindowController enterFullscreen:backgroundColor:]@660: Delay enter full screen
                        > -[MMWindowController setTextDimensionsWithRows:columns:isLive:keepOnScreen:]@311: setTextDimensionsWithRows:80 columns:239 isLive:0 keepOnScreen:1
                        > -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                        > -[MMVimView(Private) frameSizeMayHaveChanged]@891: Notify Vim that text dimensions changed from 239x80 to 239x76 (SetTextDimensionsMsgID)
                        > -[MMVimController sendMessage:data:]@336: msg=SetTextDimensionsMsgID (isInitialized=1)
                        > -[MMVimController sendMessage:data:]@336: msg=SetWindowPositionMsgID (isInitialized=1)
                        > -[MMFullscreenWindow enterFullscreen]@136: Enter full screen now
                        >
                        > It's consistent. There are two cases:
                        >
                        > 1. If I start up MacVim with MMAutosaveRows = 76 in my prefs
                        > file, the first fullscreen window shows up ok, and subsequent
                        > windows are borked. MMAutosaveRows changes to 80.
                        >
                        > 2. If instead I start up with MMAutosaveRows = 80, the first
                        > fullscreen window shows up borked, and subsequent windows are
                        > good. And, you guessed it, MMAutosaveRows goes back to 76.
                        >
                        > So, at this point I'm in need of a little guidance. There's a lot more I can say but as I implied above, I'm not sure which information is relevant. If any of this gives you any ideas of where to look, let me know.

                        You seem to be using the :winpos command somewhere in your .[g]vimrc file or plugin. The problem may go away if you remove this command. Where/how do you use it? (I may be able to reproduce the bug this way.)

                        Björn

                        --
                        You received this message from the "vim_mac" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php
                      • David Whetstone
                        ... I don t think that s the case. The problem occurs if I move all of .vimrc, .gvimrc, and the .vim directory out of the way before starting MacVim. So for
                        Message 11 of 17 , Feb 22, 2011
                        • 0 Attachment
                          On Feb 22, 2011, at 8:55 AM, Björn Winckler wrote:

                          > You seem to be using the :winpos command somewhere in your .[g]vimrc file or plugin. The problem may go away if you remove this command. Where/how do you use it? (I may be able to reproduce the bug this way.)
                          >
                          > Björn

                          I don't think that's the case. The problem occurs if I move all of .vimrc, .gvimrc, and the .vim directory out of the way before starting MacVim. So for testing all I have is a .gvimrc with "set fullscreen" in it. Is there some other place I'm not aware of where :winpos might be getting in there?

                          - David

                          --
                          You received this message from the "vim_mac" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php
                        • björn
                          ... I think I see the problem now. Does the attached patch fix the problem for you? Björn -- You received this message from the vim_mac maillist. Do not
                          Message 12 of 17 , Feb 22, 2011
                          • 0 Attachment
                            On 22 February 2011 18:12, David Whetstone wrote:
                            > On Feb 22, 2011, at 8:55 AM, Björn Winckler wrote:
                            >
                            >> You seem to be using the :winpos command somewhere in your .[g]vimrc file or plugin.  The problem may go away if you remove this command.  Where/how do you use it?  (I may be able to reproduce the bug this way.)
                            >>
                            >> Björn
                            >
                            > I don't think that's the case.  The problem occurs if I move all of .vimrc, .gvimrc, and the .vim directory out of the way before starting MacVim.  So for testing all I have is a .gvimrc with "set fullscreen" in it.  Is there some other place I'm not aware of where :winpos might be getting in there?

                            I think I see the problem now. Does the attached patch fix the problem for you?

                            Björn

                            --
                            You received this message from the "vim_mac" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php
                          • David Whetstone
                            ... Awesome. That did it. Thanks! -- You received this message from the vim_mac maillist. Do not top-post! Type your reply below the text you are replying
                            Message 13 of 17 , Feb 22, 2011
                            • 0 Attachment
                              On Feb 22, 2011, at 11:03 AM, björn wrote:

                              > I think I see the problem now. Does the attached patch fix the problem for you?
                              >
                              > Björn

                              Awesome. That did it. Thanks!

                              --
                              You received this message from the "vim_mac" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php
                            • björn
                              ... Great! I ll go ahead and merge it. Björn -- You received this message from the vim_mac maillist. Do not top-post! Type your reply below the text you are
                              Message 14 of 17 , Feb 22, 2011
                              • 0 Attachment
                                On 22 February 2011 20:34, David Whetstone wrote:
                                >
                                > On Feb 22, 2011, at 11:03 AM, björn wrote:
                                >
                                >> I think I see the problem now.  Does the attached patch fix the problem for you?
                                >>
                                >> Björn
                                >
                                > Awesome.  That did it.  Thanks!

                                Great! I'll go ahead and merge it.

                                Björn

                                --
                                You received this message from the "vim_mac" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php
                              • David Whetstone
                                Here s my patch, in case you change your mind. -- You received this message from the vim_mac maillist. Do not top-post! Type your reply below the text you
                                Message 15 of 17 , Feb 24, 2011
                                • 0 Attachment
                                  Here's my patch, in case you change your mind.

                                  --
                                  You received this message from the "vim_mac" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php
                                • Douglas Drumond
                                  ... It looks good to me, though, as Ben, I can tell I don t carry much weight. I m using patched MacVim now. Douglas Drumond -- You received this message from
                                  Message 16 of 17 , Feb 24, 2011
                                  • 0 Attachment
                                    > Here's my patch, in case you change your mind.
                                    >

                                    It looks good to me, though, as Ben, I can tell I don't carry much weight.
                                    I'm using patched MacVim now.



                                    Douglas Drumond

                                    --
                                    You received this message from the "vim_mac" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php
                                  Your message has been successfully submitted and would be delivered to recipients shortly.