tokenize-786661: Param order: assert.is(actual, expected);

Unit tests in GCLI have changed. Originally assert.is() was called
equals() and the order was equals(expected, actual) because it seemed to
make sense to have the expected thing first, however if the function
name is 'is' then you have to put the 'actual' parameter first. When we
changed from 'equals' to 'is' (to match mochitest) we didn't swap the
orders of the params (but added new asserts the new way). This corrects
that and fixes the orders of the params.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Pass context to lookup/max/min

Some time ago we started passing context to parse, but now we need to
push it further, to lookup in selection and max/min in number.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: s/context/executionContext

Previously we split context into executionContext and conversionContext
but failed to propagate the change to a few places. This fixes those.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Remove unused function

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Expose the Event constructor

It's used by cli.js, and the basic Firefox JSM environment doesn't
expose this by default.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
tokenize-786661: Move some escaping to string type

There are 2 distinct reasons for escaping:
1. allow typing untypable chars (\t, \n, etc)
2. preventing gcli from treating chars like ', ", [space], {, } as
   special

So the tokenizer needs to think about 2, but not 1, and 1 should be
handled by the type system; just as we convert "42" to 42 when the type
is a number, so we should convert "\t" to a TAB char when the type is a
string.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Add basic DateType implementation

Work outstanding:
- Define valid input formats. Should probably include the format that
  cookies are defined in, along with a simple basic alternative and a few
  shortcuts, e.g.: 'now', 'tomorrow', 'yesterday'
- Implement parse function based on the above
- Think about step values for increment/decrement
- Complete tests

Rebased from d14bebafadf9eb9f6b4caad03c304cb5bf838110

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: This is a working prototype for a GCLI date type

This works in a demo command named "gcli onedate".
It supports the increment/decrement/parse/stringify operations, but not
min/max: I don't think they make sense for a date. Increments steps are
specifiable, and the unit is currently days. For example, with a step
of 5, 'Tue Jan 15 2013 15:46:29 GMT+0100 (CET)' becomes
'Sun Jan 20 2013 15:46:29 GMT+0100 (CET)'.

Issues:
* testDate.js has not been updated
* There is no integration with the cookie command yet
* MDN says that n should be between 1 and 31 for Date.setDate(n), but
  it seems to work with any number on Firefox and Chrome, and I "abuse"
  this behavior.

Signed-off-by: Quentin Pradet <quentin.pradet@gmail.com>
date-773271: Add new date type

This works in a demo command named 'gcli onedate' and is tested in
testDate.js. It supports the increment/decrement, parse/stringify and
min/max operations.

Increments steps are specifiable, and the unit is currently days. For
example, with a step of 5, 'Tue Jan 15 2013 15:46:29 GMT+0100 (CET)'
becomes 'Sun Jan 20 2013 15:46:29 GMT+0100 (CET)'.

Notes:
 * There is no integration with the cookie command yet.
 * MDN says that n should be between 1 and 31 for Date.setDate(n), but
   it seems to work with any number on Firefox and Chrome, and I "abuse"
   this behavior.
 * the parse() test assumes that two subsequent 'new Date()' will share
   the same second, but it's possible for the test to fail, especially
   on slow machines.
 * 'gcli twodates' is disabled since a bug prevents from having two
   parameters with spaces delimited by quotes and testing increments.

Signed-off-by: Quentin Pradet <quentin.pradet@gmail.com>
date-773271: Remove two console.log used for debugging

Signed-off-by: Quentin Pradet <quentin.pradet@cea.fr>
date-773271: Update date type to be async

Several tidy-ups, the biggest being that DateType is now asynchronous
(in that parse() returns a promise of a conversion rather than a
conversion like the other types)
We also added 'context' to the functions that should take it and did a
few tidy-ups to fit with the rest of the GCLI code.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: this._isValidDate -> isDate

I'm not sure we need to expose this function, and we're not using it
everywhere. Also we have a dateType._getDefault() function which is just
'new Date()' which seems like overkill.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Allow max/min dates as strings

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Fix Date.parse returns a int not a date

So we need to convert it to a date before we return it in the
Conversion

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Use reduced iso8601 as output format

The default date.toString() format is ugly, hard to read and not a
normal input format, so serialise dates using the ISO8601 format
(without the time component where possible) where we can.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Allow custom tests for arg values

Sometimes we can't provide an identity equals value for an argument
check, but we still want to check the properties of the value, so we
allow 'value' to be a function which we call, passing it the actual
value, and expect the function to call assert to prove that the provided
value is correct.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Add more unit tests for date types

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Fix test assumptions about timezone

One of the unit tests accidentally assumed GMT. It still assumes a
gregorian calendar, but we have not planned support for non gregorian
calendars so far.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
tokenize-786661: Minor comment update

Signed-off-by: Joe Walker <jwalker@mozilla.com>
date-773271: Inputter.setInput should move cursor to end

Previously, by ignoring caretChange, the default was to move to the next
argument, which was really arbitrary. Now it does the obvious thing of
moving the cursor to the end of the input.

Signed-off-by: Joe Walker <jwalker@mozilla.com>