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

Override to avoid using smartcase #14

Open
AlexSWall opened this issue Dec 30, 2022 · 3 comments
Open

Override to avoid using smartcase #14

AlexSWall opened this issue Dec 30, 2022 · 3 comments

Comments

@AlexSWall
Copy link

I like using smartcase for standard searching but am not keen on it for my f (etc.) behaviour, so would like to avoid this. I have ignorecase = false for leap, but I'm still getting the behaviour of ff moving me to the next F.

Is there a way to override this or change this behaviour?

If not, I'm not against submitting a PR to add this functionality if you can point me to where it's occurring in the code and if it's not too complex; I couldn't see it.

@ggandor
Copy link
Owner

ggandor commented Dec 30, 2022

I have ignorecase = false for leap

Flit uses Leap's search function (get-match-positions), but feeds it with its own pattern, so Leap's setting is irrelevant here. (The option name is case_sensitive btw.)

Replace '\\V' with '\\V\\C' here, to force case sensitivity:

return '\\V' .. (kwargs.multiline == false and '\\%.l' or '') .. input

If not, I'm not against submitting a PR to add this functionality

The problem is not the implementation, but we'd need to decide on the API then. (Just an ignorecase flag? One for forcing smartcase too? An additional one to follow vim.o.ignorecase|smartcase? There are many possible combinations.)

@AlexSWall
Copy link
Author

Makes sense. Thanks for pointing me to the right place.

There could be two flags, one for ignorecase and one for smartcase, with true and false values setting the value as an override and nil defaulting to vim.opt values?

@AlexSWall
Copy link
Author

@ggandor If you give the thumbs up on this API, I'm happy to look into throwing in a PR. I just want to avoid putting in the effort if you wouldn't be happy with the solution.

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