Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formalise character positioning #17

Open
2 of 5 tasks
mjakeman opened this issue Aug 24, 2022 · 1 comment
Open
2 of 5 tasks

Formalise character positioning #17

mjakeman opened this issue Aug 24, 2022 · 1 comment
Milestone

Comments

@mjakeman
Copy link
Owner

mjakeman commented Aug 24, 2022

aka 'The wonderful wild world of word wrapping' :/

Introduction

The way we currently handle cursor positions is a mess. For each paragraph, it is comprised of several 'runs', with each run being a block of contiguously formatted text. Text is indexed on a per-paragraph basis.

Character movement is handled by the TextEditor class, while home/end movement is handled by the TextDisplay class. This is because at present a TextDocument is a semantic description of the document, paired with a TextLayout to create the actual formatted document. TextEditor operates directly on the semantic document (as it should, at least for now).

Traversal between paragraphs is not a problem as each paragraph can be considered a 'self-contained' block, so going from the end of one paragraph to the start of another paragraph is one movement backwards/forwards.

The problem arising when dealing with paragraphs that span multiple lines, and particularly when words themselves are split instead of wrapped. When we use home/end, where should the cursor go?

Google Docs:

Paragraph wraps, word is not split:

The space is used to correctly handle traversal between the end of the first line and the start of the second. No special case needed.

Screen.Recording.2022-08-24.at.5.54.53.PM.mov

Paragraph wraps, word is split:

Docs appears to use a 'before character' approach in that the caret position is determined by the following character. This is particularly nice because pressing end takes you to the final index position on the line, belonging to the final character on the line (i.e. the space or tab). For the final line in the paragraph however, there is no break and so we need to account for the extra index.

Screen.Recording.2022-08-24.at.6.07.59.PM.mov

Text Engine:

Paragraph wraps, word is not split:

Normal navigation works, but the current state of home/end dumps the cursor on the line after. This is probably fixable by choosing the index preceding the final character on the line.

Screen.Recording.2022-08-24.at.6.00.54.PM.mov

Paragraph wraps, word is split:

Again this works similarly to Google Docs, however we have the additional '-' character inserted by Pango when word wrapping. We could probably disable this? The issue here which makes it look much worse than it is stems from 'end' using the character after, rather than the character before. This makes it appear like two characters are being skipped. Switching to a character before system puts us on par with Google Docs and is probably the best path forward:

Screen.Recording.2022-08-24.at.6.03.44.PM.mov

Again we need to count for the additional index on the final line, as there is no 'break' character.

Conclusions

We should:

  • Follow the Google Docs model of character positioning within paragraphs
  • Make Home and End to use the first index and last index on a given line
  • Refactor movement into a new TextTraversal auxiliary object?
    • Alternatively make TextEditor layout-aware (not too happy with the idea)
  • Unit test everything
@mjakeman mjakeman added this to the 0.2 milestone Aug 24, 2022
@mjakeman
Copy link
Owner Author

mjakeman commented Sep 4, 2022

Something else to consider is that we should differentiate between child indices (e.g. text run is "the second child of" paragraph) and character indices (Cursor is at index 7 in the string: "Hello W|orld").

This will be important when dealing with non-textual elements like Images, and even more so when implementing native equations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant