Upgrade to wcwidth 0.3.1, drop Python 3.7

[jquast]

CI

• drops Python 3.7
  • because wcwidth doesn't support it
  • I guess because of the new pyproject.toml stuff, wcwidth wasn't compatible
• bugfix build dupes, do not "double-build" all tests (push and pull)
• bugfix enforcing pty window size with semaphore
  • similar to how pexpect / pty_process project does it

Performance

• Upgrade dependency wcwidth to 0.3.1 (today's release)
• Replace custom Sequence method implementations with wcwidth's new functions: ljust(), rjust(), center(),
  clip(), and width() using control_codes='ignore', new since 0.3.0.
• See benchmark results below

2 Changing Behaviors

1. The length() method now returns maximum cursor extent rather than final relative cursor position:

• term.length('x\b') was 0, now 1!
• term.length(f'{"_" * 10}{term.cub(10)}') was 0, now 10!

This is preferred !

I think blessed is doing this wrong by default -- the most common use case is only, "how much screen real estate this takes up", and, likely to use direct cursor positioning yourself to display each wrapped/centered/etc line -- the ending position of the cursor has no consequence.

2. The truncate() method now fills with space when a wide character doesn't fit:

For leading space this new behavior is absolutely necessary, like if we wanted to do horizontal scrolling of CJK characters, to do this 1 cell at a time will require an oscillating leading ' ' at the beginning of the string.

    >>> wcwidth.clip("AB\uff23", 0, 3)
    'AB '
    >>> wcwidth.clip("AB\uff23", 0, 4)
    'ABＣ'
    >>> wcwidth.clip("\uff23BA", 0, 4)
    'ＣBA'
    >>> wcwidth.clip("\uff23BA", 0, 3)
    'ＣB'
    >>> wcwidth.clip("\uff23BA", 1, 3)
    ' B'
    >>> wcwidth.clip("\uff23BA", 1, 4)
    ' BA'
    >>> wcwidth.clip("\uff23BA", 0, 4)
    'ＣBA'

I admit trailing space is a little bit questionable, we want a string "no wider than x", and if it is less that is probably fine and there is no need for trailing space, the caller could use 'ljust()' to padd it if necessary, this is just how it worked out in the wcwidth implementation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.42%. Comparing base (db76f55) to head (bf52ae2).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #344      +/-   ##
==========================================
- Coverage   98.45%   98.42%   -0.03%     
==========================================
  Files          11       11              
  Lines        2649     2607      -42     
  Branches      471      460      -11     
==========================================
- Hits         2608     2566      -42     
  Misses         31       31              
  Partials       10       10              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will improve performance by ×410

_{Comparing jq/wcwidth-0.3.0 (bf52ae2) with master (db76f55)}

Summary

⚡ 12 improved benchmarks
✅ 16 untouched benchmarks

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_center_ansi	676.1 µs	377.6 µs	+79.05%
⚡	test_truncate_emoji_zwj	5.2 ms	1.6 ms	×3.2
⚡	test_center_ascii	104.8 µs	61.2 µs	+71.3%
⚡	test_length_ascii	98.4 µs	87 µs	+13.13%
⚡	test_truncate_ansi	46.1 ms	32 ms	+44.1%
⚡	test_length_ansi	673 µs	507.1 µs	+32.69%
⚡	test_rjust_ansi	672.1 µs	375.6 µs	+78.95%
⚡	test_ljust_ansi	672.1 µs	377.8 µs	+77.88%
⚡	test_rjust_ascii	99.7 µs	58 µs	+71.92%
⚡	test_ljust_ascii	100.2 µs	58.8 µs	+70.61%
⚡	test_truncate_cjk	14.2 ms	7 ms	×2
⚡	test_truncate_ascii	33,585.7 µs	82.6 µs	×410

[avylove]

3.15 was optional because it's still pre-release, scheduled for release in October. That said, it's probably more signal than noise at this point. Are you thinking we'll add optional back if that changes or when we switch to testing 3.16 pre-release?

[jquast]

I just figured since we fixed the textwrap compatibility issue, I have never seen any failing tests since then so it is no harm

[avylove]

I just figured since we fixed the textwrap compatibility issue, I have never seen any failing tests since then so it is no harm

I think you're right, though maybe better to comment out the line so we don't forget we can just mark it optional if it starts failing again and it's not a quick fix.

[jquast]

I reverted it to make 3.15 optional, again.