I am following gh's advice [see issue2350] to turn this into an
independent proposal.

The idea is to allow users to define their own aliases for darcs
commands. Aliases are currently hard-coded, and in order to keep the
visible user interface clean and orthogonal, they are not listed by
--help or --commands. The proposal is to remove all hard-coded aliases
and instead provide a way for users to create and remove aliases at will.

One option would be a separate configuration file, as in

> cat ~/.darcs/alias
amend-unrecord amend-record --unrecord
unpull obliterate

Another option (which I find more elegant) is to extend the defaults
file syntax with an 'alias' keyword. Here are some examples:

record prompt-long-comment

This is the old style definition for a default option.

default whatsnew --interactve

The same, only with the keyword 'default' added in front, and with the
two option dashes not erased. NB, not leaving off the option dashes is
much more readable!

This is for consistency of the new syntax. For compatibility, 'default'
is the default (sic!).

alias amend-record amend --record
alias amend-unrecord amend --unrecord

These lines demonstrate alias syntax. They declare two new aliases
(amend-record and amend-unrecord) to be synonymous with 'amend' with
different options.

Without wanting to turn this into an everything-bug, the plugin
mechanism wishlist item may be relevant as there could be room for a
shared config

On 8 April 2014 22:39, Ben Franksen <bugs@darcs.net> wrote:
>
> New submission from Ben Franksen <benjamin.franksen@helmholtz-berlin.de>:
>
> I am following gh's advice [see issue2350] to turn this into an
> independent proposal.
>
> The idea is to allow users to define their own aliases for darcs
> commands. Aliases are currently hard-coded, and in order to keep the
> visible user interface clean and orthogonal, they are not listed by
> --help or --commands. The proposal is to remove all hard-coded aliases
> and instead provide a way for users to create and remove aliases at will.
>
> One option would be a separate configuration file, as in
>
>> cat ~/.darcs/alias
> amend-unrecord amend-record --unrecord
> unpull obliterate
>
> Another option (which I find more elegant) is to extend the defaults
> file syntax with an 'alias' keyword. Here are some examples:
>
> record prompt-long-comment
>
> This is the old style definition for a default option.
>
> default whatsnew --interactve
>
> The same, only with the keyword 'default' added in front, and with the
> two option dashes not erased. NB, not leaving off the option dashes is
> much more readable!
>
> This is for consistency of the new syntax. For compatibility, 'default'
> is the default (sic!).
>
> alias amend-record amend --record
> alias amend-unrecord amend --unrecord
>
> These lines demonstrate alias syntax. They declare two new aliases
> (amend-record and amend-unrecord) to be synonymous with 'amend' with
> different options.
>
> ----------
> messages: 17301
> nosy: bf
> priority: wishlist
> status: unknown
> title: user defined command aliases
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2371>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



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

Ben Franksen writes:

 > Another option (which I find more elegant) is to extend the defaults
 > file syntax with an 'alias' keyword.

I suspect this is not backward-compatible, which could be quite
annoying for developers trying to help people with older versions.

It *is* fully compatible considering that the new syntax is active only
if the line starts with a keyword, and that neither 'alias' nor
'default' ever were valid command names.

It is also future proof, in that darcs can (and should!) ignore lines
not starting with a valid command or keyword. This means we can add more
keywords in the future and are completely free as to how the rest of the
line gets interpreted.

BTW, I am not wedded to the syntax, it was just the first I could think
of. If someone has a better idea, please come forward.

Ben Franksen writes:

 > It is also future proof, in that darcs can (and should!) ignore
 > lines

"Can" and "should" are not considerations for backward compatibility.
The question is "does [darcs ignore invalid/meaningless syntax in that
file]?"

Stephen, I really tried, but I do not understand what you worry about.
Can you give me just one example, a concrete scenarion where the new
syntax leads to a compatibility problem?

Ok I understand now. What you are asking for is not backward but forward
compatibility! That is, can an old version of darcs be used if the
defaults file contains line with the new syntax? (Backward would mean:
does the new darcs still understand old-style defaults file.)

Well, it turns out the proposal is even able to take that hurdle. I
wrote the line 

  alias amend-record amend --record

at the top of my defaults file and everything works just fine (with HEAD
and 2.8.4). So, yes: for the two versions I tested this, darcs *does*
ignore invalid/meaningless syntax.

Ben Franksen writes:

 > at the top of my defaults file and everything works just fine (with HEAD
 > and 2.8.4). So, yes: for the two versions I tested this, darcs *does*
 > ignore invalid/meaningless syntax.

Good!