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

<SNR>52_(restore-marks) left in buffer #56

Closed
Asheq opened this issue Sep 24, 2017 · 6 comments
Closed

<SNR>52_(restore-marks) left in buffer #56

Asheq opened this issue Sep 24, 2017 · 6 comments

Comments

@Asheq
Copy link

Asheq commented Sep 24, 2017

Doing any ci[textobject] (for instance cie or cil) leaves <SNR>52_(restore-marks) in the buffer.

Thanks

@Asheq
Copy link
Author

Asheq commented Sep 24, 2017

Perhaps semi-related: I'm noticing that when I specifically do a yie, the '< and '> marks are no longer what they should be if the last visually-selected area was character-wise (i.e. a word)

I really appreciate having this common vim-textobj-user plugin to handle edge cases like this. I know it's not easy to figure out :)

@kana
Copy link
Owner

kana commented Sep 25, 2017

I'll investigate the problems later.

@kana kana closed this as completed in 2950a99 Sep 25, 2017
@kana
Copy link
Owner

kana commented Sep 25, 2017

I've fixed the first problem. I'll look into the second problem later.

@kana
Copy link
Owner

kana commented Sep 25, 2017

I've created a new issue #58 for clarity.

@Asheq
Copy link
Author

Asheq commented Sep 27, 2017

@kana: Thanks for looking into this! I'm noticing that when using the popular surround.vim plugin to do ysi[text-object]", it is not behaving properly anymore when the text object is one created with vim-textobj-user.

For instance, if I start with a buffer that looks like

hello there
hello there

And type ysie, I'm oddly left in insert mode and see:

tore-marks)ello there
hello there

Which looks like part of (Restore-marks). Any ideas?

Thanks again.

@kana
Copy link
Owner

kana commented Sep 28, 2017

Thank you for the report. But it's a separate problem. I'll write further progress at #59

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