search

vit-project / vit

VIT is a lightweight, fast, curses-based front end to Taskwarrior
MIT License
482 stars 51 forks source link

Resize/redraw issues with small terminal #224

Open ipwnponies opened 4 years ago

ipwnponies commented 4 years ago

What

When the terminal is resized smaller, columns are dropped if they don't fit. But it seems that forcing a redraw makes them reappear again.

It feels like there is a bug in not recalculating and evaluating column widths before truncating the columns.

Impact

This is not necessarily broken or bad behaviour, it's merely inconsistent.

Repro Steps

  1. pip install vit from source: https://github.com/scottkosty/vit/commit/811c480ce9fa491cf419e04310bf49cbe7093e2d

  2. Run the test script and this command generate data:

    task add really long text description really long text description really long text description really long text description

  3. Resize terminal to <120 char

  4. Launch vit with ready

  5. Decrease terminal width, this will drop description column

  6. Invoke the ready report again. i.e. :ready

  7. Column widths are resized, description column is visible again. Note that the issue can be continually reproduced, but only for subsequently smaller widths.

Let me know if you feel it's useful to have screenshot but this is easily reproducible.

thehunmonkgroup commented 4 years ago

Your Step #5 above has an incorrect assumption -- the column is not dropped, but instead hidden from the display -- you can readily verify this by expanding the window again before refreshing the report.

VIT currently does all column size calculations when:

The underlying Urwid library handles the hiding of columns when the current screen width gets too small to view them all.

There is already some dynamic resizing code in task_list.py to handle growing the screen vertically, but no such code exists for growing/shrinking it horizontally.

The only option I see is to do a similar kind of detection for horizontal changes, and completely rebuild the column display every time.

Re-rendering the display would need to be kept separate from re-reading the report data from TaskWarrior, otherwise the operation would be prohibitively slow. We'd have to figure out which of the display calculations from the initial render we could cache for efficiency, and which would need to be re-calculated. Even then I'm not totally sure how efficient the redraws would be.

We're talking about an awful lot of work, when hitting Ctrl+L after a screen resize would also fix the issue (how many times a day are you resizing your screen? For me it's pretty rare).

All this to say that, yes, there is some display logic that could be more automated, but it's pretty low on my priority list to do the work to address it.

So most likely, to move this issue forward, it would take:

ipwnponies commented 4 years ago

Thanks for thoughtful response. The workaround of ctrl-L is sufficient, given the incremental complexity of adding this feature.

I believe this is the dynamic vertical sizing code you're referring to, handlers for user events that trigger redraw: https://github.com/scottkosty/vit/blob/bf4cb069228e12b26e436b120fb9938a2b6a1531/vit/task_list.py#L47 It sounds like even if we added corresponding event listeners to the window resize (sigwinch?), the next hurdle is that vit doesn't maintain an stateful representation of taskwarrior?

I'll leave it to you to close this out or to keep it open as a low priority, pipe-dream ticket.

thehunmonkgroup commented 4 years ago

Yes, that's the event fired that can be caught for the purpose of handling the resize. I believe it passes the new size along.

VIT has a stateful representation of the data, and the configuration, which is all that's necessary. The potential challenge is that currently Ctrl+L reloads everything -- I don't think there's a very clean separation between what we'd want to preserve and what we'd want to refresh -- that could get hairy.

We can keep it open, maybe somebody will take a stab at it.

eriteric commented 4 years ago

Just wanted to add my experience to this. The above mentioned workarounds helped me to figure this out, and I also had the reload key remapped in tmux so i had to map it to CTRL+r for vit instead.

On a large monitor, I still run into this issue. I have annotations and "long" descriptions, (ranging from 5 to ~20 words). The description column goes hidden, making for a rather unuseful list.

What I do to fix it each time is:

I can then read the descriptions until I do another filter. If i had to guess at a number of times a day I do this process it would be 20-40.

rephrased question: Does there exist a way to hook onto the filter action?

thehunmonkgroup commented 4 years ago

I'm not willing to do that. The correct approach is detailed above, I look forward to a PR to review!

thehunmonkgroup commented 4 years ago

@eriteric it just occurred to me that you might be getting bit by https://github.com/scottkosty/vit/issues/203, which has been fixed, but is not in an official release yet.

Can you try installing the latest development version and see if that fixes your issue?

nblock commented 4 years ago

For me, 8d885c2 no longer has this issue for me. Updated the Arch AUR package accordingly.

eriteric commented 4 years ago

@eriteric it just occurred to me that you might be getting bit by #203, which has been fixed, but is not in an official release yet.

Can you try installing the latest development version and see if that fixes your issue?

That looks to be exactly it, thanks.