Is hLimit w widget drawn at all if w<=0?

[amano-kenji]

Does brick attempt to draw hLimit w widget if w<=0?

[jtdaugherty]

The effect of hLimit 0 w is that w is not drawn, but that does not mean no attempt is made. Can you say more about what motivated this question?

[amano-kenji]

I have these data types in MixedTabularList.hs.

data MixedColumnHeaderWidths row = AvailHdrWidth (AvailWidth -> [Maybe Width])
  | VisibleRowAvailHdrWidth ([row] -> AvailWidth -> [Maybe Width]) deriving Generic

newtype WidthsPerRow row = WidthsPerRow (row -> [Maybe Width]) deriving Generic

data MixedColumnWidths row = AvailWidth (AvailWidth -> WidthsPerRow row)
  | VisibleRowAvailWidth ([row] -> AvailWidth -> WidthsPerRow row) deriving Generic

Maybe Width is for skipping rendering for certain columns entirely if the available width is too narrow. Perhaps, I can replace Maybe Width with just Width to simplify the codebase. Width can be equal to or less than 0.

Moore's law is dead, and the attempts still eat up precious CPU cycles. I don't know how many CPU cycles are needed to make the attempts.

I thought GridTabularList was going to be more complex, but it turned out to be simple after figuring out an efficient stateless rendering algorithm. MixedTabularList is more complex due to data structures for column width calculation.

[jtdaugherty]

I don't know how many CPU cycles are needed to make the attempts

Due to lazy evaluation, probably not very many at all. But I pushed a patch to master to take away a few more cycles. :)

[amano-kenji]

I just checked. That will do the work.

[jtdaugherty]

What do you mean by "do the work"?

[amano-kenji]

The latest change serves the purpose of saving some CPU cycles.

[jtdaugherty]

It might add a few, actually; it just depends on how much lazy evaluation was playing a role before in avoiding them. In any case, my main intention with updating those functions was to make them easier to reason about in the less-than-or-zero case.