Issue 1471 Cope with darcs --repo foo whatsnew

Title Cope with darcs --repo foo whatsnew
Priority wishlist Status given-up
Milestone Resolved in
Superseder general purpose command line parsing library (CmdArgs)
View: 1550
Nosy List darcs-devel, dmitry.kurochkin, kowey, twb
Assigned To
Topics UI

Created on 2009-05-27.03:09:51 by twb, last changed 2017-07-30.23:55:40 by gh.

msg7846 (view) Author: twb Date: 2009-05-27.03:09:48
Currently you can say

    darcs <command> <option>

but you can't say

    darcs <option> <command>

I believe this could be fixed in the code by "moving" the first
non-hyphenated argument to the front of the list of arguments.

This is particularly annoying when you want to run several different
commands with the same option.  The most common case for me is when I
want to keep --repo the same.  For example,

    $ darcs --repo foo w
    # I type previous-input, backwards-word, kill-word, then "rec".
    $ darcs --repo foo rec

Instead I have to type

    $ darcs w --repo foo
    # I type previous-input, beginning-of-line, forward-word, kill-word, then "rec"

Though usually I don't think of that, and instead type backwards-word
several times to get "past" the static argument, to the command.
msg7848 (view) Author: igloo Date: 2009-05-27.12:11:46
Your proposed fix would make darcs treat
    darcs --repo foo w
    darcs foo --repo w
msg7851 (view) Author: twb Date: 2009-05-28.00:55:06
On Wed, May 27, 2009 at 12:11:50PM -0000, Ian Lynagh wrote:
> Your proposed fix would make darcs treat
>     darcs --repo foo w
> like
>     darcs foo --repo w

Good point.  Obviously this requires a little more thought that it
first appears :-)

The getopt libraries I've used in the past have the form

    getopt :: OptionMetadata    --^ telling it what options to expect
           -> [String]          --^ the arguments
           -> ([Option],        --^ the parsed options
               [String])        --^ the remaining arguments, including
                                    stuff after the first "--" argument.

I guess currently Darcs manually extracts the command (and subcommand)
before it calls getopt.  Perhaps it could call getopt first, then
take the head of the unparsed arguments to be the command?
msg8030 (view) Author: kowey Date: 2009-08-06.14:30:46
Getting little details like this right is why I would like to see a generic
command/sub-*command/switches parsing library on hackage one day.
msg8334 (view) Author: kowey Date: 2009-08-22.00:37:24
I think we should raise the bar on this and just refuse any more fanciness of
the sort until somebody sits down and works out a proper library for it.  See
issue1550.  Don't let our desire to improve darcs make it more complicated and
harder to maintain.
Date User Action Args
2009-05-27 03:09:52twbcreate
2009-05-27 12:11:50igloosetstatus: unread -> unknown
nosy: + igloo
messages: + msg7848
2009-05-27 12:12:14igloosetnosy: - igloo
2009-05-28 00:55:09twbsetnosy: kowey, simon, twb, thorkilnaur, dmitry.kurochkin
messages: + msg7851
2009-08-06 14:30:50koweysetpriority: wishlist
nosy: kowey, simon, twb, thorkilnaur, dmitry.kurochkin
topic: + UI
messages: + msg8030
2009-08-22 00:37:27koweysetstatus: unknown -> deferred
nosy: kowey, simon, twb, thorkilnaur, dmitry.kurochkin
superseder: + general purpose command line parsing library (CmdArgs)
messages: + msg8334
2009-08-25 17:45:21adminsetnosy: + darcs-devel, - simon
2009-08-27 14:29:11adminsetnosy: kowey, darcs-devel, twb, thorkilnaur, dmitry.kurochkin
2010-04-04 19:14:52koweysetstatus: deferred -> waiting-for
nosy: - thorkilnaur
2017-07-30 23:55:40ghsetstatus: waiting-for -> given-up