[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Introspecting yas tab binding
From: |
Psionic K |
Subject: |
Re: Introspecting yas tab binding |
Date: |
Sat, 3 Feb 2024 22:47:06 +0900 |
It's solved. The general method is described at the end.
> For the first question, we have trace.el, stepping through Lisp code
> in Edebug, and stepping through code in keyboard.c in GDB. For the
> second, I would modify the offending menu entry in some way that would
> signal that it is responsible
I re-bound the command to "X" like so:
(setcar (car(last yas-minor-mode-map)) (string-to-char "X"))
This confirmed the responsibility of the menu binding, the contents of
which are:
(9 menu-item "" yas-expand :filter yas-maybe-expand-abbrev-key-filter)
> The fact that :filter function cannot be debugged using debug-on-entry
> perhaps warrants a bug report.
I confirmed that `trace-function' was able to see the filter be
called. However, debug-on-entry did not trigger a debugger session.
`key-binding' succeeds in uncovering that a binding exists, but not where it is.
Identifying keymaps from `current-active-maps' and corroborating the
symbol names with the obarray values, then calling `keymap-lookup'
appears to be viable.
The `keymap-lookup' returns nil or `yas-expand' depending on the
:filter result. The user must configure the filter to be true to
observer the binding. This is the only such conditional binding I
have observed in Emacs that didn't rely on variables in
`emulation-mode-alists` or modifying keymaps themselves.
Re: Introspecting yas tab binding,
Psionic K <=