Evil uses the TAB key by default to bind its
evil-jump-forward command to it. This key corresponds to both the
physical tabulator key and the C-i keybinding. Binding a command
to either TAB or C-i in Emacs[1] results in a command you
can invoke by pressing either of these. However, in GUI Emacs
instances you have an extra option, you can bind a command to
<tab>. This rather curious notation is for the tabulator key
symbol, a special keyboard event that is only sent by pressing the
tabulator key. Binding a command to it and a different command to
TAB therefore results in the former command being called upon
pressing the tabulator key and the latter upon pressing C-i. This
can be easily proven by enabling evil-mode in an Org file and
checking the resolved commands with F1 k.

In a perfect world having both C-i and the tabulator key doing
different things would work out of the box. Unfortunately this was
not the case for me. Some modes bind TAB, some bind C-i, some
bind both. I initially unbound TAB in Evil for having Emacs
defaults exposed and later went over to a bit of keyboard wizardry
to tell Emacs to discern both keybindings at the input decoding stage
and defined a <C-i> symbol that way which I’ve bound to
evil-jump-forward in the appropriate Evil keymap and otherwise to
do what TAB would.

I assumed this would solve problems once and for all. This is where
Yasnippet enters the stage. For a yet undiscovered reason it undoes
my carefully set up input decoding hack. My first reaction was
checking whether this was a phenomenon manifesting itself immediately
after init. It wasn’t. No, it is triggered at a later point in my
editing sessions and remains hard to reproduce. Searching in its
sources only made me learn about yet another obscure keyboard event
notation which apparently originates from Lucid Emacs. I
ended up unbinding everything looking like an offending key in its
keymaps and documented the not so trivial procedure of making an
alternative trigger key work in my Emacs configuration.

The bug was finally gone. Still angry over what I’ve went through (in
the end I had only figured out a workaround), I started reading
Yasnippet’s sources. I found enough horrific things in it to compile
my Top 5. Enjoy!

(defunyas--fallback-translate-input(keys)"Emulate `read-key-sequence', at least what I think it does.
Keys should be an untranslated key vector. Returns a translated
vector of keys. FIXME not thoroughly tested."(let((retval[])(i0))(while(<i(lengthkeys))(let((ji)(translatedlocal-function-key-map))(while(and(<j(lengthkeys))translated(keymapptranslated))(setqtranslated(cdr(assoc(arefkeysj)(remove'keymaptranslated)))j(1+j)))(setqretval(vconcatretval(cond((symbolptranslated)`[,translated])((vectorptranslated)translated)(t(substringkeysij)))))(setqij)))retval))

(defunyas--save-backquotes()"Save all the \"`(lisp-expression)`\"-style expressions
with their evaluated value into `yas--backquote-markers-and-strings'."(while(re-search-forwardyas--backquote-lisp-expression-regexpnilt)(let((current-string(match-string-no-properties1))transformed)(save-restriction(widen)(delete-region(match-beginning0)(match-end0)))(setqtransformed(yas--eval-lisp(yas--read-lisp(yas--restore-escapescurrent-string'(?`)))))(goto-char(match-beginning0))(whentransformed(let((marker(make-marker)))(save-restriction(widen)(insert"Y");; quite horrendous, I love it :)(set-markermarker(point))(insert"Y"))(push(consmarkertransformed)yas--backquote-markers-and-strings))))))

(defunyas--indent-according-to-mode(snippet-markers)"Indent current line according to mode, preserving SNIPPET-MARKERS.";;; Apropos indenting problems....;;;; `indent-according-to-mode' uses whatever `indent-line-function';; is available. Some implementations of these functions delete text;; before they insert. If there happens to be a marker just after;; the text being deleted, the insertion actually happens after the;; marker, which misplaces it.;;;; This would also happen if we had used overlays with the;; `front-advance' property set to nil.;;;; This is why I have these `trouble-markers', they are the ones at;; they are the ones at the first non-whitespace char at the line;; (i.e. at `yas--real-line-beginning'. After indentation takes place;; we should be at the correct to restore them to. All other;; non-trouble-markers have been *pushed* and don't need special;; attention.;;(goto-char(yas--real-line-beginning))(let((trouble-markers(remove-if-not#'(lambda(marker)(=marker(point)))snippet-markers)))(save-restriction(widen)(condition-case_(indent-according-to-mode)(error(yas--message3"Warning: `yas--indent-according-to-mode' having problems running %s"indent-line-function)nil)))(mapc#'(lambda(marker)(set-markermarker(point)))trouble-markers)))

;; Apropos markers-to-points:;;;; This was found useful for performance reasons, so that an;; excessive number of live markers aren't kept around in the;; `buffer-undo-list'. However, in `markers-to-points', the;; set-to-nil markers can't simply be discarded and replaced with;; fresh ones in `points-to-markers'. The original marker that was;; just set to nil has to be reused.;;;; This shouldn't bring horrible problems with undo/redo, but it;; you never know