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

Error after sourcing vimrc when g:targets_nl is set #257

Open
victorkristof opened this issue Sep 2, 2020 · 1 comment
Open

Error after sourcing vimrc when g:targets_nl is set #257

victorkristof opened this issue Sep 2, 2020 · 1 comment

Comments

@victorkristof
Copy link

Hi there,

Thank for the great plugin!

After I source my vimrc, targets.vim gets some errors for operations on i{text-obj} and a{text-obj} (e.g., diw):

Error detected while processing function targets#e:
line    6:
E714: List required
Error detected while processing function targets#e:
line   12:
E121: Undefined variable: nKeys
Error detected while processing function targets#e:
line   19:
E121: Undefined variable: lKeys
Error detected while processing function targets#e:
line   26:
E121: Undefined variable: nKeys
Error detected while processing function targets#e:
line   26:
E116: Invalid arguments for function s:hasPrefix(nKeys, pending) || s:hasPrefix(lKeys, pending)

This is how I configured the plugin in my vimrc:

let g:targets_nl = 'nN'

When removing this line, the error disappears.

@victorkristof victorkristof changed the title Error after sourcing vimrc Error after sourcing vimrc when g:targets_nl is set Sep 2, 2020
@rgreenblatt
Copy link

rgreenblatt commented Apr 23, 2021

targets.vim changes the value of g:targets_nl to be a list when it is loaded. In this case, that list is ['n', 'N'].
So, if you reset the variable to a string after it is loaded, that results in the error E714: List required.
As a workaround, you can instead use

let g:targets_nl = ['n', 'N']

If you always set it to be a list, then the issue doesn't occur.

IMO, this is still a bug with targets.vim, it really should just do the conversion each time. I would have to imagine that any speed up from doing the conversion once would be premature optimization.

I will probably make a PR to fix this in a sec

rgreenblatt added a commit to rgreenblatt/dotfiles that referenced this issue Apr 23, 2021
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

2 participants