1 patch for repository http://darcs.net:

Sun Sep 16 17:29:38 BST 2012  Dave Love <fx@gnu.org>
  * Resolve issue2236:  Make n a synonym for q in lastQuestion

Attachments

• patch-preview.txt
• resolve-issue2236_--make-n-a-synonym-for-q-in-lastquestion.dpatch
• unnamed

seems fine in principle
I still kind of think we should maybe just get rid of y/n for this
question and give people d/q instead

On 16 September 2012 18:29, Dave Love <bugs@darcs.net> wrote:
>
> New submission from Dave Love <fx@gnu.org>:
>
> 1 patch for repository http://darcs.net:
>
> Sun Sep 16 17:29:38 BST 2012  Dave Love <fx@gnu.org>
>   * Resolve issue2236:  Make n a synonym for q in lastQuestion
>
> ----------
> files: patch-preview.txt, resolve-issue2236_--make-n-a-synonym-for-q-in-lastquestion.dpatch, unnamed
> messages: 16094
> nosy: fx
> status: needs-screening
> title: Resolve issue2236:  Make n a synonym for q in lastQues...
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/patch942>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>



-- 
Eric Kow <http://erickow.com>

I think the duplication of code is a smell, an alias should reuse
existing code.

I'm in favour of having y/n as the options - the question is "Do you
want to push these patches?" my answer is either "yes, I do" or "no, I
don't, actually". I think d/q should be aliases of y/n (what does d
mean, anyway? "do"?)

Dave, do you mind making a follow up patch, that doesn't duplicate
implementation? Thanks.

Owen, when you were asking about d/q, did you mean in the context
of this last regrets prompt?

d/q are useful because they do something different in the patch selection
prompt; they allow you to terminate early

So my thinking behind the alternative approach (which should not get in
the way of Dave just following up with his intention to make an alias) is
that by offering *only* d/q we do two things:

1. we prevent people blazing through the last regrets prompt by accident
(a bit similar to how we sometimes make people type "yes")

2. we train people to use d/q, which I think cuts some of the too-many-prompts
frustration.

I guess 2 is a bit dubious though; there's no evidence to suggest that people
who take the last-prompt d/q and generalise it to patch selection usage.

Also it comes at a very heavy price of people not generally knowing what
they're supposed to do.



On 21 September 2012 00:15, Owen Stephens <bugs@darcs.net> wrote:
>
> Owen Stephens <darcs@owenstephens.co.uk> added the comment:
>
> Dave, do you mind making a follow up patch, that doesn't duplicate
> implementation? Thanks.

-- 
Eric Kow <http://erickow.com>

> Owen, when you were asking about d/q, did you mean in the context
> of this last regrets prompt?

Yes

> d/q are useful because they do something different in the patch selection
> prompt; they allow you to terminate early

Right, I understand that, during the actual selection.

> So my thinking behind the alternative approach (which should not get in
> the way of Dave just following up with his intention to make an alias) is
> that by offering *only* d/q we do two things:

But the final question is: "You've selected these patches, do you want
me to do
this thing to them?" It's a yes/no question. If no, quit, if yes, do it.
(obviously we also allow users to list the changes or to go back and select
again)

What are the mnemonics for d/q in this situation? One thing that did
confuse me
is that 'd' at last regrets is a synonym for "yes" which is strange,
considering it's "don't" everywhere else :-)

> 1. we prevent people blazing through the last regrets prompt by accident
> (a bit similar to how we sometimes make people type "yes")

Ah, yes, I hadn't thought of that but, meh :-) I don't think it's that
much of
an issue.

> 2. we train people to use d/q, which I think cuts some of the
too-many-prompts
> frustration.

Yeah, maybe, I'm not convinced though... I'd be happier if we could
figure out
a way to make last-regrets be a wee bit smarter (such as not prompting
if I've
selected 0 patches, or perhaps only if I've selected 1).

> Also it comes at a very heavy price of people not generally knowing what
> they're supposed to do.

Yes, I think this is important!

> But the final question is: "You've selected these patches, do you want
> me to do
> this thing to them?" It's a yes/no question. If no, quit, if yes, do it.
> (obviously we also allow users to list the changes or to go back and select
> again)

Well this can rephrased.  For example,

Almost there! Hit 'd' if you have you're happy for me to push these 42
(out of 90)
patches. If not, you can revisit your selection with 'j/k' or 'q' to abort.

> What are the mnemonics for d/q in this situation? One thing that did
> confuse me
> is that 'd' at last regrets is a synonym for "yes" which is strange,
> considering it's "don't" everywhere else :-)

[d]one
[q]uit

as usual

>> 2. we train people to use d/q, which I think cuts some of the
> too-many-prompts
>> frustration.

I think you're right to be sceptical.  I admit there's a strong chance
I'm just being crazy here, and am not too strongly attached to the
idea.


-- 
Eric Kow <http://erickow.com>

Owen Stephens <bugs@darcs.net> writes:

> Dave, do you mind making a follow up patch, that doesn't duplicate
> implementation? Thanks.

I think you chaps should sort out what to do generally, but I do expect
to be able to answer "n" there.  (For what it's worth "last regrets"
probably doesn't mean anything to others searching issues and archives,
though I'm probably not one to talk about such things...)

I don't see the problem with duplicating a few lines due to the Haskell
case syntax myself.

> I don't see the problem with duplicating a few lines due to the 
> Haskell case syntax myself.

But there is a simple solution for the case expression, using guards, as
demonstrated for y/d/a a few lines above.
Semantically, it's also nicer, since you're making it clear that your
intention really is to make an alias, and nothing more.

For the option lists, it's less easy, but I'm sure something can be done
with a where block. I suppose that am just a bit wary of the slight
increase in the chance for bit-rot/divergence in UI messages, with
duplicated code like this...

The following patch actually did the job:

patch 7843e9ea4646243342374c0159d795f64a3e4d50
Author: "Gian Piero Carrubba" <gpiero@rm-rf.it>
Date:   Thu Dec 13 03:38:12 -03 2012
  * resolve issue2236: make 'n' an alias for 'q' in lastregret questions