Please consider adding this change to fix problems with Dvorak-Qwerty+Cmd layouts (and possibly others) #14

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@NorwegianRockCat

Begin quoting from my change:

It seems that this layout will cause the input method methods to be
called, whereas "normal" layouts don't go this route. The problem is
that this sends the wrong text (namely a ',' in the case when the user
pressed 'w'). However, we also need to set the
"interpretKeyEventsSwallowedKey flag since in this particular case we
really mean that a selector didn't swallow this key.

Yes, it's complicated and this layout is used by a very small minority.
But this layout is handy enough to support, kind of like the Mac users
of old. :-)

End Quote.

If it helps for convincing, this pattern for handling text is also used in Qt for its text editing widgets (see http://qt.gitorious.org/qt/qt/commit/9377881d6d6f5c07aa134c8f1708d0afd0d06e86), I know this because I was the person that got to double-check the code before it was submitted.

Certainly open for other ways of doing patch if desired.

@NorwegianRockCat NorwegianRockCat Fix Ctrl+W on Dvorak-QwertyCmd layouts.
It seems that this layout will cause the input method methods to be
called, whereas "normal" layouts don't go this route. The problem is
that this sends the wrong text (namely a ',' in the case when the user
pressed 'w'). However, we also need to set the
"interpretKeyEventsSwallowedKey flag since in this particular case we
really mean that a selector didn't swallow this key.

Yes, it's complicated and this layout is used by a very small minority.
But this layout is handy enough to support, kind of like the Mac users
of old. :-)
3d07ed2
@b4winckler
Owner

This looks like an extremely dangerous change. You are blocking all calls to insertText unless imControl is set (which in normal circumstances it is not). Hence no text will be inserted unless this insertText was called from keyDown: and this is not a safe assumption. It may fix your immediate problem but will cause several others and hence I cannot merge this.

@NorwegianRockCat

That's true, but insertText should only be called from an input method. That is, it's part of the NSTextInput Protocol. So, this should not be called in other circumstances, other than when an input method is being called. So, it's not dangerous, unless you know other places where insertText is called. I'm not sure why interpretKeyEvents calls insertText for this particular layout. If I was at WWDC, I would ask, but I'm not.

And input is not blocked. If insertText returns, the rest of keyDown finishes and it passes through to Vim, which is what would have happened anyway. If the string, really is a string, than it was built up in the other NSTextInput protocol methods.

Please reconsider, or if you can know that this will cause a problem, can you offer a suggestion for another workaround. I'll consider a different workaround, but as it is, MacVim is broken for this layout and many other editors handle this correctly.

@b4winckler
Owner

My point still stands: insertText can be called from anywhere, not necessarily from keyDown:. Have you tried what happens when you enter text from the "Special Characters" dialog for example?

I cannot merge this.

@NorwegianRockCat

Ah, you are correct that doesn't work quite right. Thanks for the pointing me to a good test case that broke my assumptions.

I'll investigate and send back a better patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment