|
From: | Juri Linkov |
Subject: | bug#9923: 24.0.91; `where-is' does not find recentf menu items (cmds, not files) |
Date: | Sun, 29 Aug 2021 19:48:15 +0300 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) |
> I'm wondering whether where-is could go at this the opposite direction. > I mean, the menu system knows how to expand all this stuff... so... > could we ask it to do that, and then look at the results of that instead > of parsing the keymap ourselves in where-is? Another question: is it possible not to evaluate :filter in where-is as all? Yesterday I added to context-menu-map such lines: (let ((fun (mouse-posn-property (event-start last-input-event) 'context-menu-function))) but now noticed that after typing 'C-h m' it fails with: Debugger entered--Lisp error: (args-out-of-range 1786) mouse-posn-property((#<window 178 on *scratch*> 1786 (0 . 0) 0) context-menu-function) context-menu-map() (lambda (_) (context-menu-map))(ignore) where-is-internal(ignore nil t) #f(compiled-function (sym) #<bytecode -0x1145d1e4eb4c2a6>)(ignore) help-fns--list-local-commands() describe-mode() funcall-interactively(describe-mode) command-execute(describe-mode) because context-menu functions are called from where-is-internal without a mouse click. Some time ago I already tried to workaround this problem in help-mode-context-menu with: (when (and ;; First check if `help-fns--list-local-commands' ;; used `where-is-internal' to call this function ;; with wrong `last-input-event'. (eq (current-buffer) (window-buffer (posn-window (event-start last-input-event)))) (mouse-posn-property (event-start last-input-event) 'mouse-face)) And now it reared its ugly head again.
[Prev in Thread] | Current Thread | [Next in Thread] |