On 19 Sep 2014, at 17:28, Eduardo Francos wrote:
[…] It seems from the program's behavior that TM's keyboard<->action binding system activates the action as soon as it receives the initial dead key character and before the sequence of characters is finished (hasMarkedText would/should return TRUE). If it could wait until all the insertText calls are issued followed by the unmarkText call then it would have the real character intended by the user.
I don’t think this is the problem, rather, in the case of typing é via a dead key, the user first types ´ and the system asks TextMate to insert ´ and have it *selected*, this is where TextMate will overwrite your current selection (and make a new), but since it’s part of a multi-input sequence, it won’t really do more. Next the user press E and the system then asks TextMate to insert é, this time not as selected, but as we already have ´ as selected text, it’ll replace what’s already typed (and the original selection you want to wrap was lost in first step).
I dived in the code (mainly OakTextView) and couldn't understand what was going on […]
I can’t claim to fully understand Apple’s NSTextInput protocol and the current code is the result of lots of trial-and-error with various official and third party input modes, so I’m not keen on touching it to try and address your issue, not to say it’s impossible.
The NSTextInput protocol has since been superseded, and at some time I will update the code to use the new protocol, I’ll keep your issue in mind when updating it.