I think it’s fairly common that, when you want to get a change, it’s the last one you want. Can we either
-
make “last” the default, i.e. snap tasks -> you get the last change
con of this is that it’s not entirely obvious that you’re getting the last change
-
make snap tasks --last work
con of this is that the options parser we have doesn’t make it easy to have “this argument is required unless this flag is set” (i.e., more manual option wrangling)
-
make snap tasks last work
con of this is that if changes ever become alphanumeric, we need extra special wrangling. Also “snap tasks last” sounds like an order, not a request
any others?
One concern I have with this is that it encourages a use pattern which is naturally flaky. We can’t ever tell what the last one really is, but I suspect that when people type out --last, they’ll be thinking of that one, if you see what I mean, but may be surprised by something else entirely that has shown up since they did the manual action.
One way around that would be to offer a more stable view. For example, we might have a --refresh flag, which shows the last refresh available, and --install, with the respective semantics, etc.
What do you think?
also there’s auto refreshes that could happen any time in between
As long as we skip the empty ones, that’s perhaps okay. The command might actually be looking for the auto refresh itself.
I’ll be happy to work on that next, unless this is something you wanted to do @chipaca? The idea to have --refresh and --install flags etc. looks sensible to me. I can start working on this soon once I land some of my current PRs.
snap tasks --last <verb> with verb being refresh, install, etc? Is that doable even?
1 Like
FTR I’m not too worried about who gets to make things better as long as they get better 
That sounds good, and yeah, it seems easily doable.
