http://darcs.net/manual/node8.html#SECTION00854000000000000000 :

"If you prefer to choose a different set of characters to define your token
(perhaps because you are programming in some other language), you may do so with
the --token-chars option. You may prefer to define tokens in terms of delimiting
characters instead of allowed characters using a flag such as --token-chars '[^
\n\t]', which would define a token as being white-space delimited."

10:30 AM] 1.2Mb$ darcs replace --token-chars '[^\ \n\t]' foo bar *

darcs failed:  Bad token spec: '[^\ \n\t]' (Space is not allowed in the spec)
[10:30 AM] 1.2Mb$ darcs --version
2.2.0pre2 (+ 88 patches)

---

On a side note, does anyone know why this fails? I've read the manual but it
doesn't help much:

[10:31 AM] 1.2Mb$ darcs replace
"https://secure.wikimedia.org/wikipedia/en/wiki/" "Wikipedia" Threats.page 
darcs failed:  'https://secure.wikimedia.org/wikipedia/en/wiki/' is not a valid
token!

The following patch updated the status of issue1373 to be resolved:

* Resolve issue1373: make --token-chars [^ \t\n] work as advertised. 
Ignore-this: 2588b1d862a2d5e20ede58c8b56f6168

# Rollback issue1373 fix, which causes a regression.

I get the impression that the core implementation for darcs replace is actually
quite simple and straightforward (see the RegChars module and forceTokReplace)

I need somebody to study the code more closely.

1. Is there any reason in the core that spaces should NOT be token characters? 
I don't get that impression by looking at forceTokReplace, but I could be mistaken.

2. Is there any reason they should not be explicit delimiter characters?  (It
sounds like this is very likely NOT, otherwise how would darcs replace even work
with the default token spec?)

3. (this requires studying the history and mailing list), what regression did
Trent's patch cause, exactly and why?

4. Notice the discrepency between Gwern's command and the code in Trent's patch.
 Is there any reason one would need to backslash the space? "\ "?  Or was that
just a flub?

If I we can get answers to these three questions, it sounds like we can move
forward on this, either by updating some documentation

That's easy Eric, the patch format uses spaces as separators. That's why we
have the in-house whitespace escaping in filepaths. Of course, no escaping is
done on tokenspec, so it can't contain spaces, and the format is set in stone,
so it cannot be changed. I'd argue for a wontfix. (You need a new patch type to
implement this in existing repoformat.)

Excellent!  We now have clarity on this.  Thanks, Petr!

Trent, may I assign this to you to clarify in the user manual why we can't have
spaces at all?