I like the general style of thinking below (thorough, careful, looking at the *whole* picture).
Unfortunately, I'm not yet really in a position myself to get into it (and was really just responding out of impulsiveness). I'd only add that we might have it in there out of desire for consistency across commands (but maybe minimising last regrets usage is important: for example, we try to avoid last regrets if there is only one prompt anyway?) I'm not sure destructiveness is really the decision basis, partly was about “aww, man, do I have to go through and make all my decisions again?”, but there is a more general point that for some commands, the alternative may be clunky (eg. you have to amend, or in the worst case, you have to unrecord and record again), but that the clunkiness may be a lesser evil than the last regrets I'll also throw in that the last time I complained about LR, Florent did successfully persuade me it was a useful thing to have. It's on IRC somewhere, probably ages back, shortly after the Southampton sprint, would be great to find the conversation again On 2 July 2013 17:04, Benjamin Franksen <benjamin.frank...@helmholtz-berlin.de> wrote: > Hi Eric > > Eric Kow wrote: >> I seem to remember this was under discussion, how to make the last >> regrets prompt less annoying. I'd suggest we avoid going down the >> route of making this configurable just to please people who both find >> it annoying and are willing to configure their darcs, and instead >> focus on the problem at hand. >> >> It's one of these seeming rock-and-hard-places problems: how else do >> we offer the ability to revisit the very last choice (not to mention >> the IMHO less important review function)? > > How about the following strategy: > > First and foremost, skip the last regrets question if the user's selection > amounts to a no-op. I hope this is un-controversial. Bonus points for > restoring the nice message that Darcs used to issue in that case. > > Next, decide for which commands the last regrets makes sense. For instance, > 'darcs record' can be so easily un-done (just say darcs unrecord), that IMHO > last regrets make little sense. The last regrets should be reserved for > operations that irreversibly destroy some information: unrecord, amend- > record, obliterate without -O (BTW, -O should be the default), etc. > > A more difficult candidate is pull; this is (or can be) destructive if you > have local unrecorded changes; I'd say push and pull should both check > whether allow-conflicts (marked or unmarked) is on and in case it is on the > last regrets make sense, else not. > > I would also exclude the cases in which Darcs asks for extra confirmation > anyway, such as when it says: "This will make unrevert impossible, are you > sure?". > > If we did all that together, systematically reviewing all commands under > this aspect, then I predict that the remaining last regrets questions will > not be considered annoying by anyone but instead as helpful. Problem solved. > > More bonus points for making the result of this review and the decisions > taken publicly visible in the form of a simple table on the wiki. Something > like > > Command Last Regrets Side Condition(s) > ---------------------------------------------------------------- > record no - > changes no - > unrecord yes chosen set of changes /= empty > rebase > unsuspend no - > suspend yes chosen set of patches /= empty > > etc, maybe with an added column for a short rationale. > >> I still hold that [dq] is better for last regrets than accepting [yn], >> precisely for the reason that it's easy to accidentally say yn when >> you don't mean it. (And that UIs should be designed to forgive users >> like me who tend to tell the computer things they don't really mean >> like ?yeah yeah, ok I really do want to delete that file? oh wait, no! >> what was I saying?! Argh!?) > > I fully agree with your reasoning: *if* we (and in consequence Darcs) decide > that it makes sense to ask the last regrets question, then it should not be > possible to accidentally answer it by hitting the [y] key once too often. > > Cheers > >> On 1 July 2013 13:56, Benjamin Franksen >> <benjamin.frank...@helmholtz-berlin.de> wrote: >>> This regularly happens to me lately: >>> >>> franksen@tiber: ...support/seq/branch-2-2 > darcs push >>> Mon Jul 1 14:37:59 CEST 2013 benjamin.frank...@helmholtz-berlin.de >>> * top level Makefile: pdf and docs no longer variables, restructured >>> extra >>> targets >>> Shall I push this patch? (1/1) [ynW...], or ? for more options: n >>> Do you want to push these patches? [Yglqk...], or ? for more options: q >>> push cancelled. >>> >>> I find the extra question extremely annoying, especially (but not only) >>> when I selected no patches as in the above example. The above always >>> makes me stop, thinking, "What? Did I accidentally press 'y' when I meant >>> to press 'n'? I'm sure I didn't!". >>> >>> I loved how Darcs used to tell me "You don't want to push any patches, >>> and that's fine with me!" which always made me smile, whereas the new one >>> makes me moan. >>> >>> Is there a switch that gets me back to old behaviour, preferably one that >>> I can put in my ~/.darcs/defaults? > -- > Ben Franksen > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachm?nts > > > _______________________________________________ > darcs-users mailing list > darcs-users@darcs.net > http://lists.osuosl.org/mailman/listinfo/darcs-users -- Eric Kow <http://erickow.com> _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users