Visidata: VisiData should confirm quits while a thread is still in progress

Created on 10 Nov 2019  路  8Comments  路  Source: saulpw/visidata

...or, at minimum, if VisiData is still saving a file. =)

This is in response to this bug report https://github.com/saulpw/visidata/issues/388 by @dbandstra.

Sometimes, users do not notice the saving progress bar, and may quit before their saving has completed.

fixed wish granted wishlist

Most helpful comment

I think it's reasonable to add this to options.quitguard, maybe even replacing the existing behavior. I'm not totally sure what counts as a modification though. A direct edit on a source sheet, yes, but adding an expression column? Hiding a column? Deleting a column? Deleting a row?

What I'm thinking right now, is to only mark a source sheet as directly 'modified' if one of its source rows is modified via a column setter, so none of the above would trigger the quitguard. Then q on a modified source sheet would require confirmation. gq should probably require confirm if any of the source sheets on the sheet stack are modified. Ctrl+Q will quit immediately without confirmation as always.

For a more 'forgiving' experience, you could push the cmdlog at the outset and then any command that got added to the cmdlog would mark it as modified. Actually that would be pretty sweet..

All 8 comments

What about confirming any time the file has unsaved work? This is another thing that I find a little odd about vd coming from other programs.

@dbandstra Yes, there is a plugin for "tracking changes in state". It colours modified un-saved cells, and I can see adding a feature to it for "confirm-quit" when you have unsaved changes. That plugin has a few bugs right now (see our issue board...), but it is on my priority list. I can leave a message here when those are fixed.

A major design component of VisiData is "classic terminal sleekness" and I think having a lot of default safety rails in the core can be a hindrance to that. But I can definitely add that safety-rail in the trackmod plugin for those who want it.

Cool, I'll check the plugin out if this gets added. Classic sleekness sounds like a euphemism :) I would call it old-school unforgivability. But I'd be interested in reading more about this design philosophy though. Is vd more often used to explore data without editing? (I picked it up recently and I'm just using it as a basic CSV editor.)

Yeah, it can definitely be unforgivable. I agree. That is why this plugin is important and I want to iron out its kinks.

There is a WIP book section available here https://github.com/saulpw/visidata-book/blob/master/design-choices.md that briefly outlines the design philosophy. Saul calls it "snappiness" which is a much better and less weighed down descriptor.

Also, I would love a poll on the diverse ways VisiData is used. I am actually not sure what the more common usecase is. Maybe @saulpw has an intuition?

I think it's reasonable to add this to options.quitguard, maybe even replacing the existing behavior. I'm not totally sure what counts as a modification though. A direct edit on a source sheet, yes, but adding an expression column? Hiding a column? Deleting a column? Deleting a row?

What I'm thinking right now, is to only mark a source sheet as directly 'modified' if one of its source rows is modified via a column setter, so none of the above would trigger the quitguard. Then q on a modified source sheet would require confirmation. gq should probably require confirm if any of the source sheets on the sheet stack are modified. Ctrl+Q will quit immediately without confirmation as always.

For a more 'forgiving' experience, you could push the cmdlog at the outset and then any command that got added to the cmdlog would mark it as modified. Actually that would be pretty sweet..

Looking at this one again. I implemented the title fix (confirm quits while thread still in progress), but I don't like it, as the vast majority of the time I quit with threads running, it is inconsequential (e.g. a sheet is still loading but I can tell it's the wrong file/format; or a long-running operation like sort), or intentional (I started too many threads and want to quit immediately before it gets out of control). In fact I'm wondering now if perhaps the only in-progress thread we want to quitguard is a saver.

However, I don't want to make this decision unilaterally since I don't use the quitguard option myself. So, does anyone want confirm-quit-on-unfinished-threads for anything other than saving?

Also I prototyped the "confirm-quit-on-modify" functionality mentioned elsewhere in the comments here, and it's pretty tricky (and is complicated by undo). I suggest we split this second one out into another issue so we can discuss it separately.

So, does anyone want confirm-quit-on-unfinished-threads for anything other than saving?

I think you hit the nail on the hand, and saving is the primary use-case! I agree that the other scenarios would be frustrating.

Further input: https://twitter.com/phil_yen/status/1222043080582238210

Instead of adding another confirm(), I decided that saving was important enough that vd should simply wait for save_ threads to finish before quitting. Then if you still want to abort the save, Ctrl+C works.

Was this page helpful?
0 / 5 - 0 ratings