Re: [Fish-users] bug in computing COLUMNS?
Status: Beta
                
                Brought to you by:
                
                    liljencrantz
                    
                
            | 
     
      
      
      From: Kurtis R. <kr...@sk...> - 2017-09-02 14:20:31
      
     
   | 
On Sat, Sep 2, 2017 at 6:05 AM, Greg Reagle <gre...@um...> wrote: > On Fri, Sep 1, 2017, at 15:05, Kurtis Rader wrote: > > Fish won't work if the terminal height is less than two. I don't recall > the exact value but > > it also won't behave sensibly if the width is much less than 20. > > Does fish behave better when the width is less than 20 to pretend that > the width is 80? What about all the programs that depend on $COLUMNS or > `tput cols` etc.? My question is: what is the reason to *mis-represent* > the width when it's less than 20. > > > This tends to happen most often with console VTs where the size is > frequently reported as > > zero for both values. > > I understand that this can be a problem, but I don't see the relevance, > i.e. it seems like a different issue. Checking for zero is different > than checking for less than 20. Certainly fish can be programmed to > fallback to 80x24 if either dimension is reported to be zero. Fish won't work if COLUMNS is one or two either. As I said earlier I don't recall now what the exact threshold is but I'm pretty sure it was greater than ten. Similarly, it won't work if LINES is less than two. So the actual threshold is not zero versus non-zero. Feel free to do some experiments to determine the hard lower limit on COLUMNS and ask that it be used as the hard lower bound rather than 20. Of course, that just moves the goal posts slightly so it's not clear it really matters at the end of the day. Fish will not work in a 1x1, 2x2, 5x2, or other similarly sized terminals. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank  |