unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Psionic K <psionik@positron.solutions>
To: Eli Zaretskii <eliz@gnu.org>, help-gnu-emacs@gnu.org
Subject: Re: Introspecting yas tab binding
Date: Sat, 3 Feb 2024 11:14:13 +0900	[thread overview]
Message-ID: <CADQMGATm8jkO6dvTg102b6KB+QpgGjE3REKYRzEy3XadSE3MBg@mail.gmail.com> (raw)

> What is "Yas minor mode"?  I don't see it in Emacs 29 or in Emacs 30.

I will ignore what appears to me to be some kind of sarcastic
perversion of reality attempting to imply "go away, this is not
Emacs", which it most surely is not, and rephrase the question to
focus on Emacs specific elements.

I have identified a command by viewing lossage called
`mysterious-command`.  It is called in some situations when I press
TAB, but not always.

`where-is' reports that `mysterious-command' is not bound on any key.
Lossage reports:

 <tab>          ;; mysterious-command

I have found `mysterious-command' in a keymap menu item, and the key
definition matches the command I observe, but I cannot get debug to
trigger when using `debug-on-entry' on the function assigned as the
`:filter' in that menu item, so I'm unsure if the menu item is related
at all.

I can get a debugger for `mysterious-command' itself, which displays a
stack beginning with `command-execute', called only with
`mysterious-command'.   I need to discover how `mysterious-command' is
arrived at to work backwards toward the mechanism used to make it only
receive the TAB key in certain situations.

Evaluating (key-binding (kbd "TAB")) shows that the binding is
situational, returning different commands depending on the location of
the point, but still not how.   After following the code into
`lookup_key_1', I am expecting attaching a debugger will reveal that
the external state, the keymap with the menu item, is changed between
calls, but again not where this behavior originates.

What Emacs facilities might uncover the states and execution flow
responsible for this situational behavior for the TAB key sequence?
How can I identify or rule out the menu item's responsibility?



             reply	other threads:[~2024-02-03  2:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-03  2:14 Psionic K [this message]
2024-02-03  6:11 ` Introspecting yas tab binding tomas
2024-02-03  6:43   ` Joost Kremers
2024-02-03  7:09     ` Emanuel Berg
2024-02-03  7:42     ` Eli Zaretskii
2024-02-03  7:57       ` Emanuel Berg
2024-02-03  6:54   ` Emanuel Berg
2024-02-03  8:06 ` Eli Zaretskii
2024-02-03  8:29   ` Emanuel Berg
  -- strict thread matches above, loose matches on Subject: below --
2024-02-03 13:47 Psionic K
2024-02-02 12:34 Psionic K
2024-02-02 12:39 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADQMGATm8jkO6dvTg102b6KB+QpgGjE3REKYRzEy3XadSE3MBg@mail.gmail.com \
    --to=psionik@positron.solutions \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).