God Mode - C-i and <tab> separation?

I use this in my init file to separately bind ctrl+i and tab: ```el (define-key input-decode-map [(control ?i)] [C-i]) (define-key input-decode-map [(control ?I)] [(C-S-i)]) ``` I'm not exactly clear what this snippet is doing, as I copied and modified it from an emacs.stackexchange answer. I tried to use God Mode today, however, pressing `i` doesn't activate by keybinding, but that of the tab key. How do I fix this?

`god-mode` uses `read-event` function, which does not honor `input-decode-map`. See [https://www.gnu.org/software/emacs/manual/html\_node/elisp/Reading-One-Event.html](https://www.gnu.org/software/emacs/manual/html_node/elisp/Reading-One-Event.html) You may want to try my fork: [https://github.com/YangZhao11/god-mode/tree/struct](https://github.com/YangZhao11/god-mode) I updated this with `read-key`, which does honor `input-decode-map`. It could solve your problem. You'll also need to update your config a bit: the key to `god-mod-alist` is now a character instead of a string.

EDIT: After reviewing the response from u/zhyang11, I'm not sure this will solve OP's problem, which is specific to God-mode. And I'm now confused, since I don't understand how `read-char` can translate the <tab> key to "C-i" after that translation's been overridden in `local-function-key-map`. <head-scratcher> From [the Elisp manual](https://www.gnu.org/software/emacs/manual/html_node/elisp/Function-Keys.html): >In ASCII, C-i and TAB are the same character. If the terminal can distinguish between them, Emacs conveys the distinction to Lisp programs by representing the former as the integer 9, and the latter as the symbol tab. > >Most of the time, it’s not useful to distinguish the two. So normally local-function-key-map (see Keymaps for Translating Sequences of Events) is set up to map tab into 9. Thus, a key binding for character code 9 (the character C-i) also applies to tab. So if you want to remove the translation from <tab> to "C-i", you need to do it in `local-function-key-map`, not`input-decode-map`. Also, it's not "C-i" being translated to <tab>. It's the other way around. You can check this by entering "C-h v local-function-key-map RET". Then find the entry for tab by doing "C-s (tab". You'll see the entry `(tab . [9])`, which indicates that the <tab> function key is being translated to the integer 9 ("C-i"). You can prevent this translation from occurring by putting this in your init file: (define-key local-function-key-map [tab] nil) After that's evaluated, the <tab> key is no longer translated to "C-i", so you can bind those keys to different commands.

I don't know what I'm talking about :) Differentiating TAB and C-i under terminal requires quite some config. You'll need to make sure the terminal sends different key codes in the first place. I have not made that work, partly from a lack of trying.

> I don't know what I'm talking about :) I think you do though. Haha > Differentiating TAB and C-i under terminal requires quite some config. I wouldn't bother with it in the terminal. (Actually, I wouldn't bother with it in GUI either, but it seemed like an interesting problem to try to solve.) I'm still surprised to have discovered (based on your comment) that `read-char` translates <tab> to "C-i" even when it's overridden in the translation maps. (I tried and confirmed that that's the case.) I can only assume that there's an additional translation map hardcoded into Emacs's C internals and used by the `read-char` function. Thank you for enlightening me.

>I can only assume that there's an additional translation map hardcoded into Emacs's C internals and used by the > >read-char > > function. Yeah it's hard-coded in C. [https://github.com/emacs-mirror/emacs/blob/master/src/lread.c#L735](https://github.com/emacs-mirror/emacs/blob/master/src/lread.c#L735) If you evaluate `(symbol-plist 'tab)` in your environment you'll find a bunch of config that read-char uses to translate it into ascii. It's trying really hard to give you ascii when you asked for it.

I tested a bit - it turns out `read-key` translates `<tab>` to `C-i`, so that would not work here. And the horror I found when reading the source of `read-key`. It simply calls `read-key-sequence-vector` and tries to interrupt the call at 0.01s intervals, so "hopefully" it will exit when 1 key is entered. Ah the miracle of software engineering.