[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69306: 30.0.50; defining menu-items with :enable enables them uncond
From: |
Eli Zaretskii |
Subject: |
bug#69306: 30.0.50; defining menu-items with :enable enables them unconditionally |
Date: |
Fri, 23 Feb 2024 09:23:45 +0200 |
> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: 69306@debbugs.gnu.org
> Date: Thu, 22 Feb 2024 15:19:26 -0600
>
> Basically, I am trying to define a conditional keybinding. The real-world
> example I’m working with is:
>
> (when-let ((cmds-del (and (modulep! :completion corfu +tng)
> ’(menu-item “Reset completion” corfu-reset
> :enable (and (> corfu–index -1)
> (eq corfu-preview-current
> ’insert)))))
> (cmds-ret ’(menu-item “Insert completion” corfu-insert
> :filter (lambda (cmd)
> (if (eq corfu–index -1)
> (corfu-quit)
> cmd)))))
> (map! :when (modulep! :completion corfu)
> :after corfu
> :map corfu-map
> [backspace] cmds-del
> “DEL” cmds-del
> :ig [return] cmds-ret
> :ig “RET” cmds-ret))
>
> Here, the :filter and :enable properties are used to conditionally enable
> their
> respective keybindings. The :filter property works as expected, but the
> :enable
> property does not. The backspace keybinding is always enabled, even when the
> :enable property is evaluates to nil.
If you expect that the key binding will be disabled via :enable, then
I don't think this is supported except in menus (and tool bars and tab
bars): the value is evaluated by the menu-related code, when it
actually displays the menu, and in your case there's no menu. The
:filter attribute is interpreted differently, so it just happens to
work. But that's sheer luck, I'd say.
Adding Stefan in case he has comments.