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

Add an option to disable the Telescope preview #92

Closed
soywod opened this issue Apr 11, 2021 · 7 comments · Fixed by #97
Closed

Add an option to disable the Telescope preview #92

soywod opened this issue Apr 11, 2021 · 7 comments · Fixed by #97

Comments

@soywod
Copy link
Member

soywod commented Apr 11, 2021

The preview in unusable when Himalaya connects to a remote IMAP server (delay between searches are insane). We need to find a way to disable this feature with a flag.

@AckslD
Copy link
Contributor

AckslD commented Apr 12, 2021

Sounds good @soywod! How would you prefer to configure this? I don't see if there are already configuration options. For example we could have the user set the global value g:himalaya_enable_telescope_preview (vim.g.himalaya_enable_telescope_preview for neovim). Perhaps having if off by default is better than on? Furthermore, maybe the user could also then choose the preferred way of searching, i.e. telescope, fzf or through direct choice. What do you think?

Maybe while doing this it would also be good to add an option for if the default keybindings should be configured or not?

@soywod
Copy link
Member Author

soywod commented Apr 12, 2021

Sounds great! I would name it sth like g:himalaya_telescope_preview_enabled since it's a flag. An other option for choosing the search provider is also great. It's not a priority, but if you feel motivated for, feel free to propose 😃

Maybe while doing this it would also be good to add an option for if the default keybindings should be configured or not?

I'm not sure to understand this last one. If you talk about keybinds in general then it's already configurable. See https://github.com/soywod/himalaya/tree/master/vim. For example to change the default gm keybind, you can do sth like nmap <leader>m <plug>(himalaya-mbox-input). If you talk about one different keybind by search engine then I think it's too much. Usually, when you use a certain search engine, you want to use it all the time. I don't see a use case where you use this X search engine for on task and the Y one for other tasks.

@AckslD
Copy link
Contributor

AckslD commented Apr 12, 2021

Cool! I'll make an attempt to add this and share it to see what you think.

What I meant regarding keybinds is that currently the default keybindings are always configured, even if you set nmap <leader>m <plug>(himalaya-mbox-input) you will still have nmap gm <plug>(himalaya-mbox-input), which someone might not want. Unless I've gotten this wrong. So maybe it's nice to have e.g. g:himalaya_default_keybinds_disabled. This is separate from the above issue though :)

@soywod
Copy link
Member Author

soywod commented Apr 12, 2021

even if you set nmap <leader>m <plug>(himalaya-mbox-input) you will still have nmap gm <plug>(himalaya-mbox-input)

I think this is a bug, it should override the default one. I did on purpose to avoid having a keybinds variable. I will investigate this point.

@AckslD
Copy link
Contributor

AckslD commented Apr 12, 2021

I haven't actually tried this but thought this was the case by looking at the code since if the code does e.g. nmap lhs1 rhs1 and the user then does nmap lhs2 rhs1 it does not remove the mapping of lhs1 which would only be overridden if the user did nmap lhs1 rhs2 which is something else. But I might be misunderstanding something.

@soywod
Copy link
Member Author

soywod commented Apr 12, 2021

I just tried, I confirm that it overrides well the default mapping. It's because I declared a special mapping <plug>, see :h <plug>. So we can forget this last point 😉

@AckslD
Copy link
Contributor

AckslD commented Apr 12, 2021

Ooh, didn't know that <plug> worked like that :) Sorry for the confusion!

@soywod soywod self-assigned this Apr 17, 2021
@soywod soywod added this to the v1 milestone Apr 17, 2021
@soywod soywod removed their assignment Feb 11, 2022
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

Successfully merging a pull request may close this issue.

2 participants