Cursor rework

[dfrg]

This is a draft because some functionality (mostly around word/line selection) is still missing. I also commented out the fix from #163 because the skip_mandatory_break flag is now gone and I haven't dug into the logic from that PR.

Submitting this now so that people can take a look and see if it fixes some of the known bugs, particularly around newline handling.

note: #166 should probably land first

[nicoburns]

I also commented out the fix from #163 because the skip_mandatory_break flag is now gone and I haven't dug into the logic from that PR.

Looks like you're now appending the newline cluster to the previous line rather than waiting to append it to the next line. We'll need to test, but I suspect that means that the bug fixed in #163 won't be present. The key thing not being which line the newline cluster ends up in, but that the cluster is "committed" eagerly rather than deferred to the next iteration of the loop (the fix in #163 was handling that deferred cluster commit handling the case that the next iteration of the loop was an inline box (and thus went down a different code path)).

If you wanted to keep the "newline is at the start of the following line" behaviour then think you could probably just reverse the append_cluster_to_line and try_commit_line statements (although IMO it's more intuitive if the newline cluster is part of the line it ends).

[nicoburns]

I've left some review comments on the layout code that I'm familiar with. I haven't reviewed the selection code which I don't fully understand yet.

[nicoburns]

Can you explain why you have switched from Boundary::Mandatory to Whitespace::Newline here? What (if anything) is the difference?

I'm assuming the reason you (can safely) check Boundary::Line before checking is_newline is because a newline will never be a Boundary::Line (it will always be a Boundary::Mandatory)? If this is not the case then I think you need to invert the order in which you check those conditions.

[dfrg]

The full explanation is at #132 (comment)

tldr; Unicode LBA specifies a break after the newline and a trailing newline doesn’t have a following cluster so we lose that information.

Re check order: good question. I’m going to assume that a newline sequence is not marked as a break opportunity because the code appears to work as is :)

[spirali]

I did some quick manual testing with 220f1bc and it seems that problem from #163 is gone. The logic behind #163 was to solve the problem that newline cluster is part of the next line and it broke placing inline boxes.

[dfrg]

I did some quick manual testing with 220f1bc and it seems that problem from #163 is gone. The logic behind #163 was to solve the problem that newline cluster is part of the next line and it broke placing inline boxes.

Thanks for confirming.

[dfrg]

If you wanted to keep the "newline is at the start of the following line" behaviour then think you could probably just reverse the append_cluster_to_line and try_commit_line statements (although IMO it's more intuitive if the newline cluster is part of the line it ends).

This was initially done to force a line to be created at the end of the layout when the last character was a newline. This didn’t really work anyway and I agree that it’s more intuitive (and correct!) to keep the newline attached to the line it ends.

[mwcampbell]

Cursor::to_access_position returns None when the cursor is at the end of the text (e.g. after pressing Ctrl+End in vello_editor). This is incorrect, as it means we can't report an accessible text selection when the cursor is at the end.

[dfrg]

Ah, I see. We won’t have a downstream cluster at the end of the text. I’ll push a fix for this in a bit.

[mwcampbell]

Just tried the latest push with a screen reader. If I go to the end of the default text in vello_editor with Ctrl+End, then the accessible selection is where it should be. But if I then press Enter to start a new blank line at the end, then the accessible selection is on the previous line, after the hard line break, rather than on the new, blank line.

[dfrg]

This is probably a question of affinity. I pushed an update that might address it.

[mwcampbell]

No change to the accessibility behavior when inserting a new blank line at the end.

[DJMcNab]

I can confirm that works. The behaviour seems a tiny bit janky, as it allows both the selections. {lorem} ipsum and {lorem }ipsum. Firefox only allows the former on my machine.

[nicoburns]

As it allows both the selections {lorem} ipsum and {lorem }ipsum. Firefox only allows the former on my machine.

FWIW, Chrome allows both on my machine.

[xStrom]

On my Windows 11 machine both Firefox and Chrome allow both selections.

[dfrg]

Word selection and movement is entirely inconsistent across platforms/editors so I chose a set of behaviors that seemed to make sense. Including space-like “words” in mouse selection was intentional because you cannot otherwise extend the selection into a space without using the keyboard, and as noted, there is precedent for this in Chrome.

[dfrg]

@mwcampbell I pushed a change to add a "phantom" text run to the last empty line. The logic is a bit janky but I believe (hope?) the mapping to AccessKit is correct.

[mwcampbell]

The phantom run for a blank line at the end seems to work correctly. I can find just one more accessibility problem: if the text is entirely empty, there's a phantom run, but Cursor::to_accesskit_position returns None because there's no cluster. In that case, we need to return the node ID of the one phantom run and a character index of 0.

[dfrg]

Thanks Matt. I added a special case for that.

Assuming this is okay for accessibility, I don't plan on making any further changes unless new issues are raised by others.

[mwcampbell]

The AccessKit integration now looks good to me.

[dfrg]

The AccessKit integration now looks good to me.

Great! I appreciate your patience and your help with testing.

[nicoburns]

We have a cursor when there's no text! (rendered with Blitz + Parley):

[nicoburns]

I've done some testing of the vello_editor example, and this seems to resolve all of the robustness issues around newlines I was seeing before. I've also updated Blitz to use this branch, which seems to work well.

[dfrg]

Thanks Nico. I’m going to go ahead and merge this. If there are further issues they can be addressed in a follow up.

Requested changes have been addressed.