From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Introspecting yas tab binding Date: Sat, 03 Feb 2024 10:06:02 +0200 Message-ID: <86h6iq3rbp.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8759"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 03 09:06:36 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rWB2p-000274-Sp for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 03 Feb 2024 09:06:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWB2L-00077F-VQ; Sat, 03 Feb 2024 03:06:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWB2K-000776-Gm for help-gnu-emacs@gnu.org; Sat, 03 Feb 2024 03:06:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWB2K-0000i0-6P for help-gnu-emacs@gnu.org; Sat, 03 Feb 2024 03:06:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JIBRnxbD2i0KHuyynFodgxRHDhzPptdpkl6lnXtrtbQ=; b=IU2DxglbE7m9 tApqowE5MFX13E5H2xvLM46bxyPDnxITsl+47sAe7x/eb4NUlb3eW9ceEt/zvEY51XUqWLwrm4fJq +hpslq2m7xRD3enxht7mapTaNgARE6K20zfrinD66x23vQDELG5fi9vBDNgDp/9G6WneCsA57iDzd 4aSIySRInckY2NIdzQ9KrcW5LtQ9euJODWwkyczES6ZgyZCaS4jEejWi3/9fgJzs6OkKgl1Z1kxwI VpKSbon+Rp76PUNUSXlzBV0TJP5nK2oivJfft9puwZXeZMIaAfPAzTJFKcoJMcUP2KH0yjcMLQG7V isLoU5zhNZWKXviCRh6vcg==; In-Reply-To: (message from Psionic K on Sat, 3 Feb 2024 11:14:13 +0900) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145866 Archived-At: > From: Psionic K > Date: Sat, 3 Feb 2024 11:14:13 +0900 > > 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. The simplest way is to add some call to 'message' in the function assigned to :filter, and then look for that message in *Messages*. The message could include the details you are looking for, like the current keymap in effect, for example. The fact that :filter function cannot be debugged using debug-on-entry perhaps warrants a bug report. > 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. This is a much more general question, and I don't think we have facilities other than stepping through the code to answer such general questions. > 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? The first question is much more general than the second. 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, like produce some message or maybe call an entirely different function, and then watch for the effects.