Bug in enclose selection with multi-key characters using US-International keyboard layout
Hi,
When using the US-International keyboard layout, if you want to enclose selected text with quotes, single quotes or back-quotes by typing them, the originally selected text is deleted.
Those keys are used for diacritical accents by the US-International layout and require two keystrokes, the quote character itself followed by either a space to indicate you actually want the quote character itself, or a different character if you want to apply the diacritical accent on it. For instance a single quote ' followed by an a gives á. If the quote character is followed by a character that doesn't accept diacritical accents then the layout issues the two characters as they were typed, so a " followed by a w gives "w
I do most of my programming using the standard US layout but sometimes I need to switch to spanish or french. A really insignificant bug, I know :p and I can certainly live with it, so this is mostly for information. It's good to know someone knows it's there :-)
Gualo
On 17 Sep 2014, at 13:11, Eduardo Francos wrote:
When using the US-International keyboard layout, if you want to enclose selected text with quotes, single quotes or back-quotes by typing them, the originally selected text is deleted.
I have both the ISO and ANSI US/international keyboard, and I can type all of the following quotes without using dead keys: ‘…’, “…”, "…", '…', and `…`.
A really insignificant bug, I know :p and I can certainly live with it, so this is mostly for information. It's good to know someone knows it's there :-)
I fear it would be rather complex to do a workaround for this because we would need to delay overtyping a selection when we detect the user starts a complex input sequence, and for most users I imagine this would be undesired (not seeing the selection immediately overtyped).
I think it’d be fair to say that characters used for auto-pairing have the same limitations as characters available for key equivalents, where your issue also exist, i.e. you can’t bind a menu item to characters that you cannot type with a single key sans modifiers.
Le 18 sept. 2014 à 09:48, Allan Odgaard mailinglist@textmate.org a écrit :
On 17 Sep 2014, at 13:11, Eduardo Francos wrote:
When using the US-International keyboard layout, if you want to enclose selected text with quotes, single quotes or back-quotes by typing them, the originally selected text is deleted.
I have both the ISO and ANSI US/international keyboard, and I can type all of the following quotes without using dead keys: ‘…’, “…”, "…", '…', and `…`.
I can confirm that this also happens with the standard French layout with the ` backtick, the selected text just disappear. As the OP says, not a really harmful, significant bug, I just want to confirm that there's an issue.
A really insignificant bug, I know :p and I can certainly live with it, so this is mostly for information. It's good to know someone knows it's there :-)
I fear it would be rather complex to do a workaround for this because we would need to delay overtyping a selection when we detect the user starts a complex input sequence, and for most users I imagine this would be undesired (not seeing the selection immediately overtyped).
A quick fix (IMHO, I'm no expert on the text system) would be to make dead keys be handled as normal keys as soon as you have something selected — the rationale being that if you're actually trying to overtype a missed accent, you wouldn't rewrite a whole bunch of stuff. But there be dragons ;-).
Regards, Etienne Samson -- samson.etienne@gmail.com
On 18 Sep 2014, at 10:46, Etienne Samson wrote:
I have both the ISO and ANSI US/international keyboard, and I can type all of the following quotes without using dead keys: ‘…’, “…”, "…", '…', and `…`.
I can confirm that this also happens with the standard French layout with the ` backtick, the selected text just disappear. As the OP says, not a really harmful, significant bug, I just want to confirm that there's an issue.
Well, I can certainly reproduce it. What I didn’t understand is how the OP couldn’t type the above quotes on a US keyboard without using dead keys.
A quick fix (IMHO, I'm no expert on the text system) would be to make dead keys be handled as normal keys as soon as you have something selected […]
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/applic...
As you can see, there is no “here is a dead key that looks like a quote” but rather methods like -setMarkedText:selectedRange:.
On Thu, Sep 18, 2014 at 6:13 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 18 Sep 2014, at 10:46, Etienne Samson wrote:
I have both the ISO and ANSI US/international keyboard, and I can type all of the following quotes without using dead keys: ‘…’, “…”, "…", '…', and `…`.
I can confirm that this also happens with the standard French layout with the ` backtick, the selected text just disappear. As the OP says, not a really harmful, significant bug, I just want to confirm that there's an issue.
Well, I can certainly reproduce it. What I didn’t understand is how the OP couldn’t type the above quotes on a US keyboard without using dead keys.
I use the US-International keyboard layout too. To type ', I usually press ' then space, but I just accidentally discovered I can press ctrl ' for that. If I select text then try quoting it via ' then space, I trigger the reported bug, but not when using ctrl '. So, OP can consider using ctrl ' for quoting as a workaround. Also helpful: Toggle Single / Double String Quotes from the Source bundle, and Toggle Quote Style from the Ruby bundle (both accessible via ctrl cmd T). To type ", I press shift ' then space. I don't know how to type this character any other way to act as a workaround for quoting selected text. Also, I don't know how to type ‘, ’, “ or ”, it would be nice to learn how to do that.
-- :: dip --
On 18 sept. 2014, at 11:13, Allan Odgaard mailinglist@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/applic...
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-unmark...)
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.
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.
On 19 Sep 2014, at 17:28, Eduardo Francos wrote:
After some searching […]
It occurred to me that you might get your desired behavior by binding a custom action to the key for the case where there is a selection.
E.g. make a snippet with: ${0:´$TM_SELECTED_TEXT´}
Set the key equivalent to (assuming US keyboard): ⌥E
Set the scope selector to: dyn.selection
After this, pressing ⌥E with a selection wraps the selection in acute accents (and keeps it selected).
If there is no selection, it should insert ´ (as “marked”, allowing you to e.g. type E to make it é).
On 18 sept. 2014, at 09:48, Allan Odgaard mailinglist@textmate.org wrote:
On 17 Sep 2014, at 13:11, Eduardo Francos wrote:
When using the US-International keyboard layout, if you want to enclose selected text with quotes, single quotes or back-quotes by typing them, the originally selected text is deleted.
I have both the ISO and ANSI US/international keyboard, and I can type all of the following quotes without using dead keys: ‘…’, “…”, "…", '…', and `…`.
My bad. I forgot I had installed the US International PC layout years ago using one that implements the Windows US International layout logic for diacritical characters. Apple's own US Extended layout does not have this problem. I may even switch to it, thanks for the tip. But that still leaves other layouts with diacritical accents.
A really insignificant bug, I know :p and I can certainly live with it, so this is mostly for information. It's good to know someone knows it's there :-)
I fear it would be rather complex to do a workaround for this because we would need to delay overtyping a selection when we detect the user starts a complex input sequence, and for most users I imagine this would be undesired (not seeing the selection immediately overtyped).
I think it’d be fair to say that characters used for auto-pairing have the same limitations as characters available for key equivalents, where your issue also exist, i.e. you can’t bind a menu item to characters that you cannot type with a single key sans modifiers
Seems reasonable. As I said the issue is insignificant and I, as probably others experiencing this problem, have long since learned ways to overcome it.
Regards, Gualo
-
Allan Odgaard -
dipnlik -
Eduardo Francos -
Etienne Samson