[TxMt] Re: Bug in enclose selection with multi-key characters using US-International keyboard layout

[Allan Odgaard]

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.