Ad
  • Custom User Avatar
  • Custom User Avatar

    It's been resolved. I've updated the type hint to str | None to correctly reflect that None is a valid input.
    Thanks for the feedback!

  • Custom User Avatar

    It's quite similar, but works in a different way.
    Anyway, thanks for pointing it out!

  • Custom User Avatar

    This kata needs feedback CrossMath

  • Custom User Avatar

    New traduction for revision Traduction

  • Custom User Avatar

    Issue resolved, thanks for the feedback!

  • Custom User Avatar

    Sorry, I forgot to change Python and Kotlin tests. Now it should be ok.

  • Custom User Avatar

    You're right. Null testing doesn't add meaningful value and tends to create more issues than benefits, so it has been removed.

    Regarding the whitespace behavior. The case "a " won’t occur in practice. Randomized tests won’t generate such inputs, and the only test case that includes spaces is "1 1 1".

    Also, from a human perspective, when you open a file and see a letter, your brain expects to find some kind of meaningful content. But if there are only spaces or invisible characters, it feels like there's nothing there. That intuition is part of the logic here.

  • Custom User Avatar

    First of all, thanks!
    About the round subject, it's true that the way that it was written could lead to a misunderstanding of the task so I have changed it.

    Also, I will keep the sugestion in mind for what will most likely become the second part of this kata, harder and definitely more interesting!

  • Custom User Avatar

    After further consideration, I realize it adds unnecessary complexity at this stage and have removed it, so I’ll leave that part for a second part of this concept.

  • Custom User Avatar

    You're right. Handling newlines in detail does add complexity, especially when it comes to defining keypress behavior and covering all edge cases in tests.

    For now, I’ll keep this kata as a simpler introduction to the concept, where newlines are just normalized for consistency (\r and \r\n become \n). In the very possible second part, I’d like to explore more advanced behavior, like the previously mentioned upper case using both SHIFT keys, defining how line breaks count as keypresses, how they interact with segment limits, and adding proper random tests for all cases.

    Thanks again for the thoughtful feedback!

  • Custom User Avatar

    You're right, it was too vague.
    I updated the tip to clearly say that \r\n or \r should be replaced with \n.

  • Custom User Avatar

    First of all, thanks for the great suggestions to improve this kata!

    • Proper markup is now used.
    • The tip has been expanded. I had the idea of an octopus working in an office, handling files received by email. I once had a real issue while reading a .txt file that wasn’t working properly. It turned out Windows uses a different line ending format and I wanted to highlight that in the kata. But in the end, I forgot to include it in the description.
    • I really liked the idea of the octopus opening an email but finding no file or an empty one, so it doesn't type anything, yet it still showed up to work.
    • I’ll definitely keep your suggestion in mind and will work on a second part with more complex logic and deeper mechanics.
    • I’ll also add assertion messages to help show failed test cases more clearly.
  • Custom User Avatar
    • Recipe images have been added.
    • Random tests were implemented.
    • Example test and submision test cases have been swapped.
    • The name was updated to an English name.