Hi Florent
thanks for your reply. You raise a number of interesting issues. And, BTW,
let me make it clear that a lot of work has already been done during the
last years (for instance that push and pull no longer --set-default),
something I much appreciate.
Florent Becker wrote:
> Benjamin Frankes wrote:
>> Apropos, some UI changes I'd like to propose to make the darcs experience
>> more predictable and even more useful than it already is:
>>
>> changes:
>> --interactive should be the default; displaying the complete history of
a
>> repository in one big rush is almost never what you want, except for
>> scripts that analyse the repo, and the default UI should always be
>> optimized for the interactive user.
>>
> +1, but the hunks within each patch should be shown one by one, like we
> do now.
Florent Becker wrote:
> Of course, I mean all at once, *not* one by one.
Agreed, since that is a different issue (see below on whatsnew command, the
'i' keybinding would apply here, too, of course).
>> whatsnew:
>> should have a --interactive option (which should be the default),
>> the idea is hunks (and replaces, etc) are displayed one at a time;
>> I'd also like to have an option to select the type of change that
>> whatsnew reports, e.g --replace-only or --hunk-only.
>>
>
> having --interactive is probably a good idea, making it the default
> probably not: unrecorded changes tend not to be too numerous (at least
> in my use), and interactive prompting when there's no input to be had
> from the user is an annoyance.
I had the situation in mind where you /do/ have lots of unrecorded changes.
I like to avoid that, too, but sometimes it is hard to find a good point
where to stop, so to speak, because a change may need major and wide-spread
refactoring and I like my project history clean.
I can live well with whatsnew --interactive not being the default as long as
the switch is there and I can /make/ it my default.
> For consistency, within 'pull', 'changes' and other commands which
> display patches, we could add a 'i' keybinding for listing hunks
> interactively. Would you find that useful?
This is an excellent idea. I almost never use 'v', the output is just too
much most of the time. However, once inside the hunk-level view we'd need
yet another binding to return back to the patch-level view ('r' for 'return'
comes to mind). And interaction with the -v (--verbose) command line switch
must be considered, too. I think we'd need --verbose-interactive or some
such to specify that 'i' should apply by default (for the current command),
just as --verbose means to apply 'v' by default.
>> send:
>> --interactive should be the default; furthermore, it should *ask*
whether
>> you want to edit the description, just as record does with the long
>> comment.
>>
>
> --interactive is already the default, as far as I can tell. Maybe you're
> referring to something else.
No, you are right, sorry. It wasn't the default some versions ago and I
still had it in my preferences.
> I'm not sure about asking whether to edit, it's yet another prompt, and
> you can simply quit your editor if you don't want to modify it
It is exactly the need to quit my editor that annoys me. Hitting 'n' is
faster and less disruptive of my work flow, compared to a large window
popping up that I have to close before I can continue.
According to my proposal users who wish to be asked less questions can avoid
it simply by adding either 'send edit-description' or 'send no-edit-
description' to their preferences. And they can still override their default
on a case-by-case basis by explicitly giving the opposite command line
switch.
Finally, this is where IMO consistency wins over all other considerations,
so if the new policy is 'avoid prompting the user if it can be helped' then
'darcs record' should be changed in the same way.
>> diff:
>> do not wait for the user to "Hit return to move on..."; I already
ordered
>> darcs to do what I told it to do, so why do I have to confirm? If the
idea
>> is to guard against (potentially destructive) errors in the
configuration
>> file, why not rather add a --dry-run option, so I can try any changes
out
>> and see what would be executed?
>>
>
> This is when using --diff-command, right?
Yes.
> I think this prompt is used in
> case the diff-command exits before the user is done (some graphical
> diffs do so, I think).
You mean programs that start the actual viewer as a background task (or send
the file or directory names to an already running demon task) and then exit,
so darcs thinks the user is done and deletes the temporary files/directories
it created for the diff... yeah, that's a problem. I see. For the same
reason you should not set DARCS_EDITOR to a GUI editor that just opens
another window of an already running editor process and then exits. I
actually made that mistake when I started working with darcs and kept
wondering why my long comments didn't make it into the repo...
Cheers
--
Ben Franksen
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
