You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing code is built around the assumption that you can always drop an exact length from the left or right of a Cell. This is true of String and Text, but not true of WideString and WideText. To get around this, WideString and WideText are padded with spaces if dropping characters goes too far.
For example: dropLeft 1 (WideString "㐁㐂") = WideString " 㐂", and dropRight 1 (WideString "㐁㐂") = WideString "㐁 ".
This is perfectly fine, but when using the ExpandUntil strategy for columns, it sometimes produces columns that are (slightly) too wide. If you try to put WideString "㐁㐂" into a column with policy ExpandUntil 3, it will drop one (width 2) character from the string, pad it with a space, and put it into the column. If all other entries in the column are of length 2 or shorter, this extra space of padding is unnecessary, and the entire column can be shrunk to width 2.
In the case of WideString and WideText this is not too much of a problem, as it at most results in one extra space. However, there could be other instances of Cell (such as the proposed ElidableList in #34) where the difference is more noticable.
I think the solution is that we need a new function in Cell a which gives you the list of all natural truncations. We can the determine the best width for ExpandUntil by, for each element of the column, finding the largest natural truncation which is smaller than the limit, and then taking the maximum of all those. This is complicated by needing both a list of left truncations and a list of right truncations, depending on whether we're using left or right positioning. And for centre positioning we'd need to combine the two.
Or perhaps there's another way of achieving the same effect. Let me know if you have any thoughts.
The text was updated successfully, but these errors were encountered:
Xitian9
changed the title
Columns with expandUntil are not as tight as they could be
Columns with expandUntil are not as tight as they could be with WideString
Apr 6, 2022
Having thought about this more, I think a better solution is to add new functions to the Cell typeclass with the following signatures and default definitions:
dropLeftNoPad :: Int -> a -> (Int, a)
dropLeftNoPad n a = (0, dropLeft n a)
dropRightNoPad :: Int -> a -> (a, Int)
dropRightNoPad n a = (dropRight n a, 0)
dropBothNoPad :: Int -> Int -> a -> (Int, a, Int)
dropBothNoPad l r a = (0, dropBoth l r a, 0)
These can be subject to the property
buildCell (dropLeft n a) == let (l, c) = dropLeftNoPad n a in replicateChar l ' ' <> buildCell c
The existing code is built around the assumption that you can always drop an exact length from the left or right of a
Cell
. This is true ofString
andText
, but not true ofWideString
andWideText
. To get around this,WideString
andWideText
are padded with spaces if dropping characters goes too far.For example:
dropLeft 1 (WideString "㐁㐂") = WideString " 㐂"
, anddropRight 1 (WideString "㐁㐂") = WideString "㐁 "
.This is perfectly fine, but when using the
ExpandUntil
strategy for columns, it sometimes produces columns that are (slightly) too wide. If you try to putWideString "㐁㐂"
into a column with policyExpandUntil 3
, it will drop one (width 2) character from the string, pad it with a space, and put it into the column. If all other entries in the column are of length 2 or shorter, this extra space of padding is unnecessary, and the entire column can be shrunk to width 2.In the case of WideString and WideText this is not too much of a problem, as it at most results in one extra space. However, there could be other instances of
Cell
(such as the proposedElidableList
in #34) where the difference is more noticable.I think the solution is that we need a new function in
Cell a
which gives you the list of all natural truncations. We can the determine the best width forExpandUntil
by, for each element of the column, finding the largest natural truncation which is smaller than the limit, and then taking the maximum of all those. This is complicated by needing both a list of left truncations and a list of right truncations, depending on whether we're using left or right positioning. And for centre positioning we'd need to combine the two.Or perhaps there's another way of achieving the same effect. Let me know if you have any thoughts.
The text was updated successfully, but these errors were encountered: