Re: visual/viopp modes are not detected by zle-keymap-select

Re: visual/viopp modes are not detected by zle-keymap-select

[Hugh X]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Got it. Thanks for the explanation. My preliminary thought is to use the
"visual" to update the prompt so that I can add/debug some key bindings in
the visual mode. Since you mentioned that these local keymaps will have
their own widget-binding methods through the interpreter, I wound whether
there is such special widgets that similar to *_init and *_exit.

Re: visual/viopp modes are not detected by zle-keymap-select

[Bart Schaefer]

On Feb 24,  4:59pm, Hugh X wrote:
}
} Got it. Thanks for the explanation. My preliminary thought is to use
} the "visual" to update the prompt so that I can add/debug some key
} bindings in the visual mode.

OK, that's the one context where it's potentially useful, but:

} Since you mentioned that these local keymaps will have their own
} widget-binding methods through the interpreter, I wound whether there
} is such special widgets that similar to *_init and *_exit.

In fact visual mode is the one case where there is NOT any such local
interpreter -- there's just a different keymap, which is still handled
by the global interpreter.  This is why it would not break anything to
invoke the zle-keymap-select hook.

However, there's also no clear begin/end of visual mode.  As presently
implemented, visual mode is a combination of a couple of different
states that can each be changed independently; the determination of
whether this "mode" is in effect is not made until the last instant
before ZLE waits for the next keystroke, and is forgotten as soon as
the keystroke has been consumed.  The keymap isn't even in place long
enough for the corresponding widget to see it; it's indistinguishable
from vicmd mode.

Consequently the zle-keymap-select hook would be called twice on every
keystroke during visual "mode", if naive implementation were adopted.

Re: visual/viopp modes are not detected by zle-keymap-select

[Bart Schaefer]

On Feb 23, 11:34pm, Hugh X wrote:
}
} The recent zsh 5.2 supports more vi modes including visual and viopp. When
} I switched from vicmd to visual, the zle-keymap-select fails to capture the
} keymap change in $KEYMAP. Please let me know if there is a way to indicate
} the current editor state enters the visual-mode. Thanks.

The zle-keymap-select hook is not called for "local" keymaps, which for
the most part means those that are active within the context of another
built-in widget invoked from one of the other keymaps.  Local keymaps
currently include:

command - inside execute-named-command
isearch - incremental search
listscroll - in completion lists
menuselect - in menu selection
viopp - reading bounds of vi range operator
visual - active region in vicmd

The reason for this is that local keymaps generally each have a special
interpreter for the widget bindings, and can't be allowed to branch off
to arbitrary user-defined widgets (including the hooks).

However, it looks to me as though visual mode could potentially be an
exception to this.  It uses the local map to look up the binding, but
then restores the vicmd map before invoking the widget.  On the one
hand, this means we *could* invoke zle-keymap-select (twice); on the
other hand, it means the mode is NEVER "visual" in any *other* context
where it might matter, except for updating the prompt.

I'm personally not a vim user so I have no idea how this corresponds to
actual vim behavior.  It'd also help to understand how you intend to
make use of the $KEYMAP value.

visual/viopp modes are not detected by zle-keymap-select

[Hugh X]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

Hi,

The recent zsh 5.2 supports more vi modes including visual and viopp. When
I switched from vicmd to visual, the zle-keymap-select fails to capture the
keymap change in $KEYMAP. Please let me know if there is a way to indicate
the current editor state enters the visual-mode. Thanks.


Regards, Hugh