From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: [PATCH] Re: zed-set-filename breaks zed keymap?
Date: Sun, 25 Apr 2021 12:35:03 -0700 [thread overview]
Message-ID: <CAH+w=7bV1nTYjfpafs1HM1gxnCDqpPZqfSpK5gBqHZ-LDJbccQ@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7bCUavuPzMKvJtu0mvrp8HuzGUdpkXbF7ZkxTWWkPx3QQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
Reviving this from a year-ish ago, so including that thread for
context ... please see below.
On Tue, May 26, 2020 at 8:30 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I was trying to get zed-set-file-name to work with my "zed -h" change,
> and discovered that even with plain "zed file" after entering the file
> name into read-from-minibuffer, ^X^W no longer works to exit from zed,
> and a bare return DOES exit it. Apparently returning from
> read-from-minibuffer does not constitute "the next command" for
> purposes of zle -K restoring the keymap? Did this work at one time?
>
> Also, it is possible to execute zed-set-file-name recursively from
> inside read-from-minibuffer, which is a bit strange.
On Tue, May 26, 2020 at 9:25 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The documentation for zed-set-file-name seems contradictory as well.
> In the first paragraph it says:
>
> ... because of zed's rebindings you will have to type ^j at the
> end instead of the return key ...
>
> but then the second paragraph says
>
> While zed-set-file-name is running, zed uses the keymap
> zed-normal-keymap, which is linked from the main keymap in effect
> at the time zed initialised its bindings. (This is to make the
> return key operate normally.) ...
>
> The return key does not in fact "operate normally" during
> zed-set-file-name, but something else strange is going on with the
> keymaps.
After some experimentation ...
zed does these things up front:
1. Creates the keymap zed as a copy of main (bindkey -N zed main)
2. Aliases zed-normal-keymap (bindkey -A main zed-normal-keymap)
3. Creates the keymap zed-vicmd as a copy of vicmd
It then eventually runs: vared -M zed -m zed-vicmd ...
Next bin_vared hides the "main" keymap and renames the keymap passed
for -M as "main", so $KEYMAP is not "zed".
zed-set-file-name then does this:
1. zle -K zed-normal-keymap
2. read-from-minibuffer
However, zle -K is useless, because eventually read-from-minibuffer runs
zle recursive-edit -K main
and because of vared's dirty trick, this pulls in the "zed" keymap,
not the keymap that read-from-minibuffer actually wanted.
So ... what's the correct fix here? Shortest is to change
zed-set-file-name to use
bindkey -A zed-normal-keymap main
Attached patch does that. Other options:
Change vared to act more like "zle widget -K"? I don't think that
breaks any promises, but implicitly $KEYMAP has been "main" inside
vared all these years (when not viins).
Change read-from-minibuffer to make its own keymap? It's unclear how
to accomplish that cleanly when vared has already done its thing,
unless we force an explicit set of keybindings.
Change read-from-minibuffer to pass in the keymap it should bind for
recursive-edit? How? -K option to go with the single existing -k
option?
Rewrite zed-set-file-name to invoke zle recursive-edit directly, with
the correct keymap?
[-- Attachment #2: zsfn-patch.txt --]
[-- Type: text/plain, Size: 985 bytes --]
diff --git a/Functions/Zle/zed-set-file-name b/Functions/Zle/zed-set-file-name
index da3421e71..c77a9d26e 100644
--- a/Functions/Zle/zed-set-file-name
+++ b/Functions/Zle/zed-set-file-name
@@ -2,8 +2,25 @@ emulate -L zsh
autoload -Uz read-from-minibuffer
-zle -K zed-normal-keymap
-
-local REPLY
-read-from-minibuffer "File name: "
-zed_file_name=$REPLY
+case $curcontext in
+ (zed:::)
+ local curcontext=zed-set-filename:::
+ # The call to vared from zed does the equivalent of
+ # bindkey -A zed main
+ # which confuses read-from-minibuffer. Fix it.
+ bindkey -A zed-normal-keymap main;;
+ (zed-set-filename:::)
+ zle -M "zed-set-file-name: may not be called recursively"
+ return 1;;
+ (*)
+ zle -M "zed-set-file-name: not called from within zed"
+ return 1;;
+esac
+{
+ local REPLY
+ read-from-minibuffer "File name: "
+ zed_file_name=$REPLY
+} always {
+ # Re-install the zed keymap in the way vared should have all along
+ zle -K zed
+}
next prev parent reply other threads:[~2021-04-25 19:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 3:30 Bart Schaefer
2020-05-27 4:25 ` Bart Schaefer
2021-04-25 19:35 ` Bart Schaefer [this message]
2021-04-25 20:55 ` [PATCH] " Bart Schaefer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH+w=7bV1nTYjfpafs1HM1gxnCDqpPZqfSpK5gBqHZ-LDJbccQ@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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 NNTP newsgroup(s).