restore screen after adding tasks

[champignoom]

Is your feature request related to a problem? Please describe.

After adding a task, seeing the following message

TASKRC override: /home/exprosic/.taskrc
Created task 12.
Press Enter to continue...

and quitting from vit, the entire screen is cleared.

If I quit immediately from vit after launching it, the screen is not cleared.

Describe the solution you'd like

The screen should be restored after vit terminates.

Additional context

[thehunmonkgroup]

I'm afraid I don't understand the issue you're reporting.

[champignoom]

Here's the detailed steps to reproduce the issue:

1. open a fresh terminal session
2. type seq 5<enter>vit<enter>:q<enter>
3. the result of seq 5 should remain on the screen
4. type vit<enter>anewtask<enter><enter>:q<enter>
5. everything disappears from the screen but it shouldn't

[thehunmonkgroup]

OK, I see now.

I believe we may run into a worse UX situation trying to fix this.

If we eliminate the clear screen for commands like adding tasks, I believe the display will not be as user friendly, as the various command outputs will just pile up on the screen. The way that works now seems correct from a UX perspective.

However, clearing the screen the way I do clears the screen, meaning it also removes any non-VIT related content that was there before.

We could also fix the inconsistency on the other end by clearing the screen upon a clean VIT exit:

diff --git a/vit/application.py b/vit/application.py
index 0a92399..9109dda 100644
--- a/vit/application.py
+++ b/vit/application.py
@@ -552,6 +552,9 @@ class Application():
         return False, False
 
     def quit(self):
+        self.loop.stop()
+        clear_screen()
+        self.loop.start()
         raise urwid.ExitMainLoop()
 
     def build_task_table(self):

That way you always return to a clear screen upon exit. I'm not really sure what that buys us, as in that case there's no need to clear the screen for any functionality that VIT is performing.

If there's a way to somehow collect what's on the screen, hold it, then put it back after VIT exits, I don't know what it is.

[champignoom]

If there's a way to somehow collect what's on the screen, hold it, then put it back after VIT exits, I don't know what it is.

It's the altscreen termcap. It's just yet another ansi sequence (see https://stackoverflow.com/a/11024208), but it is better managed by the curses module of python.

Refactoring vit with curses is aesthetically the better solution, but it could be a giant pull request with little visible short-term benefit.

I could make the PR if it's allowed.

After inspecting into the code a bit, this becomes a very suspicious claim to me:

VIT (Visual Interactive Taskwarrior) is a lightweight, curses-based front end for Taskwarrior that provides a convenient way to quickly navigate and process tasks.

since I've not found any use of curses after initialization. It might have used curses during the perl era but hardly ever since.

[thehunmonkgroup]

VIT uses the Python Urwid library, which I'm pretty sure uses curses under the hood.

There's no way I'm refactoring to use curses natively. If there is a more surgical implementation to address this issue, I'm happy to look at it.

[thehunmonkgroup]

@champignoom the offending code is here: https://github.com/vit-project/vit/blob/2.x/vit/process.py#L44-L55

I think it would be possible to refactor that to preserve the original terminal content, but in my poking around there are some gotchas:

1. If we write to the 'alternate screen', there's no scrollback, which would cause problems if any task command that we currently display had output that didn't fit on a single screen.
2. If we disable the 'clear' functionality, it would preserve the terminal content, but the command results from all task commands run in VIT would pile up in the terminal, and the output of each would be harder to read IMO as it's on the bottom of the screen once you get enough output. Plus that output shouldn't really live in the main terminal window if we're trying to restore it to its previous state.
3. Staying inside Urwid's main loop and offering the output of task commands we run would be the cleanest, but would involve some refactoring, as process.py currently has no awareness of the necessary screen or loop objects, and I don't think it should. I'm also pretty sure we'd lose any coloring that comes with the task output.

[thehunmonkgroup]

Also, I did check, and while Urwid does have a curses display library, we're currently using their raw library. I did try to switch to the curses one, but it threw an error I did not understand.