Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alt maps break macros and mappings that use <esc> + char #13

Open
bruno- opened this issue Apr 8, 2014 · 15 comments
Open

Alt maps break macros and mappings that use <esc> + char #13

bruno- opened this issue Apr 8, 2014 · 15 comments

Comments

@bruno-
Copy link

bruno- commented Apr 8, 2014

Hi,
for the past week or so I was obsessed with setting up Alt mappings for all the possible keys based on the example provided in vim-rsi. I digged the idea of being able to use Alt as another modifier key. I even created a plugin that enables that (it's a work in progress, but I probably won't bother to finalize it).

Since then, I've learned that setting up alt mappings breaks 2 other things:

  • regular mappings that use esc + character and
  • macros that have esc + char

Here's how the issues can be reproduced in vim-rsi:

  • the following macro doesn't work istuff^[f.astuff^[. f. does not do what it should because ^[ + f is recognized as
  • this mapping does not work imap <C-s> <Esc>ddi (this example is obviously made up)

Basically, anytime <Esc> + b, d, f, n or p (alt mappings from vim-rsi) is executed in a macro or a mapping, I think it won't work. And it will be dang hard to debug why.

For me personally, the biggest issue are f and n because they are used all to often in macros.

Not sure if there's any solution to this, but I hope bringing this up helps.

@tpope
Copy link
Owner

tpope commented Apr 8, 2014

Huh, didn't think about that. Is it true of noremap as well?

@bruno-
Copy link
Author

bruno- commented Apr 9, 2014

Good thinking - so inoremap <C-s> <Esc>ddi seems to work properly (no side-effects when vim.rsi is loaded).

@bohrshaw
Copy link

bohrshaw commented Jan 3, 2015

@bruno- I also ran into this issue and haven't found a way to avoid macro disruption while keeping meta/alt chords mapped. But there are some circumventions like executing the macro using normal! or escaping using <C-C>. You could find more details in my codes.

@dkasak
Copy link

dkasak commented Apr 24, 2015

Just ran into this myself. If there is no solution, perhaps a short note in the README.md would be a good idea?

@acornejo
Copy link

same here, noticed that my macros were broken, and after a binary search through all the plugins, disabling vim-rsi made it work.

@justinmk
Copy link
Contributor

Note that Neovim doesn't have the meta-macro problem mentioned here. If rsi.vim decides to disable this, I suggest making it conditional on has("nvim").

@acornejo
Copy link

rsi already has a flag to disable this, so that works (and its fine for nvim, since folks can do has("nvim") in their vimrc if they want to set that flag conditionally).

what would be cool is if we could get vim-rsi meta bindings in vanilla vim (although I guess I might as well switch to neovim already...)

@justinmk
Copy link
Contributor

rsi already has a flag to disable this

Ok, but presumably the intention of this issue is to suggest that the meta-maps be disabled by default. They should not be disabled for Neovim.

@bruno-
Copy link
Author

bruno- commented Jul 17, 2015

Hey,
the issue was open quite some time ago when disabling meta mappings wasn't possible.

Meta maps in vim-rsi are defined and work for a) insert and b) command line modes. The issue with macros happens only for a) insert mode.
Having the meta maps defined for command line mode is fine. I don't think there's a reason a user would want to disable these.

Maybe the best approach would be:

  • keep command line meta maps always on (no downsides)
  • make insert mode meta maps disabled by default (fixes this issue)

[blatant promotion of another plugin - feel free to delete if it's a problem]
I wanted to make some more contributions to vim-rsi but eventually ended up creating vim-husk. It's focused just on vim's command line so this problem is not an issue there. Apart from the idea, I straight up copied a couple things from vim-rsi (credit given).

@tpope
Copy link
Owner

tpope commented Jul 17, 2015

I'm still not clear on why noremap isn't the solution?

@acornejo
Copy link

@tpope noremap fixes the problem of not being able to map keys to things that use <Esc><somechar>

But AFAIK, it doesn't help to make macros work, in particular macros where you use <Esc><any_char_bound_by_meta_with_rsi>are broken.

I am happy to provide a simple broken macro example if it helps, it turns out these macros happen a lot, since for instance you might want to edit some text, then leave insert mode (<Esc>) and then go to the beginning of the word (b), but since M-b is used by vim-rsi, the macro will be corrupt.

@tpope
Copy link
Owner

tpope commented Jul 17, 2015

Oh, bleh, didn't catch the part about macros. I guess nuking the insert mode mappings entirely would be fine.

djjcast added a commit to djjcast/vim-rsi that referenced this issue Dec 12, 2015
Closes tpope#13

The CursorHoldI event isn't triggered during macro execution, even when
updatetime is set to zero. We can use this 'feature' to create mappings
on the CursorHoldI event only when the user manually enters Insert mode.
@louwers
Copy link

louwers commented Feb 5, 2017

I just disabled all my plugins one by one to find out which one was messing with macros.

Why hasn't #30 been accepted yet?

@jsit
Copy link

jsit commented Feb 27, 2017

Same issue here. Nuking the insert mode mappings doesn't seem to do the trick, as @tpope suggested. Instead, it's lines 57-58 that seem to be causing the issue for me:

  silent! exe "set <S-Left>=\<Esc>b"
  silent! exe "set <S-Right>=\<Esc>f"

My macro register:

dttf(s: ^[f)x

Any suggestions?

@louwers
Copy link

louwers commented Feb 27, 2017

Try the pull request @jsit; it worked for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants