Handle delay when exiting into vim normal mode

[echasnovski]

Hello, @randy3k! I wanted to share my problem, its current workaround, and ask for any suggestions and possibilities of new radian settings.

By default, when using "vim" editing mode there is a rather long delay when exiting from insert into normal mode after hitting <Esc> key. It is tolerable if no radian.escape_key_map is defined and long otherwise.

I believe, it is present in order to enable escape_key_map functionality. However, I use those keymappings with <Alt> key so I don't really need any delay when hitting <Esc>. I didn't find any setting in radian which can help with this.

My current workaround is as follows. As radian uses Python's 'prompt_toolkit', there is a way to modify that delay. Currently it is defined by ttimeoutlen and timeoutlen properties of Application class. Their default values are 0.5 and 1 seconds. After experimenting, it seems that delay of 0.5 is "used" when no escape_key_map is defined and 1.5 (0.5+1) otherwise. Inspired by this comment, I implemented the following workaround (which is added to '.radian_profile'):

options(
  radian.editing_mode = "vim",
  radian.on_load_hooks = list(function() {
    getOption("rchitect.py_tools")$attach()

    radian <- import("radian")
    app <- radian$get_app()$session$app

    # Modify timeout lengths (in seconds): time to wait after pressing <Esc>
    # for another key pressing. Very useful to reduce delay when going in
    # Normal mode under "vim" editing mode.
    app$ttimeoutlen <- 0
    # This shouldn't be too small, as it is used when dealing operator sequence
    # in normal mode
    app$timeoutlen  <- 0.25
  })
)

Currently this works for me. Is there any chance of getting "official" radian settings which can help with this issue? The ultimate solution would be two settings: enabling <Alt> key mappings instead of <Esc> and those [t]timeoutlens, but I don't believe both of them are possible, are they?

[randy3k]

I can't believe that you went that far. Yes, your workaround is definitely the fix for the issue. I believe that the recommended value for ttimeoutlen is about 0.05. (This setting is inspired by vim and vim recommends 0.05)

Maybe at some points, we could expose the two settings to users.

[randy3k]

enabling key mappings instead of and those [t]timeoutlens, but I don't believe both of them are possible, are they?

Yes or no. It is not possible based on how common terminal works, alt-<anykey> is usually translated to esc-anykey. But however, in prompt_tookit, it is possible to catch any custom-defined key sequence. So it could be done by instructing your terminal to send a unique sequence to the terminal process when alt+key is pressed. Though, this workaround is not portable.

[echasnovski]

Maybe at some points, we could expose the two settings to users.

If PR is welcome, I can give it a try.

[echasnovski]

As a side note. After working with this for a while, I noticed that those timeouts only affect workflow if there are <Esc> bindings that mimic commonly used Vim commands.

For example, if there is a radian binding <Esc>+p, then one should wait those timeouts after hitting <Esc> (until prompt displays 'nav' mode) to be able to use Vim's 'put' command. On the other hand, if there is no such radian binding, prompt will automatically go into 'nav' mode (even with very big timeouts) and execute Vim's 'put' command.

[randy3k]

Your observation is correct. It is exactly how prompt toolkit handles the key bindings.

[marskar]

@echasnovski, your solution is great. I was going to do something similar to change the cursor shape based on the current vim mode, but I decided to edit the Python code instead of writing an R hook in an option () call. I submitted a PR (#222) that changes both the cursor shape and [t]timeoutlens. You can find more info in the issue (#220) that preceded the PR.