Introducing options.updateWhenComposing

[mihailik]

This option (defaulting to false) makes CodeMirror ignore composing events, switching off mobile keyboard suggestions and making mobile experience align closely with the desktop for highlighting and change handling.

The target use case of the option is rich code editing and IDEs. Those normally provide custom completions and rich contextual services, exceeding and often conflicting with mobile touch keyboard suggestions.

Hence an option to disable the platform composing smartness/substitutions.

The key downside is IME being disabled or severely handicapped when this option is set. Given that most programming languages tend to use with English and ASCII, lack of IME is seen as a reasonable tradeoff.

[mihailik]

See also discussion in #3655 [mobile] Colouring not picking changes until non-word characters

[mihailik]

I've created a gist with a CodeMirror using this option and HTML mode:

Gist hosted with githack

Gist itself

URL shortener to quickly type on mobile:
http://tinyurl.com/updateWhenComposing

[marijnh]

This seems to sort of work for the textarea inputStyle, but when using contenteditable it creates a mess of latin and Japanese characters when I try to use it with Japanese IME.

Also, in general, I'm rather hesistant to include such an accessibility-hostile feature in the core editor. Have you tried adding your own event handlers to somehow force composition to end as soon as it starts? That sounds like it would also be possible, and doesn't require changing the library.

[mihailik]

IME is an expected downside, insignificant in the target use case: mobile code editing.

I am not aware of any accessibility issues. Both reading and writing should work just the same.

[mihailik]

To put it into context, currently code editing on mobile with CodeMirror is a major pain. Because of autocorrection, lack of completion and #3653 (troubles with arrow keys).

Comparing to that, troubles with occasional ideographic in string literals/comments is very minor.

But you've mentioned composition refactoring you're planning. Would that bring back 'change' events during composition? Would you elaborate please?

Many thanks!

[marijnh]

The rewrite will, if it works out the way I planned it, have the editor fire change events during composition.

In my test with your option, there we no occasional problems with IME, it was just completely broken -- inserting both the composed character and the latin variants next to each other. The code is written with the expectation that compose events are handled, and just disabling those handlers doesn't seem like it will do the right thing.

[mihailik]

Sure, if a better solution is in the works let's close this one.

[marijnh]

Well, the thing is, that other solution isn't something that is going to happen soon, since I have much other things to do and this isn't very high-priority. So waiting for it is likely to end with frustration.

[mihailik]

Only a bit: I am keeping this option in my forked code, so it's fine in my app :-)

Or shall I try to implement that other solution?

I assume the crux of the plan is to tweak the line rendering. If composition is on (plus some extra checks), rendering will update existing elements in place, instead of recreating from scratch.

[marijnh]

The plan is to just disable line re-rendering for the line that is being composed (since the entered characters will already show up), and force a composition end if something else (say, a script) tries to modify that line. In addition, we have to read the actual characters that are in the composition from the DOM, since the events often contain unhelpful or even plain bogus data, and immediately update the document on each compositionupdate. I expect it's going to a bit hairy to implement, but if you want to take a stab at it, that'd be very helpful.

[mihailik]

Thanks, I shall stab indeed :-)