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
This commit merges in a *lot* of refactoring work done to the tree, details, and grid-details views.
The main one is that the concept of a “table” has been completely separated from the details view. Previously, if you wanted to use the long view without drawing the table (such as with --tree), exa used a “table” with 0 columns in it behind the scenes. This is now reversed: the table is now the optional component in the details view, and a tree-only view is just a details view without a table!
Doing this has paved the way for all sorts of code cleanups: now, we only calculate values needed for the table if one’s going to be displayed. Some of these were rather expensive to compute (such as the user’s time zone, or locale)
This refactoring is not fully complete; there are still several things that can be done, including having the errors and xattrs in the tree view use the same TreeParams constructor as the others, and separating the column widths from the table so fewer mutable values need to be passed around.
Finally, this also merges in a lot of debuffering. There were at least two places in the code where values were collected into a vector before immediately being iterated over, instead of just using those values as they were generated! For example, when displaying the table, each row was rendered into a set of cells for displaying: but then it all went into a vector, and was only displayed at the very end, because that was what I needed for the grid-details view. Now, exa is smart enough to not do that.
Basically, even if exa doesn’t actually *get* that much faster, it should at least display its first line of output quicker.
Fixesogham#90, but also see ogham#82.
0 commit comments