Grid view is broken

[cafkafk]

Running --grid with the latest git version of zetta is broken on my machine.

E.g. by doing cargo run --release -- --grid, or using an installed version (see screenshot below).

This is a fairly severe regression as the the default expected behavior of exa/zetta is to run --grid if nothing else is specified.

ogham/exa#1165 (comment)

syphar/zetta#4

[cafkafk]

This existed before any of the merges thou, as discussed in zetta, but tracking and bisecting this issue is important, and I'll get on it after I'm done with the PRs

[cafkafk]

After a bisect, I've arrive here:

af208285e8a0fb383f59372c966bdb77f94006e9 is the first bad commit
commit af208285e8a0fb383f59372c966bdb77f94006e9
Author: Bastien Orivel <[email protected]>
Date:   Fri Dec 10 13:21:13 2021 +0100

    Update term_grid to 0.2

 Cargo.lock                 | 4 ++--
 Cargo.toml                 | 2 +-
 src/output/grid.rs         | 1 +
 src/output/grid_details.rs | 2 ++
 4 files changed, 6 insertions(+), 3 deletions(-)

af20828

Gonna see if I can solve it.

[cafkafk]

The plot thickens ogham/rust-term-grid#11

[cafkafk]

I'm pretty sure we should move to https://github.com/uutils/uutils-term-grid (see ogham/rust-term-grid#15), but for now I'll try to go back to rust-term-grid 0.1.

[sbatial]

I'm pretty sure we should move to https://github.com/uutils/uutils-term-grid (see ogham/rust-term-grid#15)

Agreed

[ariasuni]

Regarding uutils/uutils-term-grid#6, do you think the behavior should change in uutils-term-grid? I don’t really care myself but I figured it could matter to some people here.

[cafkafk]

Regarding uutils/uutils-term-grid#6, do you think the behavior should change in uutils-term-grid? I don’t really care myself but I figured it could matter to some people here.

I'm don't really care that much, at least when just looking at it initially. Of course if it's not that big of an issue, having it configurable would perhaps be preferred, but personally, I don't see it being an issue for my use.

I'd be interested in how other people feel about it however.

[Vistaus]

It's still broken for me, even in eza.

Eza version: 0.11
OS: openSUSE Tumbleweed
Terminal emulator: Yakuake

[ariasuni]

Do you think you could post a screenshot of the output of eza vs ls?

[LeoniePhiline]

eza --grid works for me on OpenSUSE Tumbleweed.
Terminal emulator: Konsole
Maybe Yakuake is the problem?

[Vistaus]

I figured it out: it had to do with the width. For some reason, if I set Yakuake to 60%, which I prefer, eza does not do grid. However, if I set it to 80%, it does work. Why it does not work with 60% is beyond me, as my screen is 2560x1440, so I have plenty of space to show a proper grid with 60%, but oh well. Thanks for all of your input!

[Vistaus]

UPDATE: actually, it doesn't always seem to work with 80% either. Only when I have a handful of files. In a folder with about 15 files, it doesn't work.

[ariasuni]

I asked for a screenshot (but a copy-paste of the output would work as well) because otherwise it’s impossible to diagnose, since it triggers in only some cases. If you’re concerned about privacy, it should be possible to recreate the issue with different file names of the same length (if they sort in the same order).

[cafkafk]

Also I should mention, echo $COLUMNS has historically been super useful to diagnose problems like this

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[userrand]

UPDATE: actually, it doesn't always seem to work with 80% either. Only when I have a handful of files. In a folder with about 15 files, it doesn't work.

I figured it out: it had to do with the width. For some reason, if I set Yakuake to 60%, which I prefer, eza does not do grid. However, if I set it to 80%, it does work. Why it does not work with 60% is beyond me, as my screen is 2560x1440, so I have plenty of space to show a proper grid with 60%, but oh well. Thanks for all of your input!

Maybe it is just my font size but I noticed that, at least on my computer, yakuake does not work with fzf ** completion whereas konsole does. I am also unable to see the processes in htop with yakuake. So it seems to me that yakuake has some trouble showing some tui processes (but maybe it is just my font size).

[cafkafk]

I'm pretty sure this issue has been resolved by now, if not, let me know and we can always reopen.

[tribals]

ysh ysh-0.22.0$ eza --version
eza - A modern, maintained replacement for ls
v0.18.17 [+git]
https://github.com/eza-community/eza
ysh ysh-0.22.0$ eza --long --grid
drwxr-xr-x   - anthony 14 Jun 04:28  debian-nosh        drwxr-xr-x   - anthony 22 Jun 17:20  projects    drwxr-xr-x   - anthony 22 Jun 18:58  space
.rw-r--r-- 28k anthony 14 Jun 20:52  guix-install.sh    drwxr-xr-x   - anthony 23 Jun 19:05  soccoop     drwxr-xr-x   - anthony 25 Jun 23:17  vpnn
ysh ysh-0.22.0$ env EZA_GRID_ROWS=10 eza --long --grid
drwxr-xr-x   - anthony 14 Jun 04:28  debian-nosh        drwxr-xr-x   - anthony 22 Jun 17:20  projects    drwxr-xr-x   - anthony 22 Jun 18:58  space
.rw-r--r-- 28k anthony 14 Jun 20:52  guix-install.sh    drwxr-xr-x   - anthony 23 Jun 19:05  soccoop     drwxr-xr-x   - anthony 25 Jun 23:17  vpnn
ysh ysh-0.22.0$ env EZA_GRID_ROWS=666 eza --long --grid
drwxr-xr-x   - anthony 14 Jun 04:28  debian-nosh        drwxr-xr-x   - anthony 22 Jun 17:20  projects    drwxr-xr-x   - anthony 22 Jun 18:58  space
.rw-r--r-- 28k anthony 14 Jun 20:52  guix-install.sh    drwxr-xr-x   - anthony 23 Jun 19:05  soccoop     drwxr-xr-x   - anthony 25 Jun 23:17  vpnn

[sbatial]

What a problem with that rust programmers?.. Are they really capable of producing at least working as expected software?

Yes, yes they are.

Look, you were even so nice and provided an example of a working rust project, as far as I can tell: #66 (comment)

[sbatial]

The only thing I can imagine from your example is that your terminal is wide enough that more rows could fit but only a maximum of 3 rows is rendered.

But that is only a suspicion.
Can you elaborate what exactly is wrong (e.g. your terminal is wide enough, your terminal is smaller so too many rows are rendered, etc.)?
Or do you have a screenshot of the output, which is kinda necessary to debug issues with the grid display.

[LeoniePhiline]

In which case does terminal_size::terminal_size_using_fd return None? Could the terminal be incompatible?

row_threshold (the parsed value of EZA_GRID_ROWS) is only taken into account when a terminal column width could be determined or is set by the user.

eza/src/main.rs

Line 462 in c58ddcb

row_threshold,

If the terminal width is None, then EZA_GRID_ROWS has no effect. https://github.com/eza-community/eza/blob/main/src/main.rs#L471

Are any other eza or exa environment variables set in the terminal session? Which terminal is in use on which OS?

[LeoniePhiline]

Can you elaborate what exactly is wrong (e.g. your terminal is wide enough, your terminal is smaller so too many rows are rendered, etc.)?

The issue I can see in #66 (comment) is that EZA_GRID_ROWS=N should make eza use grid view only if at least N rows would be displayed, and use non grid row view for shorter result sets.

However, even with EZA_GRID_ROWS=10 or even =666, the result is rendered as grid despite being only 6 items long.

[sbatial]

oohhh, you're right.
my apologies, I had remembered the effect the wrong way around

[cafkafk]

@tribals has been blocked from all @eza-community projects for the time being, we do not tolerate that kind of behavior

[LeoniePhiline]

I believe EZA_GRID_ROWS is not working correctly:

As I understand it, EZA_GRID_ROWS should make the items after the first prompt get printed in list, rather than grid view.

[LeoniePhiline]

row_threshold is passed to grid_details::Render, but it does nothing with it.

I believe the match on match (mode, self.console_width) in fn print_files should have an added if guard, comparing row_threshold to the length of the files vector. If the row threshold is not reached, then it should use details::Render rather than grid_details::Render.

[cafkafk]

row_threshold is passed to grid_details::Render, but it does nothing with it.

I believe the match on match (mode, self.console_width) in fn print_files should have an added if guard, comparing row_threshold to the length of the files vector. If the row threshold is not reached, then it should use details::Render rather than grid_details::Render.

Maybe a separate issue should be opened for this, sounds like you're halfway to a PR as well :)

[LeoniePhiline]

sounds like you're halfway to a PR as well :)

Nerd-sniped.

Pull request: #1043 (The CI failure of Flake Checker appears unrelated. ➡️ DeterminateSystems/flake-checker-action#32)

I noticed that EZA_GRID_ROWS apparently isn't meant to apply to non-details views? Is that correct? I found the code quite clear about that, due to grid_details::RowThreshold's placement within its grid_details module.

However, from a functionality perspective, as an end user I would expect this to apply to plain EZA_GRID_ROWS=1234 eza as well, without involvement of details views.

The second prompt should, to my intuition, result in a list view like eza -1.