Typing foreign characters in Textpad is a snap – the feature is built-in. If you want an accented e – é – you simply type ctrl+’ e.
I’ve tried some of the key bindings suggested in this forum – like:
{ "keys": ["alt + ' + e"], "command": "insert", "args": {"characters": "é"}}
but none of them work. When I type alt+’ e, ST3 outputs a plain e.
Any suggestions? Am I missing something obvious? I’ve searched the documentation.
Thanks.
Try removing the spaces from the keys value.
So use ["alt+'+e"] instead of ["alt + ' + e"].
Also, after re-reading your post, it seems like you may be expecting to press the keys as:
alt + ’ then after letting go of the keys pressing e rather than alt +’ + e all at the same time.
If that’s the case then use ["alt+'", "e"] instead.
Thanks – that works (both methods). The Textpad default convention is a bit more convenient, I think. Pressing three keys at once requires some athletic effort. I’m surprised that handling foreign characters in Sublime Text requires special key bindings.
Glad to hear it works now.
Yes, using all 3 buttons at the same time is quite the challenge.
In Sublime’s keybindings you just break the keys up into separate elements of the array to express a series of key presses.
["alt+'+e"] expresses ctrl + ’ + e all at the same time.
["alt+'", "e"] expresses ctrl + ’ then letting go and pressing e separately.
You may want to use the second option if I understand what you are saying about the Textpad convention correctly.
All three supported OSes have built-in ways of typing non-ASCII characters that will work in pretty much every application.
I am messing around with Atom, Emacs, Notepad++, Sublime Text 3 and Vim as possible replacements for Textpad. No editor is perfect, but Sublime Text 3 overall may have an edge. Something that bothers me about ST3 – apparently its macro recording function can’t handle find/replace, a feature I use all the time in Textpad. (Atom doesn’t offer macros at all, the last time I checked.)
I have a vague impression that ST3 development may have slowed down during the last year, based on some initial looks at the ST3 world – am I mistaken?
I’m not sure if you are asking me directly because your reply is directed at me, or if you just clicked on any reply button and are just asking in general, but I’ll answer from my point of view anyway.
I have no experience with the macro recording function so I can’t help you there.
As for ST3 development, as far as I know it is still in development but it seems to go through patches of activity.
For example, I’m using the latest development build of ST3 because I have a paid licence for ST2, and sometimes I will see multiple automatic update prompts within days of each other, but other times I won’t see any updates for months on end.
This isn’t really much of an issue though since plugins tend to fill in most ‘missing’ functionality and if I needed any more I would probably be better off in a full blown IDE anyway.
I have also tried out Atom, Emacs, Vim and Visual Studio Code; I even wrote a couple of extensions for VS Code to bring back some of the functionality from Sublime that I was used to.
In the end I always come back to Sublime.
I find all the other editors I just mentioned to perform much slower than Sublime in general, especially Atom and VS Code since those two are both written in JavaScript on the Electron project from GitHub.
In addition to that I suppose I’m biased because I’ve been using Sublime for about 6 or 7 years now so I’ve got it set up to do anything I need it to do now anyway (with exception to a different text colour in a block cursor…).
Anyway, tl;dr: ST3 development seems to still be active, but you will usually see updates in small bursts every now and then as opposed to a steady stream.
I feel like I’ve gone off topic enough for this thread now so I’ll leave it there 
I appreciate your observations – I guess I was musing out loud in that comment while digging into ST3 in a serious way for the first time.
ST3’s performance is impressive and it boasts a rich collection of packages. I suspect I may stick with it.
I am probably missing something obvious here:
[
// foreign characters: work
{ "keys": ["ctrl+'", "a"], "command": "insert", "args": {"characters": "á"}},
{ "keys": ["ctrl+'", "e"], "command": "insert", "args": {"characters": "é"}},
// foreign characters: don't work
{ "keys": ["ctrl+^", "a"], "command": "insert", "args": {"characters": "â"}},
{ "keys": ["ctrl+:", "o"], "command": "insert", "args": {"characters": "ö"}},
]
The second set don’t work for you because ^ and : are not characters that you can type just by hitting their key; shift is also required.
If you define it as follows, it will work (although it requires more finger magic, so it’s probably still not desirable).
{ "keys": ["ctrl+shift+;", "o"], "command": "insert", "args": {"characters": "ö"}}
For more explanation (and as a weird aside to a potential weirdness in Sublime’s key handling itself), using the following key binding:
{ "keys": ["ctrl+:"], "command": "toggle_setting", "args": {"setting": "word_wrap"}}
Pressing Ctrl+: does not do what you want; it opens the Go To Anything panel with the # operator already inserted, which makes total sense because (at least under Linux) the key binding Ctrl+; is bound to do that very thing, and that’s actually what key you’re pressing.
However, if you press Ctrl+Shift+;, the shortcut works, because you are actually pressing Ctrl while generating a ; character.
On the other hand, this binding does NOT work:
{ "keys": ["ctrl+:", "o"], "command": "toggle_setting", "args": {"setting": "word_wrap"}}
Now when you do the sequence, instead of word wrap toggling, a regular o appears in the document, even if you press Ctrl+Shift+;o.
In order for it to work, it needs to be explicitly bound to use the shift key:
{ "keys": ["ctrl+shift+;", "o"], "command": "toggle_setting", "args": {"setting": "word_wrap"}}
Now it works as expected.
I imagine this is because of the internal difference in recognizing that a key stroke is bound directly to some command versus recognizing that the sequence might be a part of a key chord sequence, with the rules for matching being a little looser or stronger in one case over the other.