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

[Eduardo Francos]

On 18 sept. 2014, at 11:13, Allan Odgaard <mailinglist at textmate.org> wrote:

> On 18 Sep 2014, at 10:46, Etienne Samson wrote:
> ...
> TextMate doesn’t know as much as you here. The input system is abstracted to support many different input modes. This is the protocol currently used to talk to TextMate: https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/Protocols/NSTextInput_Protocol/Reference/Reference.html
> 
> As you can see, there is no “here is a dead key that looks like a quote” but rather methods like -setMarkedText:selectedRange:.

After some searching I found that actually there is. It's related to the 'setMarkedText', 'insertText', 'hasMarkedText' and 'unmarkText' selectors.
Apparently the marked text is text that is pending input to be finished before the final modifications to the text are applied.
Look at this short discussion in a Cocobuilder forum (http://www.cocoabuilder.com/archive/cocoa/144153-nstextinput-protocol-unmarktext-is-late.html)

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 dived in the code (mainly OakTextView) and couldn't understand what was going on. It seems to me that the marked text is being used for handling multiple selections or something.
Anyway, hope this helps.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.macromates.com/textmate/attachments/20140919/ca1f3ca3/attachment.asc>