fix(code-blocks): remove buggy "exit code block" functionality

[alexwarren]

Closes #191

Describe your changes

This PR removes the custom logic that was attached to "arrow right" and "arrow down" keypresses.

These were added in #64 in an attempt to add some behaviour where people could exit code blocks by pressing arrow keys. Unfortunately that introduces bugs like this one, where you can't use the arrow keys to navigate inside a code block any more - instead you get teleported out of it. Annoying!

After removing this code, things seem to work as I would expect them to anyway.

Screen.Recording.2025-02-26.at.14.45.06.mov

PR Checklist

• All new/changed functionality includes unit and (optionally) e2e tests as appropriate
• All new/changed functions have /** ... */ docs
• I've added the bug/enhancement and other labels as appropriate

Environment(s) tested

Tested on Chrome and Safari.

Additional context

n/a

[dancormier]

Thanks for the change @alexwarren

ArrorDown

I think I'm good with getting rid of this key binding. Seems like the only (intended) benefit is that it creates a new line when the user presses down to exit the code block. Without that key binding, users can still exit code blocks with down arrow.

The only catch I could find is that if the user is either at the end of a document or adjacent to a similar element that captures input the same way (such as another code block or a table), the user may have trouble inserting a new line between the two blocks. That said, the user can use Shift + Return create a new line in this circumstance, which is pretty standard behavior.

The exitDown on ArrowDown seems to be the sole issue identified in #191. In order for this to work as intended, I think we'd need a new function executed on ArrowDown that triggers exitDown only under specific circumstances when the cursor is both on the last line of a code block and in the final block of the document.

ArrowRight

I think the sin with exitInclusiveMarkCommand here is just that it assumes $cursor has a value. If the user presses their right arrow while text is selected, we get an error. I think this can be resolved just by performing a check or two to make sure $cursor is defined before we try to use it (adding ? like $cursor?.nodeAfter I think will be enough) and adding a test to make sure. Other than that, it seems to work as designed so I'd suggest keeping it in place.

If you do decide to remove the key binding, I recommend also removing the function and related tests from our code entirely since it's not used elsewhere.

---

Let me know if anything I said doesn't make sense and/or if you wanna sync on my impressions here. Happy to chat about it.

[alexwarren]

@dancormier Thanks, I've reinstated that.

I've added a test for the case when $cursor is null - I've sort of hacked my way around to get there though, and the test generates a console warning "TextSelection endpoint not pointing into a node with inline content (doc)". Which I guess is intentional, I'm deliberately creating an invalid state here (?) to ensure our code can handle it. But I'm not sure if there's a better way of testing this.

[dancormier]

Thanks for making those changes @alexwarren. I've suggested one minor change to get rid of that console.warn statement that comes up when you run the test. Otherwise, it looks good and I'd be happy to see it merged once the one thing is resolved

[alexwarren]

Thanks @dancormier, I've made that change.