I used this regexp to search for multi-line docstrings: """.*(?<!""")\n
Here's a regexp to search for class docstrings: class .*\n\s*"""
in case that's useful later.
This has upsides and downsides.
- It's less verbose in most cases
- But event.offset I can't use unless I define that myself.
(I wasn't even taking full advantage of this property.)
- It's clearer what's used because what is used has to be copied.
- But what's used has to be copied.
Regarding "Initial document is zero wide to avoid an extraneous character at (0,0)",
this is not necessary anymore since I (recently) changed it to set, rather than append, values.
Regarding "...but needs one row to avoid IndexError", this commit removes that constraint.
It could now be initialized with size (1, 1) or (0, 0) or even (1, 0) I suppose, although that's not really a contender.
- Will this make the files smaller when compressed? Doubtful.
- Will this commit make the repo larger? Yes, since the old is kept.
- But keeping the files in line with current encoding will allow me
to see changes in encoding, using --recode-samples.
- I'm excluding files not saved with the app:
generated files (4x4_font_template.ans and gradient_test.ans)
which will be recreated in their original form when regenerating,
and a manually created empty file (0x0.ans), which tests the minumum
document size of 1x1.
With the more general type, it was giving:
/home/io/Projects/textual-paint/src/textual_paint/paint.py:798:38 - error: Cannot access member "markup" for type "ConsoleRenderable"
Member "markup" is unknown (reportGeneralTypeIssues)
/home/io/Projects/textual-paint/src/textual_paint/paint.py:798:16 - error: Type of "markup" is unknown (reportUnknownMemberType)
/home/io/Projects/textual-paint/src/textual_paint/paint.py:798:38 - error: Cannot access member "markup" for type "RichCast"
Member "markup" is unknown (reportGeneralTypeIssues)
/home/io/Projects/textual-paint/src/textual_paint/paint.py:798:38 - error: Cannot access member "markup" for type "str"
Member "markup" is unknown (reportGeneralTypeIssues)
/home/io/Projects/textual-paint/src/textual_paint/paint.py:798:16 - error: Return type is unknown (reportUnknownVariableType)
This fixes loading samples/4x4_font_template.ans, and I should be able
to rebase my code for more efficient ANSI file saving, where I was also
running into missing last rows.
- `observer` can be None, if --restart-on-changes was not passed, but
the hotkey F2 is pressed.
- `is_alive` is a bound method, not a property. It was definitely used
like a property in the code I referenced.
I didn't fix these type checker errors for a long time because:
1. they never caused actual problems for me, and
2. when adding a type annotation `observer: Observer | None`, Pyright
gets even _more_ confused, saying it's Unknown | None instead of
BaseObserver | None. The secret trick was to leave it unannotated.
3. Adding parentheses to make it `is_alive()` also made Pyright seem
even more confused, saying it was Unknown — until I added the
conditional.
Type of "schedule" is partially unknown
Type of "schedule" is "(event_handler: Unknown, path: Unknown, recursive: bool = False) -> ObservedWatch"PylancereportUnknownMemberType
Ooh, more importantly than running in parallel, this actually fixes
error handling. I had chmodded a file to be read-only for testing,
and this is failing on it loudly instead of silently ignoring an error
that I didn't know about! Because it was silenced! That was a bit of a
redundant way of saying that, but better to be heard than be SILENT...!
*crickets*
