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

RE: Tabs revisited

Expand Messages
  • Nowhere Man
    Bram: Is my patch or another fix going to make it into the source?
    Message 1 of 21 , May 31, 2004
    • 0 Attachment
      Bram:

      Is my patch or another fix going to make it into the source?




      > -----Original Message-----
      > From: Nowhere Man [mailto:pi-rho@...]
      > Sent: Saturday, May 29, 2004 12:05 AM
      > To: 'Benji Fisher'; vim-dev@...
      > Subject: RE: Tabs revisited
      >
      > > -----Original Message-----
      > > From: Benji Fisher [mailto:benji@...]
      > > Sent: Friday, May 28, 2004 10:05 PM
      > > To: vim-dev@...
      > > Subject: Re: Tabs revisited
      > >
      > > On Fri, May 28, 2004 at 04:48:37PM -0500, Nowhere Man wrote:
      > > >
      > > > I understand what you were saying. And I got it to work...
      > > It looks
      > > > pretty neat. My patch was to fix the following:
      > > >
      > > > [in vimrc: wh=999, wmh=0, noea, sb]
      > > >
      > > > vim -o file1 file2 file3 file4
      > > > :: this creates two windows and 4 buffers with the first
      > > two buffers
      > > > in the windows (in window.c/make_windows() maxcount is set
      > > to 2 since
      > > > the calculation gives a negative number).
      > > >
      > > > vim then :new file1<CR>:new file2<CR>:new file3<CR>:new file4<CR>
      > > > :: this creates four windows with a buffer in each and
      > > works as expected.
      > >
      > > I see something different, but it still looks like a bug.
      > > Instead of adding a line to my vimrc, I skipped the vimrc
      > file and set
      > > the various options when starting vim:
      > >
      > > $ vim -N -u NONE +"set wh=999 wmh=0 noea sb" -o file1 file2
      > > file3 file4
      > >
      > > Please try it this way, just in case there is something
      > else in your
      > > vimrc file that affects this behavior.
      > >
      > > Instead of seeing two windows and 4 buffers, I get 4 windows:
      > > three of them have one status line *and* one text line, and
      > the fourth
      > > takes up the rest of the terminal. When I cycle to the
      > bottom window,
      > > or
      > >
      > > :set wh=999
      > >
      > > the three small windows collapse to just a status line each.
      >
      > Yes, same here... If the commands are issued after vim is
      > running it behaves correctly. If the commands are in vimrc,
      > it only creates two windows.
      >
      > Sorry for not including my version information... Vim
      > 6.3b/Win32 (I've tested this with both the packaged 6.3b and
      > the cvs sources as of 8:00pm CDT with the HUGE feature set
      > with dynamic perl and python). The same behavior is seen
      > with vim and gvim.
      >
      >
    • Bram Moolenaar
      I still didn t get your real name. ... It s not clear what problems a fix would create. I rather not change it now. -- hundred-and-one symptoms of being an
      Message 2 of 21 , Jun 1, 2004
      • 0 Attachment
        I still didn't get your real name.

        > Is my patch or another fix going to make it into the source?

        It's not clear what problems a fix would create. I rather not change it
        now.

        --
        hundred-and-one symptoms of being an internet addict:
        26. You check your mail. It says "no new messages." So you check it again.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
      • Vince Negri
        There is something strange happening. if I do Benji s vim -N -u NONE + set wh=999 wmh=0 ls=2 -o file1 file2 file3 Then I get three status lines for the three
        Message 3 of 21 , Jun 1, 2004
        • 0 Attachment
          There is something strange happening.

          if I do Benji's
          vim -N -u NONE +"set wh=999 wmh=0 ls=2" -o file1 file2 file3

          Then I get three status lines for the three files.

          *but* if I create a _vimrc which has only the line
          set wh=999 wmh=0 ls=2
          in it, and then do

          vim -N -u _vimrc -o file1 file2 file3

          I only get status lines for file1 and file2.

          Surely those two commands ought to be equivalent?

          > -----Original Message-----
          > From: Benji Fisher [SMTP:benji@...]
          >
          >
          > I see something different, but it still looks like a bug. Instead
          > of adding a line to my vimrc, I skipped the vimrc file and set the
          > various options when starting vim:
          >
          > $ vim -N -u NONE +"set wh=999 wmh=0 noea sb" -o file1 file2 file3 file4
          >
          > Please try it this way, just in case there is something else in your
          > vimrc file that affects this behavior.
          >
          >
          Legal Disclaimer: Any views expressed by the sender of this message are
          not necessarily those of Application Solutions Ltd. Information in this
          e-mail may be confidential and is for the use of the intended recipient
          only, no mistake in transmission is intended to waive or compromise such
          privilege. Please advise the sender if you receive this e-mail by mistake.
        • Antony Scriven
          ... Maybe it s something to do with there not being a terminal present when the _vimrc is executed? au vimenter * set wh=999 wmh=0 ls=2 works fine. Antony
          Message 4 of 21 , Jun 1, 2004
          • 0 Attachment
            Vince Negri wrote:

            > There is something strange happening.
            >
            > if I do Benji's
            > vim -N -u NONE +"set wh=999 wmh=0 ls=2" -o file1 file2 file3
            >
            > Then I get three status lines for the three files.
            >
            > *but* if I create a _vimrc which has only the line
            > set wh=999 wmh=0 ls=2
            > in it, and then do
            >
            > vim -N -u _vimrc -o file1 file2 file3
            >
            > I only get status lines for file1 and file2.
            >
            > Surely those two commands ought to be equivalent?

            Maybe it's something to do with there not being a terminal
            present when the _vimrc is executed?

            au vimenter * set wh=999 wmh=0 ls=2

            works fine.

            Antony
          • Bram Moolenaar
            ... The order of execution is different. Firs the vimrc file is used, then the files are loaded, then command arguments are executed. Thus in the first
            Message 5 of 21 , Jun 1, 2004
            • 0 Attachment
              Vince Negri wrote:

              > There is something strange happening.
              >
              > if I do Benji's
              > vim -N -u NONE +"set wh=999 wmh=0 ls=2" -o file1 file2 file3
              >
              > Then I get three status lines for the three files.
              >
              > *but* if I create a _vimrc which has only the line
              > set wh=999 wmh=0 ls=2
              > in it, and then do
              >
              > vim -N -u _vimrc -o file1 file2 file3
              >
              > I only get status lines for file1 and file2.
              >
              > Surely those two commands ought to be equivalent?

              The order of execution is different. Firs the vimrc file is used, then
              the files are loaded, then command arguments are executed. Thus in the
              first example you set 'winheight' after opening the windows.

              That ":all" uses 'winheight' was discussed previously. It's not nice in
              this situation, but useful in others (e.g., to avoid you end up with 12
              one-line windows in a 25 line terminal).

              --
              How To Keep A Healthy Level Of Insanity:
              5. Put decaf in the coffee maker for 3 weeks. Once everyone has gotten
              over their caffeine addictions, switch to expresso.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
            • Vince Negri
              ... Yes indeed. It s the age-old situation where an option (winheight) which was originally for one use (stopping annoyingly small windows, as in your example)
              Message 6 of 21 , Jun 1, 2004
              • 0 Attachment
                Bram wrote:

                > That ":all" uses 'winheight' was discussed previously. It's not nice in
                > this situation, but useful in others (e.g., to avoid you end up with 12
                > one-line windows in a 25 line terminal).

                Yes indeed. It's the age-old situation where an option
                (winheight) which was originally for one use (stopping
                annoyingly small windows, as in your example) has been
                creatively (ab)used to do something else - and now we've
                run across a corner case which reveals the underlying
                "hack."

                The tweak I set out in my previous email (changing winheight
                to a true soft limit) allows the "12 one-line windows"
                situation, and isn't 100% back compatible, so it's not
                really satisfactory.

                The only perfect solution (assuming one wants to bother
                creating one) is to stop winheight doing double duty,
                viz:

                Either (a) removing the need for setting winheight to
                a silly number by creating a new option that has the
                effect "I want the current window to take as much space
                as possible, forcing all other windows to winminheight"

                or (b) adding an option which specifies whether
                winheight is a genuinely soft limit (new behaviour) or
                a firm limit (old behaviour)

                or (c) allowing winheight to be set to a -ve value, where
                a negative value is like setting the +ve value but
                as a true soft limit (ugh, I shouldn't have even suggested that...
                now I feel dirty.. ;)

                or (d) allowing a syntax like ":set winheight=max" which
                acts like the option (a) above but avoids creating another
                option (superficially nice, but I don't think any other
                numerical option acts like this so it's likely to be a can
                of worms)

                Note that all of the above *are* backward compatible, which
                is another important consideration.


                Legal Disclaimer: Any views expressed by the sender of this message are
                not necessarily those of Application Solutions Ltd. Information in this
                e-mail may be confidential and is for the use of the intended recipient
                only, no mistake in transmission is intended to waive or compromise such
                privilege. Please advise the sender if you receive this e-mail by mistake.
              • Antoine J. Mechelynck
                ... I was going to say that I thought the situation outlined in the help to be the intended behaviour, but I had a crash, and by the time my computer was up
                Message 7 of 21 , Jun 1, 2004
                • 0 Attachment
                  Vince Negri <vnegri@...> wrote:
                  > Bram wrote:
                  >
                  > > That ":all" uses 'winheight' was discussed previously. It's not
                  > > nice in this situation, but useful in others (e.g., to avoid you
                  > > end up with 12 one-line windows in a 25 line terminal).
                  >
                  > Yes indeed. It's the age-old situation where an option
                  > (winheight) which was originally for one use (stopping
                  > annoyingly small windows, as in your example) has been
                  > creatively (ab)used to do something else - and now we've
                  > run across a corner case which reveals the underlying
                  > "hack."
                  >
                  > The tweak I set out in my previous email (changing winheight
                  > to a true soft limit) allows the "12 one-line windows"
                  > situation, and isn't 100% back compatible, so it's not
                  > really satisfactory.
                  >
                  > The only perfect solution (assuming one wants to bother
                  > creating one) is to stop winheight doing double duty,
                  > viz:
                  >
                  > Either (a) removing the need for setting winheight to
                  > a silly number by creating a new option that has the
                  > effect "I want the current window to take as much space
                  > as possible, forcing all other windows to winminheight"
                  >
                  > or (b) adding an option which specifies whether
                  > winheight is a genuinely soft limit (new behaviour) or
                  > a firm limit (old behaviour)
                  >
                  > or (c) allowing winheight to be set to a -ve value, where
                  > a negative value is like setting the +ve value but
                  > as a true soft limit (ugh, I shouldn't have even suggested that...
                  > now I feel dirty.. ;)
                  >
                  > or (d) allowing a syntax like ":set winheight=max" which
                  > acts like the option (a) above but avoids creating another
                  > option (superficially nice, but I don't think any other
                  > numerical option acts like this so it's likely to be a can
                  > of worms)
                  >
                  > Note that all of the above *are* backward compatible, which
                  > is another important consideration.


                  I was going to say that I thought the situation outlined in the help to be
                  the "intended" behaviour, but I had a crash, and by the time my computer was
                  up again, there had been tjis exchange between you two, which made me
                  reconsider. Vince, I think your proposals have merit, the problem is
                  choosing between them. And however silly it may seem, I suppose that there
                  might some day arise a situation where having, even (let's go whole hog, and
                  in a 50-line VGA terminal) 47 zero-line windows, one single-line window, and
                  of course the command-line, would present some utility :-). Of course we can
                  set wh=1, but then if one or more windows are closed, or if less than the
                  maximum are opened to start with, there should IMO be a way to have the
                  current one take up the slack, so to speak.

                  At least, if the current ambiguous behaviour (which I personallt don't like,
                  but it's not for me to decide) is to be the norm, then it should be
                  documented, maybe even at several places, e.g. under 'wh', :all and -o.

                  For a "true soft" behaviour of &wh, the max no. of windows is of course the
                  integer quotient of (&lines - &ch - (&wmh < 1)) by (&wmh + 1).

                  Best regards,
                  Tony.
                Your message has been successfully submitted and would be delivered to recipients shortly.