MacVim treats pauses in dictation as improperly-formatted new sentences without spacing. #87
Description
As described in [this answer on Apple Stack Exchange, MacVim 7.4-77 (and other builds) do not seem to properly handle pauses in OS X dictation. This isn't a Vim issue, as Vim 7.4.889 on the same machine Does The Right Thing™.
For example, with MacVim:
I pause hereAnd dictation doesn't add a space.
but Vim itself works fine:
I pause here and dictation does add a space.
It's unclear why MacVim and Vim behave so differently in this regard. Expected behavior would be for MacVim to handle pauses in dictation without creating an improperly-formatted new sentence.
Activity
jpetrie commentedon Oct 10, 2015
I'm pretty sure it's not vim correctly handling dictation, but Terminal.app. I'll see if I can reproduce this and poke around tonight.
jpetrie commentedon Oct 10, 2015
I can't reproduce it except in normal mode, which sort of makes sense. You can't enter text in normal mode, I wouldn't expect you to be able to dictate text in normal mode either. I'd argue the bug (or at least, a bug) is that it works at all in normal mode.
I'm not sure what we can do to fix it in either direction though. Dictation is not implemented by MacVim, it's implemented entirely by the OS and we get no real hooks into it.
As far as I can tell, what happens is that the OS gets the dictated text to any
NSTextInput-conformingNSViewthough the IME events, because those support this notion of marked or (what appears to me) "pending" text which can substantially transform as it appended to. This is useful for many languages with complex character sets like Japanese, because a user can be typing out a word in a simpler set (like hiragana) and the OS will convert it into a single kanji, or similar.Dictation's output is refined as you speak, so it makes sense to leverage the same system. Unfortunately I don't know of way for us to reasonably tell the IME events for regular input attempts and dictation apart, and I assume we'd still want regular keyboard inputs in IME modes to still trigger normal mode commands?
Worse, as implemented now, dictation causes the IME events to fire when the text view isn't really expecting them, so it munges around in some state that probably is unexpected and has a tendency (from my brief tests) to just completely overwrite the same line over and over or cause rendering artifacts and so on.
I never use input methods other than boring old English so I'm probably not the best person to determine the appropriate behavior here.
(EDIT: I was finally able to reproduce this in insert mode; I'm not super clear why it finally happened, it may have been due to how I was pausing the app in the debugger to try and examine what's going on?)
todd-a-jacobs commentedon Oct 10, 2015
The problem I was describing was specifically in insert mode. Other than testing out "press escape key" to enter normal mode, all the misbehaviors I described were while in insert mode with no attempts to change modes.
OS X accessibility is probably what's allowing text to be entered in normal mode, although I'd argue that this is probably a "feature" rather than a bug. However, the problematic behavior is the inability to have sentences with pauses; is there something MacVim is doing (or not doing) when input pauses that might trigger the equivalent of ESCa? I'm not saying that's exactly what it's doing, but that's the apparent behavior that one sees.
jpetrie commentedon Oct 10, 2015
MacVim is just handling the "insert this text" and "abandon this IME conversion session" messages the OS sends it. It just doesn't seem to expect to get those messages for anything but actual IME text input, and must have some assumptions built into its handling somewhere that don't hold for when the events are sent as a result of dictation. :\
todd-a-jacobs commentedon Oct 11, 2015
I don't actually grok what happens when the "IME conversation is abandoned." Is it possible for MacVim to keep listening as long as Dictation is enabled? It seems like not restarting the session might fix the behavior. —Or am I misunderstanding what's happening under the hood?
jpetrie commentedon Oct 11, 2015
I don't quite understand it either, it's not an area I'm very familiar with.
But no, MacVim isn't the one doing the "listening," so we can't make it "keep listening." All we get are calls from the OS saying "do this now." We should be handling those events better (which probably means "more correctly")... I'm just not sure how yet.