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

Re: Tabs revisited

Expand Messages
  • 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 1 of 21 , Jun 1, 2004
      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,
    Your message has been successfully submitted and would be delivered to recipients shortly.