Related
On my mac, I need to be able to access special characters such as accents for editing purposes and for now I access this by holding a key down and then get the suggestions shortcut.
However, I would like to use the Vim mode in Sublime as well so moving around with h, j, k, l is quite tedious if I can't hold the key down to move faster.
Is there any way to only repeat a key when pressing it down in edit mode, or to have this behaviour only for h, j, k, l?
Thanks
Probably unsurprisingly, the press-and-hold-for-special-characters behavior is a macOS feature. It doesn't seem possible to change the behavior on the fly. You can adjust it per app like this:
defaults write com.sublimetext.4 ApplePressAndHoldEnabled -bool false
So the question becomes: how can you enter special characters in insert mode? In vanilla vim, you could use inoremap to replace, say, Option+l with "ł". However, NeoVintageous (which I hope you're using, not the deprecated Vintage mode) does not support remaps in insert mode. It claims to support digraphs, which would be another way of achieving this. However, the keyboard command to insert a digraph is Ctrl+k, which conflicts with one of the default Sublime Text key bindings on macOS. (The one to kill from the cursor to EOL, which is copied from Emacs and available in standard macOS text fields.) It's presumably possible to work around this, but I felt like Ctrl+k+l+/ was kind of wordy anyway.
Fortunately, there IS a fast, simple solution: a Sublime key remap. Open your user key bindings (Sublime Text > Preferences > Key Bindings) and add this one:
{ "keys": ["option+l"], "command": "insert", "args": {"characters": "ł"} }
Now Option+l will add the l-slash character to your document. If you need the special character this is replacing (the not sign "¬"), you can of course choose another binding.
I presume this is the one you want, since it's the only special character available for me when I press-and-hold any of the hjkl keys. But this approach will work equally well for any other characters you might want to insert.
By default, pressing Esc in TextMate cycles through possible completions (in addition to closing dialog boxes), which can put unwanted characters in your document, especially if you are used to Esc being a safe key to hit in most text editors. (In fact, in a lot of IDEs, pressing Esc a lot is necessary to close auto-completion popups so the up and down arrow keys work.)
How do I disable this behavior, so in normal text editing, the Esc key does nothing, but closing dialogs still works as expected?
What works
Based on a comment from #matt I found that I can do what I need by overriding the default key binding, as mentioned here, https://manual.macromates.com/en/key_bindings.html :
In addition TextMate has a /path/to/TextMate.app/Contents/Resources/KeyBindings.dict file with some extra key bindings which are specific to TextMate (and thus not appropriate to put in the per user global key bindings file). You can copy this file to ~/Library/Application Support/TextMate and edit it, this will then take precedence over the bundled file.
I edited the file and took out the line with nextCompletion, assigned to shift+Esc ($\033) and assigned both Esc and shift+Esc to call noop
"\033" = "noop:";
"$\033" = "noop:";
I learned about the existence of the noop selector here:
https://github.com/textmate/textmate/search?utf8=%E2%9C%93&q=noop
After quitting and relaunching TextMate Esc now does nothing except close dialogs.
(Apparently to change this one setting, you need to know Objective-C to recognize selector strings, (and assembly which has 'nop') so you can guess that there should be a noop selector. And you need to know octal, so you recognize the Escape key as 033 = 27.)
Things I tried that failed
EDIT: for reference for people wondering how it can take 90 minutes to change one little setting.
I found this paragraph in the manual, at the end of section 4.2:
When you provide your own completion command (or list) you may want to
disable the default matches. This can be done by setting
disableDefaultCompletion to 1.
I tried setting disableDefaultCompletion to 1 in the Preferences > Variables pane and quitting and reopening the app. I found that Bundle menu > Select Bundle Item and clicking Settings shows a list of all the settings, including my disableDefaultCompletion = 1 at the bottom. Apparently this doesn't do anything? (Other settings overridden by different bundles show as crossed out, which my settings is not.)
I also searched the http://github.com/textmate/textmate repo for the string disableDefaultCompletion and it shows in the search results, so this is feature should exist there somewhere.
I tried quitting the app and then on the commandline:
defaults write com.macromates.TextMate disableDefaultCompletion true
Relaunching and trying again (hitting Esc to the right of a close } in JavaScript mode) and it is still not disabling completion.
I'm trying to map ⌘+Delete (backspace) to delete to the beginning of the line (like it works in browsers and text editors) in iTerm2 and I'm unable to find a working escape code for it. I tried 1K (^[1K) based on what I read in Wikipedia. It just prints a "K".
Edit: I found Ctrl+U. Now to find out how to map it. Maybe Hex code 21 (U being 21st letter), so 0x15?
I got it. I have no idea why Hex Code mappings in iTerm2 produce the associated Ctrl+key mappings, but they do. No idea what 0x00 means, either, as it's not assigned to A as might be expected. (though I do believe Unix has its own conventions relating to treating null bytes -- we have e.g. xargs accepting a null byte delimiting format from find for example -- It would be neat if we can bind this to a hotkey with iTerm2)
I was able to find that Ctrl+U does nearly the exact task I want (it deletes the entire line rather than deleting only what is before cursor, but whatever... Ctrl+Y as a bonus can bring it all back). Then I curiously saw that I had hex codes 0x1 and 0x5 mapped to ^A and ^E respectively, for my Cmd+Left and Cmd+Right... so 0x15 is for ^U!
For Mac OS, most editor share the common shortcut ⌘ + Delete: delete to start of the line, in iTerm2 we can switch to this key configuration
Mapping hex code 0x15 to ⌘ + ←Delete in most shells deletes the entire line (content to the left and right of the cursor). While sometimes not as compatible, I find that mapping:
⌘+←Delete to Send Hex Codes:
0x18 0x7f
performs the desired functionality. If you're running ZSH, you'll likely also need to add this to your .zshrc file:
$ echo 'bindkey "^X\\x7f" backward-kill-line' >> ~/.zshrc
as by default ZSH doesn't map backward-kill-line to anything.
Furthermore, you can also delete everything to the right of your cursor by mapping:
⌘+fn+←Delete or ⌘+Delete→ to Send Hex Codes:
0x0b
I wrote a comprehensive guide to adding most of OSX's standard keybinding to your terminal here
In OSX, ⌥+⌫ and ⌘+⌫ are the shortcuts for deleting a word and deleting a line respectively. ⌘+ ← and ⌘+ → are for going to the beginning and end of lines. By default, iTerm2 isn't configured this way, and there are a lot of misleading guides online. The following is what I've found to work on my machine.
Open the preferences (⌘+,) and go to the Keys tab.
Add a global shortcut key, and just type in your shortcut
In the Action dropdown, select Send Hex Code
The hex codes for...
Deleting a word: 0x17.
Deleting a line: 0x15.
Moving to the beginning of the line: 0x01.
Moving to the end of the line: 0x05.
Just open a new tab, and it should work!
Here is a screenshot, for clarity:
I hope this may help you
map ⌥ <- Delete to Send Hex Codes: 0x1B 0x08
I had test for it, and it is correct.
18.09.2013 update
this delete one word, not a line.
As pointed ^U deletes the line. You can easily remap the command by using Better Touch Tool.
It also has cool features for automation, mouse, pad and keyboard mapping. Also includes a window feature for smart borders.
On iTerm2 you can set the exact same shortcuts of your OS. In this case, as the default shortcut to delete a line on Mac OS is ⌘+Delete (backspace), you can do so.
To set the default keybindings of iTerm you have to:
Go to Preferences (or ⌘+,)
Profiles
Keys
Key Mappings
Presets...
Select the "Natural text editing" option
The location has changed. In order to enable natural editing go to:
Preferences -> Profile -> Keys -> Load Presets... -> and select Natural Text Editing
For more info and tweeks go https://blog.arturofm.com/install-iterm-terminal-emulator-on-macos/
I found out that the Bash shell supports a type of autocompletion that is different from the "traditional" autocompletion, where all possibilities get listed on the following line.
With the "traditional" autocompletion, if I type ch and then press the Tab key, I get something like:
$ ch
chacl chgrp chmod chown chvt
But if I add the following line to my /etc/inputrc (which remaps the Tab key to the built-in menu-complete function):
Tab: menu-complete
then the behavior of the shell changes: the word to be completed is replaced "inline" with a single match from the list of possible completions, and if I press the Tab key again, the word gets replaced with the next match.
I found this useful, but I still wanted to keep the traditional autocompletion and have it bound to the key combination Ctrl + Tab. So I added the following line to my /etc/inputrc file, according to what the readline library documentation suggests:
Ctrl-Tab: complete
However, adding this line only seems to make both Tab and Ctrl-Tab call the traditional complete function.
Does anyone know what I am doing wrong?
Thanks in advance!
To start with, I'm not a massive expert in this area, but I think I can answer your question. First of all, while you are using Bash, Bash is a shell which interprets keyboard commands that it receives from a terminal / console. While you are informing Bash how to react to specific key combinations in the inputrc file, your Terminal determines precisely which character is 'sent' to the Shell before the inputrc file even enters the equation.
Unfortunately, on my system (granted, it's OSX - but I don't think this is strange behaviour when compared to Linux), both Tab and Ctrl-Tab send the same keyboard input to the shell. Infact, both Tab and Ctrl-Tab send a Ctrl-I command to the shell, and indeed, if I enter Ctrl-I when using the terminal, it performs the completion as if I hit Tab.
The software (installed on most Linux systems by default), showkey will tell you what keys the shell is receiving when you press specific keyboard inputs as you push them.
Anyway, my suggestion to you is to use Shift-Tab, which does appear to send it's own key-code to the shell. Shift-Tab on my computer shows up (using showkey) as '<ESC>[Z', which I think is pretty standard across the board. As such, your inputrc file with the following bindings should allow you to use shift-tab instead of ctrl-tab to achieve what you desire:
Tab: menu-complete
"\e[Z": complete
The \e in the second binding represents the escape character, and the [Z are simply the characters as shown using showkey. You can get a similar effect on OSX by simply using cat, running cat from within a terminal and pressing Shift-Tab will show you "^[[Z", where ^[ represents the escape character and the other characters are as before.
I know this doesn't resolve your question precisely, but as I don't think you are able to use Ctrl-Tab as a key combination, without re-mapping Ctrl-Tab to another keybinding within your terminal (more likely to be easier if you are using a GUI terminal), this is likely as close as you can get without significant effort!
I have ShiftTab bound to menu-complete-backward, so it goes back one step if I skipped the right completion, and I've mapped Ctrlq to complete, so if there are several possible completions I hit Ctrlq to list them without having to cycle through them.
# Make Tab cycle between possible completions
# Cycle forward: Tab
# Cycle backward: Shift-Tab
TAB: menu-complete
"\e[Z": menu-complete-backward
# Make C-q display the list of possible completions
Control-q: complete
# Display the list of matches when no further completion is possible
set show-all-if-unmodified on
Edit: Ctrlq is bound to quoted-insert by default, that is, it tells the shell to take the next key literally. quoted-insert is also bound to Ctrlv, so you don't lose that functionality if you rebind Ctrlq. Anyway, I've found that AltESC also works, by default, for showing the possible completions (as far as I can tell it is equivalent to TAB); note that it may be seized by Gnome, then either double press ESC or rebind "Switch windows directly" in Settings → Devices → Keyboard → Navigation.
The following should achieve what you're looking for (if I understand correctly!)
In your .inputrc
# display all possible matches for an ambiguous pattern at first tab
set show-all-if-ambiguous on
# next tab(s) will cycle through matches
TAB: menu-complete
# shift tab cycles backward
"\e[Z": menu-complete-backward
Where to start, if you can or cant do this is dependent your keyboard and your drivers and there isn't one catch all answer. Each key press and release generates a sequenced key pair (key down and release) (scancode) these codes are then translated by the kernel into keycodes for example on my laptop keyboard 0x3a 0xba are translated to keycode 15 (down and up) these are then translated into actions such as return letter c a / you can assign actions to keysyms using the keycode/hex/binary/octal notation which codes match which letters is determined by the kernel translation table which is fairly standardized, however the first part signal that's translated to keycodes is different for most keyboards.
Continuing with the earlier example for me shift tab (and alt and control and any combination) produce keycode 15 however in hex it produces 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a and this is because shift alt and control are special keys (modifiers) these multiply out against the keycodes and fill out the dumpkeys table the kernel is limited to the number of assignments as well this is determined by your choice of keymap and shares resources with your terminal colors (if your char set its defined above the threshold it limits your terminal color scope). And this all goes out the window if your in an xserver and has a whole new system. Most of these things can be changed,modified and manipulated by the user and programs installed. My point to all this is to emphasize that there is no catch all for the mapping of the tab key and its going to vary keyboard drivers to kbd drivers (now if you find a solution that happens to work for you excellent :)) but chances are it won't be portable and might not work if you change keyboards and might not translate between xserver and tui. What i recommend is learning the steps to modify your kbd on the go.
will give you the decimal octal hex notation for a key press on the same line
--full-table -1 >> keytable
will give you a documented with your full list of keycode->keysym pairing in a format that will give you a better picture of your layout and from there you can either use loadkey to change a keys value or ad an entry in .inputrc or your main rc file. You can also create a custom key.map file.
Further escape sequence translation is determined by the "$TERM" variable and each virtual terminal emulator can be different
infocmp "$TERM"
will give you a list of your terminal escape sequences
Resources:
https://man7.org/linux/man-pages/man4/console_codes.4.html
https://www.gnu.org/software/screen/manual/html_node/Input-Translation.html
http://kbd-project.org/docs/scancodes/scancodes.html
https://www.vt100.net/
So to sum up.
Your keyboard drivers
Your kemap choice
Your virtual terminal emulator
and your kernel
form the backbone of remapping dificult keys (tab/s-tab/a-tab)
I'm not sure Ctrl-Tab is a real character; my terminal, for instance, ignores the combination. I think the only way to use Ctrl-Tab is to use your terminal emulator to map it to some otherwise unused escape sequence, then bind that sequence to complete.
Is there a way to use an alt / option key as a meta key but still be able to use it to make some characters which need it?
For example, in my local keyboard layout:
# is alt + 2
\ is alt + shift + 7
| is alt + 7
etc.
So, if I set alt as a meta key, I can't make those characters anymore. On the other hand, using "press esc, release esc, press a key" to make meta key sequences makes my hands hurt.
Any Emacs users with international keyboards who have solved this, please give any tips you might have! :)
Edit:
It appears that I can set alt as a meta key and then add these kind of settings in inputrc: "\e2": "#" This works in the bash shell but it still won't work with Emacs though, so no good.
I use a Swedish keyboard in Mac OS X and use the following setup for Emacs.app:
First I have KeyRemap4MacBook installed and I have it setup to change the left Option key to Command.
I then have the following in my .emacs:
(setq mac-option-modifier 'none)
(setq mac-command-modifier 'meta)
This makes Emacs treat command as Meta and ignore Option. Since the left Alt/Option key is remapped to command, this makes it work lite meta while the right Alt/Option key still works for entering special characters like # [] and {}.
App specific Mac shortcuts like Cmd+C and Cmd+V no longer work, but global shortcuts like Cmd+space for Spotlight and Cmd+Tab for app switching do.
Update:
If you use iTerm2 as a Terminal, that has support for mapping only the left Alt/Option key to meta, which means you can still use the right AltGr/Option key for entering special characters. This also means you can use meta as normal inside Emacs running in the iTerm2 terminal.
I have a Swedish keyboard on my Mac and I'm using Aquamacs. Adding the two lines (attribution goes to Joakim Hårsman)
(setq mac-option-modifier 'none)
(setq mac-command-modifier 'meta)
in .emacs (and restarting Aquamacs) did the trick for me.
with iTerm2 you can map the left option key to ESC/meta and leave the mapping of the right option key to "normal". This way you can use the right option key to type accents etc.
Think about using a full featured Emacs for Mac OS X. I use Carbon Emacs but I believe others (say Aqua Emacs or X11 Emacs) would do the trick.
If you insist on using Emacs in a terminal you can use the C-x 8 prefix as a compose key. Try C-x 8 C-h to get a list of possibilities.
See http://www.emacswiki.org/emacs/EmacsForMacOS
Two work-arounds I use:
I use xterm running under X11.app. X11.app uses the command key as meta.
When running emacs in Terminal.app, I just use the rfc1345 input-method, which allows me to enter all kinds of crazy non-ascii characters without needing an option key.
Check out cmd-key-happy. This little app has worked wonders for me. It allows you to use command as meta, with exceptions that you can configure.
Author's info follows:
This program allows you to swap the command and alt (or option) keys
in any application, but in particular Terminal.app.
http://github.com/aim-stuff/cmd-key-happy
This is an old post but adding an alternatives for Robots to find.
I borrowed a couple of files from Aquamacs(emulate-mac-keyboard-mode.el, aquamacs-tools.el) that fixes the problem (I have a Italian-Pro keyboard) :
(defun aq-binding (any)
nil)
(load "~/.emacs.d/emulate-mac-keyboard-mode.el") ;; 'noerror
this provides:
few minor modes (emulate-mac-italian-keyboard-mode,
emulate-mac-french-keyboard-mode,
mulate-mac-swiss-german-keyboard-mode, etc)
a menu to play with all the options provided by Aquamacs
Tested with Emacs-23.3-universal-10.6.6 and seems to work ok for me.
Thanks Aquamacs for this, what about pushing this upstream if not already done.
It's worth thinking about the assumption behind the question. I mean to say that the real problem is making the characters that currently seem to need the option key. This problem can be solved without achieving simultaneous 'meta key + alt functionality'.
Let me explain: I have a similar problem. On my UK keyboard, shift-3 is mapped to the pound sign, £, which means that I generally need to hit option-3 to get the very useful # - a real problem in Terminal, where I use option as meta. However, I find most of the above solutions to be a little over-the-top. I don't want to change to another version of Emacs (eg. Aquamacs), to switch to a different Terminal application (eg. iTerm or xterm), or to install a key-remapping application (eg. KeyRemap4MacBook) all for the sake of one symbol! Perhaps that would suit some people, but I thought it was worth pointing out that if the problem is just one character, it can be solved with a nine-character text file.
With regard to my personal version of this problem, I find the simplest solution is to create a file called .inputrc in my home directory, consisting of the following single line:
"§": "#"
This re-maps the (to me, quite useless) § that can be found to the left of the 1 on the current Mac keyboard to the (almost indispensable) #. That suits me even better than the default setup, because I can now get # with a single keypress. If there were any other characters I needed to remap, it would just be a matter of adding an extra line for each one.
Anyway, that deals with how to get the missing character in the shell, but if you also want it in Emacs (which you didn't say but is probably the case) then you can add something like this to your .emacs file (where 35 is the ASCII for the character I happen to want, ie. #):
(global-set-key (kbd "§") 'insert-hash)
(defun insert-hash ()
(interactive)
(insert 35))
It might not be such a neat solution if there were dozens of characters that I routinely wanted to access via the option key, but there aren't.
I hope this helps somebody. As a mere weekend hacker, I ordinarily wouldn't dare post an answer to a question on Stack Overflow...
Special keyboard layout with option deadkey
My solution to this problem is a special keyboard layout I have written, U.S. custom. It provides an option deadkey that produces option combos without having to use the physical ⌥ Option modifier key. For instance, the character ⟨ç⟩ is produced as follows on a normal U.S. keyboard layout:
Hit ⌥ Option+c.
The U.S. custom keyboard layout adds a second way of producing ⟨ç⟩:
Hit ⇧ Shift+§ (the option deadkey), then release it, then hit c.
This works even in Terminal.app when Use option as meta key has been checked.
Note that the U.S. custom keyboard layout does two additional things:
It converts plain § into a ⎄ Compose key (so you could also produce ⟨ç⟩ by hitting §, then ,, then c).
It replaces the CapsLock mapping by a (significantly extended) U.S. Extended keyboard layout.
Remap option deadkey to right option modifier key
If you have a physical ANSI keyboard, then you lack the § key. In that case, I recommend assigning the § key to some other key, for instance to the right ⌥ Option modifier key. Install KeyRemap4MacBook, open ~/Library/Application\ Support/KeyRemap4MacBook/private.xml and paste the following code:
<?xml version="1.0"?>
<root>
<item>
<name>Send ISO Section for right Option</name>
<identifier>private.send_iso_section_for_right_option</identifier>
<autogen>--KeyToKey-- KeyCode::OPTION_R, KeyCode::UK_SECTION</autogen>
</item>
<item>
<name>Send Shift+ISO Section for Shift+right Option (keep normal right Option without Shift)</name>
<identifier>private.send_shift_iso_section_for_shift_right_option</identifier>
<autogen>--KeyToKey-- KeyCode::OPTION_R, ModifierFlag::SHIFT_R, KeyCode::UK_SECTION, ModifierFlag::SHIFT_L</autogen>
<autogen>--KeyToKey-- KeyCode::OPTION_R, ModifierFlag::SHIFT_L, KeyCode::UK_SECTION, ModifierFlag::SHIFT_L</autogen>
</item>
</root>
Then, open the KeyRemap4MacBook preference pane, hit ReloadXML and then select “Send ISO Section for right option”. Now, your ⌥ Right Option key is remapped to §, so while the U.S. custom keyboard layout is active, hitting ⇧ Shift+⌥ Right Option will give you the option deadkey state (hitting ⌥ Right Option without additional modifiers will give you a deadkey state equivalent to the option modifier.
If want to keep ⌥ Right Option when ⇧ Shift is not pressed (instead of the ⎄ Compose key), then select “Send Shift+ISO Section for Shift+right Option (keep normal right Option without Shift)” in the KeyRemap4MacBook preference pane (instead of “Send ISO Section for right Option”). Like that, only ⇧ Shift+⌥ Right Option will produce the option deadkey, while plain ⌥ Right Option will continue to work as an option modifier. You can even continue using ⌥ Right Option+⇧ Shift modifier combos (for instance ⌥ Right Option+⇧ Shift+c→⟨Ç⟩) as long as you don’t hit ⇧ Shift first.
The above answers mention ways to enter non-ascii input, but that's not really the problem here. The C-x 8 method lets you enter a bunch of non-ascii, but the problem is that you need the option key on mac just to enter the (ascii) character `|' (vertical bar)!
So how do you then enter stuff like M-| (region to shell command) when running emacs in ssh under Terminal.app? No way for it but to use the escape key, since | is option-7 and Terminal.app for some stupid reason won't let you use Cmc as meta :-(
(If anyone knows of a hack (SIMBL perhaps?) that actually does let Terminal.app use Cmd as meta, I'd be very grateful...)
The following solution works, is UNOBTRUSIVE and you don't need iTerm2 or Aquamacs or whatever.
Step 1
Keep "Use option as meta key" turned ON in the Terminal.app Settings.
Step 2
Edit ~/.inputrc (make it if it doesn't exist already), add the following line:
"\e3": '#'
This will remap ⌥ alt + 3 so that you produce a # character as expected in the terminal, instead of it annoyingly coming back with the prompt (arg: 3).
Step 3
Edit ~/.emacs, add the following line:
(global-set-key (kbd "M-3") "#")
This will remap ⌥ alt + 3 so that you produce a # character as expected inside emacs, instead of it annoyingly doing nothing.
Caveat 1, This is just 1 re-map. So ⌥ alt + ? (other keys) won't be remapped, e.g. you may wish to remap ⌥ alt + n to produce the tilde key ~. Simply follow the same steps outlined above obviously switching 3 with whichever key you need going forward.
Caveat 2, When you ssh into another box, you will face the same difficulties, but all you have to do there is edit the ~/.inputrc and ~/.emacs files on that box.
Caveat 3, I'm British, on a British MacBook. So I can't vouch for foreign MacBooks.
Aquamacs supports that, at least for my (french) keyboard. Once Aquamacs is installed (via drag'n'drop), you can go to Options -> Option, Command, Meta keys and choose an appropriate setting for your keyboard (in my case, ...Meta & French). I am not proficient with Emacs, but all the useful combinations I have tried seem to work ([, {, |, and so forth).
Supported keyboards, according to the menu items as of version 2.1, are :
British
US
Swiss-french
Swiss-german
Finnish
Italian-Pro
Italian
Spanish
French
German
I would guess the Aquamacs team would be grateful for any contribution, though, should your keyboard not appear in the list.
I bit the grass and started hitting the escape key instead. You get use to it...
I would like to mod this question up or something because i also use a Swedish keyboard where i must press alt+7 or alt+shift+7 to make | and \ respectively.
I also use Irssi in Terminal.app and these don't mix well.
I'm a long time vim user though so emacs is not an issue to me.
Isn't there some way to remap CMD to be Meta in Terminal.app?
So far i've been surviving by simply typing /wg N in Irssi because having those characters in my Terminal is much more important than IRC.
A solution would be worth gold to me though! :)
This is years late, but for people coming across this page whilst searching for a solution, as I did, I have decided to build one myself, one that doesn't require abandoning Terminal.app in favour of iTerm 2.
It is a simple status bar app that runs in the background and rewrites all left-Alt + $KEY key events to two key events in rapid succession, Esc, then $KEY; however, it only does this if Terminal.app is the focused application.
You can find it here at https://github.com/habibalamin/Metalt.
I assigned escape to the caps lock key and it works quite good. You can configure it easily in the mac system preferences > keyboard > modifier keys.
https://apple.stackexchange.com/a/282092/236382