ta0kira / wrapping-editor Goto Github PK

For example, allow referring to the current cursor position in terms of absolute paragraph and absolute character within that paragraph. This would be somewhat separate from the cursor display position, since the latter has no effect on data integrity.

It's often useful to scroll to another part of the document to check on something without losing the cursor position. Right now this isn't possible with FixedWidthEditor and FixedWidthViewer.

I think the implementation would be something like this:

• Add a new function to FixedFontViewer for actions to change the view, e.g., move up or down by n lines.
• The getCursor return probably needs to be made Maybe (Int,Int) to disable its display.
• In the implementation of Document:
  • Add a Maybe (Preview c b) field, where data Preview is just a line zipper containing the whole doc.
  • If the preview exists, use that for visible lines, and don't show the cursor.
  • If edits happen or if the cursor is moved (to include width resizing), set the preview to Nothing.

Horizontal cursor movement assumes an "insert" cursor, i.e., there are n+1 cursor positions on a line of length n. This is primarily to allow you to insert/delete at the end of the line without having to move to the following line first.

This is a problem when the cursor cannot be rendered past the last horizontal character, however.

Possible solutions:

1. Add a "cursor mode" to FixedFontEditor to choose between n and n+1 cursor positions. If the mode is selectable, don't forget to update reparseParaTail, since it restores the cursor position using sequential MoveNext, and thus adds one operation per line change. Another edge-case is for lines that are empty. So, there needs to be max 1 n cursor positions.

2. Recommend that applications that cannot support n+1 cursor positions set the viewport size to one less than the available width. Or, since the wrapping policy is actually the one setting line length, maybe just implement a version that subtracts one from the requested width. This could even be a generic adapter that can be applied to any policy.

Specifically, this occurs when the Hyphenator splits the word at exactly the hyphen. This seems non-trivial to fix because BreakWords doesn't allow the WordSplitter to specify the line-break type.

It seems like the options are:

• Update WordSplitter to allow a non-hyphen split. For example, return Maybe [Segment] from splitWord, with something like data Segment = WordSplit Int | WordEnd Int.
• Remove DashPunctuation from LangHyphen.wordChars so that splits happen automatically. The disadvantage here is that it will cause hyphens to be at the front of the next line in certain situations.

They should use WEditor from the cloned repo instead, in case there is a breaking change to WEditor. Otherwise, such changes would need to be pushed to Hackage before committing corresponding changes to WEditorHyphen and WEditorBrick.