Implement move word keyboard shortcuts

[xi-editor]

Implement move word keyboard shortcuts

[ThinkChaos]

For example, "3.14" is considered one word by Unicode, but the "." is considered a word splitter in Sublime.
I think Sublime gets this right: when I edit code I want to be able to select just a field's name. For instance def in abc.def.
Maybe this should vary if we are editing code or just plain text, or let plugins take care of this.

[raphlinus]

Very much worth doing. The sticky point is defining word boundaries. Also note that double-clicking should select up to word boundaries, so it requires a similar primitive.

There are two tricky aspects, defining what a word boundary should be, then implementing that. I would say a good starting point for the former is UAX 29 word boundaries, but I'll also note that Sublime Text's implementation varies quite a bit from those. For example, "3.14" is considered one word by Unicode, but the "." is considered a word splitter in Sublime.

There's also the subtle issue that option-left-arrow tends to land after spaces after the next word boundary, but option right-arrow lands before.

UAX 29 is not trivial to implement. There's unicode_segmentation, but that implementation has two things making it not immediately usable. First, it expects the whole string, and doesn't have a way to handle partial inputs like leaves in a rope. Second, while it does have a double-ended iterator, it doesn't have a general mechanism to say, "here's an offset within a string (or, ideally, rope)", tell me (a) whether it is a boundary and (b) where the previous one is.

So a good place to start would be researching the ideal behavior. If that's UAX 29 or nearly so, then it makes sense to either improve unicode_segmentation to support xi's needs, or look at a from-scratch implementation in xi-unicode (logically it's pretty similar to line breaks, which we already do). If it's quite different from UAX 29 (and maybe in some ways simpler), then from-scratch makes more sense.

It would be possible to do something really simple as a placeholder in the meantime, like considering spaces to be word boundaries.

[Sineaggi]

Under the assumption that modifying unicode_segmentation would be the way to go, how would you expect the library to handle xi-editor's custom rope implementation? A callback mechanism, where the library can continuously request 'previous' or 'next' leaves? Or develop a common interface for the class that would allow backwards/forwards movement within the rope?

Since xi-editor is already pretty unicode compliant, UAX 29 seems like a pretty decent first look. Personally, all I look for in an editor is being able to delete large token quickly, and for that case a simple space-delimited word segmented would work.

[raphlinus]

I think the best way to build the word and grapheme iterators is to have a low level struct / function that can take partial-string input. You pass in the str and a cursor location, and it either tells you the prev/next break, or returns a status code asking for more context. It worked out very nicely in xi-unicode for line break iteration, but in some ways that's a simpler problem - you only iterate forward, and you always start at a known break location, not randomly in the middle of the string. For the more general cases, you will in general need more "before" context even when going for the next break.

Given an API like that, it would be easy to wire up directly to xi-rope (or any other rope-like string store), or create a callback interface as you say.