rjust and ljust has wrong offset

[eproxus]

>>> print "{}".format(colored.red("hello")).rjust(12)
hello
>>> print "{}".format(colored.red("hello")).rjust(20)
     hello
>>> print "{}".format("hello").rjust(20)
               hello

[thomasballinger]

What was your use case? It looks like the calls can be swapped:

>>> print clint.textui.colored.red("{}".format("hello").rjust(20))
               hello
>>> print clint.textui.colored.red("{}".format("hello").rjust(12))
       hello
>>> print "{}".format("hello").rjust(20)
               hello

Sounds like the docs should have a warning about this. Is there interest in making this work? Seems pretty messy, but I guess a different class could be used for the output of colored.red which implements it's own rjust etc. and keeps track of the normal string part and the terminal color characters.

[eproxus]

Yeah, a custom class would work. Any chance the colored classes could implement that method?

[thomasballinger]

That approach would make more sense to me. That doesn't make your example work though, does it?
The result of

"{}".format(colored.red("hello"))

is a string, which we couldn't call a custom rjust on. That would allow

"{}".format(colored.red("hello").rjust(20))

to work though.

[eproxus]

Yup, you can't make the escape code characters just disappear. :-)

[aerenchyma]

What do you think about defining __getattr__ such that any string method would work on a colored string?

Like this:

def __getattr__(self, att): 
       def func_help(*args, **kwargs):
           getatt = getattr(self.s, att)(*args, **kwargs)
           return ColoredString(self.color, getatt)
       return func_help

This code above solves the .ljust() and .rjust() problem. After some editing and discussion with thomasballinger , it also works for all other string methods with two exceptions and one note:

• any string method that returns a list would be dealt with the same way .split() currently works.
• .join() does not work with ColoredStrings
• __add__ adds plain strings, not ColoredStrings, but I would think that's the functionality that would be wanted anyway

Also have a fix for just this bug, but if you're amenable to this idea, it seems useful. Is this fix interesting to you? Or would you prefer that the code were clearer or more separate?

[eproxus]

Great idea! I think that follows the principle of least surprise, so I'm all for it.

[thomasballinger]

see #57