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

nvim_oxi::api::types::Mode doesn't allow for Remap ("m") mode #128

Open
turboladen opened this issue Jan 30, 2024 · 2 comments
Open

nvim_oxi::api::types::Mode doesn't allow for Remap ("m") mode #128

turboladen opened this issue Jan 30, 2024 · 2 comments

Comments

@turboladen
Copy link

I think I remember running into a similar question when working on turboladen/overkill_nvim and stopped working on it (because this project emerged!)... I see that nvim_oxi::api::types::Mode doesn't have a variant that maps to "m", which I'm wanting to pass to feedkeys() (playing around with InsertCharPre autocompletion). Is it possible I'm looking at the wrong type?

If I have some time, I'd be up for making a PR for this, but I'm not sure if it'd make sense to include Remap/"m" with the existing Mode enum; it looks like feedkeys() modes are slightly different from regular ol' vim modes. I could see an argument for including Remap in the Mode enum; I could see an argument for a separate feedkeys-specific enum; and I could maybe even see a case for adding a Other(String) variant that let users cover cases that the API missed (for whatever reason--maybe even to allow for accommodating future nvim changes?) (this last case is probably kinda weak compared to the other two options, IMO, but still). What are your thoughts about where this should live?

@noib3
Copy link
Owner

noib3 commented Feb 2, 2024

My understanding is that feedkeys()'s modes don't have much to do with vim modes, apart from sharing some character flags. Is that correct? If so, I think creating a separate enum would make the most sense.

@turboladen
Copy link
Author

feedkeys()'s modes don't have much to do with vim modes, apart from sharing some character flags. Is that correct?

That's my understanding too. I have a fork with a new enum that I'm testing now. If it seems good, I'll put up a PR.

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