Unlock layout bias' upper limit

[resolritter]

Is your feature request related to a problem? Please describe.

Would it be feasible to allow bias above 90? As an experiment, I tried to modify the source code in the relevant places but it didn't make a noticeable difference. e.g. let's say 96

   def safe_increment_bias(old_val: float, increment: float) -> float:
  -    return max(0.1, min(old_val + increment, 0.9))
  +    return max(0.04, min(old_val + increment, 0.96))

  --- a/kitty/layout/splits.py
  +++ b/kitty/layout/splits.py
  @@ -253,7 +253,7 @@ def modify_size_of_child(self, which: int, increment: float, is_horizontal: bool
           if is_horizontal == self.horizontal and not self.is_redundant:
               if which == 2:
                   increment *= -1
  -            new_bias = max(0.1, min(self.bias + increment, 0.9))
  +            new_bias = max(0.04, min(self.bias + increment, 0.96))
               if new_bias != self.bias:
                   self.bias = new_bias
                   return True

  --- a/kitty/layout/tall.py
  +++ b/kitty/layout/tall.py
  @@ -69,7 +69,7 @@ def __init__(self, data: Dict[str, str]):
               b = int(data.get('bias', 50)) / 100
           except Exception:
               b = 0.5
  -        b = max(0.1, min(b, 0.9))
  +        b = max(0.04, min(b, 0.96))
           self.bias = tuple(repeat(b / fs, fs)) + (1.0 - b,)
           self.mirrored = to_bool(data.get('mirrored', 'false'))

The layout I used was:

enabled_layouts fat:bias=96;full_size=1

Describe the solution you'd like

Allow bias to be above 90. Unless there are implementation infeasibilities, to me it doesn't make sense to limit it; let the user deal with the consequences if there are any.

[kovidgoyal]

There has to be some limit, layouts are not designed to hide windows
completely other than the stack layout. So you would have to have some
limit less than 100. May I case what the limit of 90 is preventing you
from doing?

[resolritter]

There has to be some limit, layouts are not designed to hide windows completely other than the stack layout.

Maybe it could be 99, then?

May I case what the limit of 90 is preventing you from doing?

Sure. I have a split which acts as a text input for sending commands to other splits, so ideally I'd have it really short. 90 is good already but I'd like to experiment with more... Maybe 94 or 96 as suggested.

[kovidgoyal]

On Sun, Apr 04, 2021 at 04:58:29AM -0700, João Paulo Silva de Souza wrote: > There has to be some limit, layouts are not designed to hide windows completely other than the stack layout. Maybe it could be 99, then?

Doing that would require making sure that elsewhere in the code things dont break if the window becomes too narrow. They shouldnt, but... Note that 0.9 is the cap in other places as well, for instance in safe_increment_bias() This could be raised, however, as I said doing so will require careful testing/review.

> May I case what the limit of 90 is preventing you from doing? Sure. I have a split which is a text input for sending commands to other splits, so ideally I'd have it really short. 90 is good already but I'd like to experiment with more... Maybe 94 or 96 as suggested.

The proper fix for this is #2391 Until then, perhaps just live with a slightly fatter than optimal window :)

[resolritter]

It does feel like it's capped in other places indeed. Even with the patch I posted in the OP, I still cannot make shorter with manual resizes.

The proper fix for this is #2391

It's relevant for this to still be ratio-based instead of a fixed size. I didn't see a mention of "ratio" in that discussion although, if that's planned as well, alright.

This could be raised, however, as I said doing so will require careful testing/review.

I'm interested in the possibility of trying it out locally. Where more would I need to look at outside from the places I had already changed in the OP's patch?

[resolritter]

Actually nevermind the ratio-based idea. I think fixed size would work out as well for this.

Closing in favor of #2391.