New submission from Eric Kow <[EMAIL PROTECTED]>: Basic idea is that
(1) interactive commands which deal with 'changes' (i.e. record, amend, revert, unrevert) should implement the 'v' command (2) pressing 'h' should not display the current patch (as it may be very long), but remind the user to press 'v' to see the current patch again 17:31:20 < fasta> When I do darcs record; <press ?>, the help message is shown _above_ my patch, making the help message invisible. How is this caused? Do I have a bad terminal or is this a darcs bug? 17:33:26 < fasta> 1.0.9rc1 (release candidate 1), btw 17:33:27 < kowey> fasta: i think the problem is that if we did it the other way around, you'd have to scroll past the help message to see what your patch is 17:33:50 < kowey> which might also be confusing 17:34:26 < fasta> kowey: well, I would say that pressing ? means the user wants to see what all the options mean. The user can later press another key to see the patch again. 17:34:51 < kowey> hmm... maybe record should have a 'v' option 17:34:59 < kowey> (in the interactive dialog) 17:35:03 < fasta> right 17:35:50 < kowey> sounds like the kind of thing you'd want to discuss on the -users list 17:36:25 < kowey> arguments you might expect to respond to are what i suggested, and "oh adding a v switch just for that purpose might introduce clutter" 17:37:09 < kowey> or maybe... 17:37:20 < kowey> the help screen, and only the help screen could say "hit v to see your patch again" 17:38:02 < fasta> kowey: yes, I guess "designing" an application to make everyone instantly happy is quite difficult. :) 17:38:45 < kowey> yeah... i wish we had some people on board that had insight into this kind of stuff 17:48:09 < kowey> another idea is that help should 'block' the interactive dialog - and you'd have to hit Esc or something to exit help 17:49:35 < fasta> kowey: if the message fits in the whole screen, that is better, yes. 17:49:58 < fasta> kowey: hitting any key might be better 17:50:29 < kowey> i'm not sure about that - i wouldn't want the user to hit a key (thinking they were saying yes to a patch) 17:50:35 < kowey> and not have it taken into account 17:51:17 < kowey> i also don't want the user to "worry" about accidentally sending commands to the interactive dialog 17:51:24 < kowey> like "what if i accidentally hit y twice" 17:52:41 < fasta> kowey: you can ignore keys pressed in rapid succession. 17:52:49 < fasta> kowey: e.g. .5 seconds. 17:53:00 < kowey> well, i'm more thinking of the user model of darcs 17:53:15 < kowey> in a sense, having a priviledged 'get-out-of-help' key 17:53:22 < fasta> kowey: although, maybe Esc is indeed better. 17:53:30 < kowey> guarantees to the user that trying to get out of help won't make anything else happen 17:53:50 < kowey> it is a trade-off though... because now if the help screen blocks the whole dialog, we lose a little immediacy 17:54:13 < kowey> for example, it's not longer "what was that command to get out of darcs? <h> .... ah, it's q! <q>" 17:54:33 < kowey> but "<h>... ah! it's q <q>... wait nothing happened... oh! <Esc> <q>" 17:54:52 < fasta> kowey: I think it would be best to just display the output of the help directly, and not above the patch. 17:55:04 < fasta> kowey: then just do v to view the patch. User model did not change. 17:56:08 < kowey> yeah, that's probably the conservative way to go about it... other commands have 'v' anyway 17:57:53 < kowey> i think you should submit something to [EMAIL PROTECTED], proposing these two changes together (1) help should only display help (2) all commands should have a 'v' option, including record 17:59:02 < kowey> well, you'd also have to think about how help works in other commands, maybe (1) only applies to record 17:59:42 < kowey> or more precisely, to commands that deal with individual changes (hunks, etc), as opposed to darcs patches 17:59:54 < kowey> (revert, unrevert, amend, record) ---------- messages: 1385 nosy: EricKow, beschmi, droundy, tommy priority: wishlist status: unread title: interactive 'h' should not be hidden by long patches topic: ProbablyEasy ____________________________________ Darcs issue tracker <[EMAIL PROTECTED]> <http://bugs.darcs.net/issue379> ____________________________________ _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
