Prevent Markdown reporter crash when max_length is None

[PeterDaveHello]

Guard the None max_length case so markdown reporter no longer raises TypeError on enablement. Add reporter tests for unlimited and trimmed paths to prevent regression.

GitHub Copilot summary:

This pull request introduces a minor fix to the MarkdownReporter.submit method and adds new unit tests to ensure correct handling of the max_length parameter. The main focus is to prevent errors when max_length is None and to verify that report trimming works as expected.

Testing improvements:

• Added a new test file lib/urlwatch/tests/test_reporters.py with unit tests for MarkdownReporter.submit, including scenarios where max_length is None and where output trimming occurs.

Bug fix:

• Updated MarkdownReporter.submit in lib/urlwatch/reporters.py to only subtract the trimmed message length from max_length if max_length is not None, preventing possible errors when max_length is unspecified.

[thp]

Wouldn't max_length in the function become negative?

[PeterDaveHello]

It only goes negative if a very small max_length is passed. This is because submit() first does max_length -= len(trimmed_msg) and the trimmed_msg string is about 58 chars, so max_length=10 becomes -48. Even then it just trims and does not crash. If you want to avoid that impression, I can change the test to use a value >= 60.

[thp]

In which situation would max_length actually become None?

[PeterDaveHello]

Agreed that a plain CLI run won't hit this. The crash only happens when the Markdown reporter output is actually consumed (Python/hook/extension usage): with default max_length=None, submit() subtracts from None. This is a minimal guard and does not change behavior when a length is provided.

[thp]

The more I think about it, the more I think that max_length -= len(trimmed_msg) should be done later (only when trimmed is truthy). If it isn't trimmed, we still want to have the full max_length, and if it is trimmed, something like [...] or [trimmed] might be better to allow for more "payload" and less "boilerplate". In particular, if max_length < len(trimmed_msg), then technically we wouldn't be able to show anything, not even the summary or the details. And if the "trimmed message" is quite small (e.g. "[...]" - 5 characters).

Then again, it's probably the _render() method that should do all deciding and value adding (possibly with an additional return value before the footer), so that it knows what the "real" max length is, and either fit the message in there, or trim it.

In other words:

The message "Hello world" (11 characters) and trimmed_msg = "[...]" (5 characters)

with max_length == 11 should still be:

"Hello world"

but with max_length == 10, should be:

"Hello[...]"

Right now, with max_length == 11, it would be:

"Hello [...]"

[thp]

If trimmed_marker is the empty string (the only way if trimmed_marker should evaluate to falsy), then len(trimmed_marker) == 0, so the result is the same.

Suggested change

	reserved_length = max_length - len(trimmed_marker) if trimmed_marker else max_length
	reserved_length = max_length - len(trimmed_marker)

[thp]

It's unfortunate that we have to call MarkdownReporter._render() twice here. Can't MarkdownReporter._render() contain all that trimming logic?

[thp]

See comments. Ideally call MarkdownReporter._render() only once and let it figure out trimming (since MarkdownReporter._render() already returns the trimmed status, might as well return trimmed_msg instead (being the empty string if not trimmed or not enough space).