insertion point flicker on paragraph movement

[cmyr]

The paragraph movement commands (⌥↑ & ⌥↓) cause the insertion point to flicker to the start or end of the line before being drawn at the end or the start of the line, respectively. In other words: wherever they're supposed to be drawn, they're first drawn for a frame in the wrong place.

Stepping through in the debugger, it looks like this action sends two RPCs; in the case of ⌥↓, it's move_forward followed by move_to_end_of_paragraph. This doesn't immediately strike me as expected behaviour? Anyway I'm not sure exactly what's going on.

[raphlinus]

This is an odd OSX thing; http://osxnotes.net/keybindings.html describes two actions in a row for these keybindings ("~\Uf700" and "~\Uf701"). I think it's done this way so repeatedly pressing the key makes progress through the document.

How to deal with it? One possibility is to place a very short timeout on updates, aggregating them if they fall within the timer. I wouldn't do it for just this issue, but it's also very much an issue for color flickering when the plugin is doing syntax highlighting. I think if that can get its answer back in a ms or so, it's worth taking the small latency hit to avoid flickering.

That can be done either in the front-end or the core, but I lean toward the latter for two reasons. First, the need is common to all front-ends (as long as we're talking about syntax color and not just this specific issue 😃). Second, the core probably has more context to apply heuristics to minimize the tradeoff.

If it were just this issue, it's probably possible to override the keybinding to send a single command with the combined effect. But that might have negative consequences for users customizing their keybindings, and I'm inclined to try to solve the more general problem.

Good catch!

[cmyr]

Interesting.

I've been thinking a lot about keybindings in the last day or two, and I've come to assume that at some point we would stop relying on the interpreted NSResponder events and start sending raw events to the core. (At least, this is the only good way I can imagine implementing modal editing, and I think it also has some merit for certain a certain category of particularly ambitious plugin; again this is far future; but basically I've been imagining a modular system that sits between the client and the main dispatcher, receiving raw key events and outputting edit/other commands, maybe implemented as an FSM; this module could either be part of xi-core or a plugin communicating via json-rpc, which would let people experiment with novel modal (or not) editing paradigms).

Obviously we would want to do this in a way that didn't compromise IME support. There will probably have to be platform-specific accommodations of some kind? You'll have a much better sense of this then most of us.

My first thought about this discreet problem is that we can probably intercept the raw key event in keyDown(with:) and manually send the appropriate movement event; I'll take a look and see if it's a quick fix.

[jansol]

Status bump?

[cmyr]

Although I don't believe we added a concrete fix, it does look like at least the flickering has been resolved, probably because of the delayed rendering stuff in xi-editor/xi-editor#626. Since this was really a UI issue, I think that fix is acceptable.