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*
The backup of the current file will be deleted just after opening it.
I should probably actually prevent that, but this commit just fixes
an error message thrown up when trying to then open another file.
It said "File not found", but confusingly was not referring to the file
you were trying to open, but rather the currently open file.
Repro test steps:
Open a file (optional), make changes, and wait for backup to be saved;
open the new .ans~ backup file (discarding changes to the main file),
then try to open any file. "File not found" message should not be shown.
- This is shorter/cleaner.
- This is less prone to mistaken parentheses placement, although it
should give a type error to do `Static() + Static()`
- I already disabled markup parsing for two cases where filenames are
interpolated, but there was still:
"An unexpected error occurred while reading %1"
which was liable to misinterpret things as markup.
Note that anything in square brackets can be treated as markup and
become hidden, not just recognized tags like [red].
For example, in the Open dialog, typing a filename that doesn't exist,
and then hitting enter, it's supposed to say "File not found", but
if the event isn't prevented/stopped, it will also be handled by
the new dialog, and you won't even see it.
