From #717: Regression introduced in ef91741.

Pinging @ata2001.

I'm on it.

Okay, curtsies.formatstring.width_aware_slice() is slow for some reason on long strings. It becomes much faster when you pass the string in smaller chunks.

For example:

print("\x1b[31mhello" * 1000)

won't hang because it gets converted to an FmtStr as 1000 chunks instead of one string

>>> msg = fmtstr("\x1b[31mhello" * 1000)                                                                                                             [42/1785]
>>> msg
red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+re
d('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red(
'hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('h
ello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hel
lo')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello
')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')
+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+r
ed('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red
('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')...

This is definitely a curtsies issue, I'm going to create a PR optimizing curtsies.formatstring.width_aware_slice().

I took the freedom of overtaking you.

is that fix above the solution to the problem or just a workaround?

It's the actual solution. At least it takes the part of the code which is responsible for being slow and makes it so fast that it should no longer be the bottleneck.

This has been merged and a new release of Curtsies (0.2.12) has @BenWiederhake's patch. This is a big improvement that will help users now (there are at least 4 issues that are dups of this) so big thanks to @BenWiederhake. The behavior is from the bpython side is still empirically quadratic

so still needs some work.

Since this was introduced by width_aware_slice in ef91741 we might need to revert that. I don't remember the specific cases this was important for, should figure this out.

I've written a linear version of the line splitting behavior that made this still quadratic despite @BenWiederhake fix in curtsies with bpython/curtsies#110 but in the meantime we've stopped using the width-aware solution and released 0.17.1 to fix this behavior.

I'm not totally clear on what width-awareness was solving for us – seems like some edge cases around where to wrap lines that have double-width characters or combining characters in them, but there haven't been any open issues about that. Eventually we can use this for formatting input and correctly position the cursor in the case of double-width and combining characters, but no issues open about that. I'm going to hold off on #731 until the case for why we need it is clearer and we're confident it doesn't cause any regressions.