Fix bug with ANSI concatination.

This commit is contained in:
Jonathan Piacenti 2015-03-11 19:25:06 -05:00 committed by Griatch
parent 571b1d5fad
commit b50dbdc651
2 changed files with 17 additions and 2 deletions

View file

@ -618,7 +618,7 @@ class ANSIString(unicode):
code_indexes.extend(
cls._shifter(second._code_indexes, len(first._raw_string)))
char_indexes.extend(
cls._shifter(second._code_indexes, len(first._raw_string)))
cls._shifter(second._char_indexes, len(first._raw_string)))
return ANSIString(raw_string, code_indexes=code_indexes,
char_indexes=char_indexes,
clean_string=clean_string)
@ -660,7 +660,7 @@ class ANSIString(unicode):
a start and end with [x:y], but many forget that they can also specify
an interval with [x:y:z]. As a result, not only do we have to track
the ANSI Escapes that have played before the start of the slice, we
must also replay any in these intervals, should the exist.
must also replay any in these intervals, should they exist.
Thankfully, slicing the _char_indexes table gives us the actual
indexes that need slicing in the raw string. We can check between

View file

@ -135,6 +135,21 @@ class ANSIStringTestCase(TestCase):
self.assertEqual(mxp1, ANSIString(mxp1))
self.assertEqual(mxp2, unicode(ANSIString(mxp2)))
def test_add(self):
"""
Verify concatination works correctly.
"""
a = ANSIString("{gTest")
b = ANSIString("{cString{n")
c = a + b
result = u'\x1b[1m\x1b[32mTest\x1b[1m\x1b[36mString\x1b[0m'
self.checker(c, result, u'TestString')
char_table = [9, 10, 11, 12, 22, 23, 24, 25, 26, 27]
code_table = [
0, 1, 2, 3, 4, 5, 6, 7, 8, 13, 14, 15, 16, 17, 18, 19, 20, 21, 28, 29, 30, 31
]
self.table_check(c, char_table, code_table)
class TestIsIter(TestCase):
def test_is_iter(self):