Add support for negative indices to history command

[tleonhardt]

The built-in history command has a very powerful and flexible indexing/slicing syntax. One thing which it doesn't currently support is negative indices. It would be much more Pythonic to support negative indexing, so we should do it.

Make sure we update the documentation when this feature is added.

[kotfu]

Turns out we have code in History.get() to handle negative indices, it just behaves differently than python list indices. Here's the tests for that method:

    h = hist
    assert h == ['first', 'second', 'third', 'fourth']
    assert h.get('') == h
    assert h.get('-2') == h[:-2]
    assert h.get('5') == []
    assert h.get('2-3') == ['second']           # Exclusive of end
    assert h.get('ir') == ['first', 'third']    # Normal string search for all elements containing "ir"
    assert h.get('/i.*d/') == ['third']         # Regex string search "i", then anything, then "d"

The 3rd assertion doesn't make sense to me. It seems like we would want it to be:

    assert h.get('-2') == h[-2]

And I have no idea what the thinking was behind the 5th assertion.

I think the history argument should do one of five things:

• a positive integer n returns the nth history item (the first command entered is item 1, not 0). If there are less than n history items, return nothing.
• a negative integer n returns the nth most recent history item (i.e. -1 is the most recent history item, -2 is the second most recent history item). If there are less than abs(n) history items, return nothing.
• a..b where a and b are positive integers, returns a list of history items beginning at item a and up to and including item b. b must be greater than a. If a is omitted, assume 1. If b is omitted assume the size of the history items (i.e. include the last item in the list)
• if the argument begins and ends with a /, treat the characters in-between the slashes as a regular expression and return all history items that match the regex
• otherwise, treat the argument as a string and return any history item that contains that string

The side effect of these rules is that history 0 does a string search for input containing a zero, which I'm not sure is intuitive. Do we need a special case for history 0 and/or history 0..3?

[kotfu]

Oops, I think the history argument should do one of seven things. Here's two more to add to the list:

• n.. where n is a negative integer, return a list of history items from the nth most recent history item to the most recent history item
• ..n where n is a negative integer, return a list of history items from the first history item to the nth most recent history item

[tleonhardt]

I pretty much agree with everything you said. The only caveat being that I do like the regex search option embodied by the 5th assertion.

For history 0, I’d say anything castable to an int should be treatable as an int and 0 returns either nothing or a warning saying its an invalid index.

Other than being 1-based instead of 0-based, think indices should work just like they do for Python lists, at least as much as possible.

[kotfu]

Python lists slicing allows for 3 elements, where the 3rd element indicates an increment. For example:

>>> list
['a', 'b', 'c', 'd', 'e', 'f']
>>> list[::-1]
['f', 'e', 'd', 'c', 'b', 'a']
>>> list[2:5:2]
['c', 'e']
>>>

I don't think we should support this obscure 3rd slice element, but other than that, I agree we should make our history indices/slices work just like Python (except we are 1 based instead of 0 based).

[kotfu]

@tleonhardt do you mean the regex search option embodied by the 6th assertion? This one:

assert h.get('ir') == ['first', 'third']

In the code it's not a regex search, just a simple string search. If you type history . you will only get commands that include a period. if you type history /./ you will get all history items (since we don't add to history on empty commands).

[tleonhardt]

Yeah I think I meant the 7th assert. And agree that there is no need to support the 3rd slicing element for step size.