Closed Rahlir closed 5 years ago
Thanks, I agree that case sensitive is a more sensible default. I'd like to hear what @kiryph thinks: If he also agrees, then I'll avoid the extra option. Else I'll add a new option.
See also #794, which motivated the case insensitive version that is implemented now.
@lervag Thank you for notifying me about this issue. Indeed, I'd like to share my thoughts 😃:
My original motivation for raising the issue #794 is unchanged.
May I mention at first one proposal: change the sort order to lowercase before uppercase so that \uparrow
becomes the first candidate.
I also want to add a little bit more context:
LaTeX is case sensitive and therefore the request by @Rahlir is certainly very well motivated.
Also vim's option 'infercase'
for ins-completion
is nothing I think is a good idea to use for LaTeX commands.
However 😄, I have enabled in my vimrc 'ignorecase'
and 'smartcase'
.
For the given example \uparr<CTRL-X><CTRL-O>
this means I would like to see both candidates \Uparrow
and \uparrow
and if I would have typed \Uparr<CTRL-X><CTRL-O>
only \Uparrow
.
'ignorecase'
and 'smartcase'
are not enabled by default in vim and not everyone has changed them in his/her vimrc. For example, they are also not indefaults.vim
or vim-sensible
but in https://github.com/rstacruz/vim-opinion. So I am not surprised that others have a different opinion about whether candidate filtering should be (smart) case sensitive or not.
But I am also not alone with my point of view: the popular YouCompleteMe plugin works as I would expect it:
Filtering is "smart-case" and "smart-diacritic" sensitive; if you are typing only lowercase letters, then it's case-insensitive. If your input contains uppercase letters, then the uppercase letters in your query must match uppercase letters in the completion strings (the lowercase letters still match both). On top of that, a letter with no diacritic marks will match that letter with or without marks:
https://github.com/Valloric/YouCompleteMe#general-usage
I think deoplete's default behavior and customization possibility is optimal
*deoplete-options-smart_case*
smart_case
When a capital letter is included in input, deoplete does
not ignore the upper- and lowercase.
Default value: same with your 'smartcase' value
*deoplete-options-ignore_case*
ignore_case
If it is True, deoplete ignores case.
Default value: same with your 'ignorecase' value
I would argue that the filtering should be left to an installed autocompletion plugin (if used) and following its style, e.g. as mentioned ycm's smartcase, deoplete following your setting of ignorecase/smartcase or dedicated deoplete options. This means doing it already in vimtex would not allow this.
If I can vote, I would be in favour of following the example of deoplete.
If you want to avoid additional options, I would root for adjusting the sorting to improve the situation for @Rahlir and also satisfies users like me (or YCM expectations).
Thanks for the input, @kiryph. Can you confirm that I understand this correctly: Autocomplete plugins like deoplete, ncm2, etc, prefer that omnicomplete plugins do not filter the complete candidates, because they want to filter the output themselves.
If I understand correctly, then I suggest adding the following options:
*g:vimtex_complete_unfiltered*
If this option is enabled, then the omnicomplete function will not do any
filtering of candidates. This is appropriate when one uses an autocomplete
plugin like neocomplete, deoplete, YouCompleteMe, or ncm2.
Default value: 0
*g:vimtex_complete_smart_case*
If enabled, then vimtex will filter case sensitive if there is a capital
letter in the completion input. This is only relevant if
|g:vimtex_complete_ignore_case| is also enabled.
Default value: Same as your 'smartcase' value
*g:vimtex_complete_ignore_case*
If enabled, then vimtex will filter case insensitive.
Default value: Same as your 'ignorecase' value
I will also update the section on autocompletions by adding the unfiltered option to the setups. Do you agree?
Can you confirm that I understand this correctly: Autocomplete plugins like deoplete, ncm2, etc, prefer that omnicomplete plugins do not filter the complete candidates, because they want to filter the output themselves.
Sorry I was overhasty. My mistake.
*deoplete-options-omni_patterns*
omni_patterns
If omni_patterns is set, deoplete will call 'omnifunc'
directly as soon as a pattern is matched.
Note: This will disable deoplete filtering and combination of
sources for those matches.
General (all languages) ~
This could mean that the `Intelligent suggestion ranking and filtering` is applied to all candidates. But it is not entirely clear.
Also for ncm2, omnifuncs are registered similarly as other sources, but it is not clear if filtering is disabled for certain reasons such as performance.
I guess one would have to ask on github or install and verify manually those which are mentioned in the docs (ycm, ncm2, nvim-completion-manager, neocomplete). Do you use a different one than deoplete?
VimCompletesMe
does no filtering and therefore users who want filtering rely on vimtex.
However, there was an important change in deoplete this year: deoplete has removed the variable g:deoplete#omni#input_patterns
. The vimtex doc is now outdated:
deoplete~
*vimtex-complete-deoplete*
|deoplete| is a modern remake of |neocomplete|, and was originally written
specifically for Neovim, see here: https://github.com/Shougo/deoplete.nvim. It
is a highly customizable and flexible completion manager.
To configure for `vimtex`, one may use: >
if !exists('g:deoplete#omni#input_patterns')
let g:deoplete#omni#input_patterns = {}
endif
let g:deoplete#omni#input_patterns.tex = g:vimtex#re#deoplete
This should be now something like
call deoplete#custom#var('omni', 'input_patterns', {
\ 'tex': g:vimtex#re#deoplete
\})
Back to the actual issue:
As a first step I would go with *g:vimtex_complete_smart_case*
and *g:vimtex_complete_smart_case*
. If YCM does indeed a filtering of omni candidates, I would consider this as a new issue and postpone it until someone notices a discrepancy between his expectations of YCM filtering of different sources.
Since I am not using any of the autocomplete plugins, I cannot comment on that. But I wanted to mention why in my case I have preference for case sensitive completion and why adjusting the sort order as mentioned above wouldn't work for me.
I am using the longest completeopt as I am used to this in the various other environments I work in. The problem arises whenever the omnicomplete throws at me suggestions that include different case commands, since vim then deletes the whole item I have written and I have to select the completion manually instead of just writing out bigger portion of the command.
Hence, if I understand it correctly, the proposed additions by @lervag:
*g:vimtex_complete_unfiltered*
If this option is enabled, then the omnicomplete function will not do any
filtering of candidates. This is appropriate when one uses an autocomplete
plugin like neocomplete, deoplete, YouCompleteMe, or ncm2.
Default value: 0
*g:vimtex_complete_smart_case*
If enabled, then vimtex will filter case sensitive if there is a capital
letter in the completion input. This is only relevant if
|g:vimtex_complete_ignore_case| is also enabled.
Default value: Same as your 'smartcase' value
*g:vimtex_complete_ignore_case*
If enabled, then vimtex will filter case insensitive.
Default value: Same as your 'ignorecase' value
should solve my problem by allowing me to have all the three options disabled.
Hopefully this makes sense. As far as I am aware, there is no option to have longest completeopt that preserves the text even though some of the proposed completions differ in case. Let me know if I am mistaken, since then sorting the completions would indeed solve all the headaches of case sensitivity.
Nevertheless, it seems like you have already decided on adding the two options to vimtex, which is the most flexible solution in my opinion.
Thanks for the input. In light of "if it ain't wrong, don't fix it", I'll not go more into depth on the suggested option g:vimtex_complete_unfiltered
at this time, and as @kiryph suggests, I'll rather look into it if someone should complain that there is an unexpected behaviour.
It also seems that I'll solve this issue by adding two options for determining completion behaviour as suggested. I'll look into implementing this when I get the time.
Ok, I think this should do it. I've now made the completion consistent, i.e. the various completion types have the same level of case sensitiveness.
Let me know what you think!
Sorry to be late on this.
Works great for my use case and the docs for the added options are pretty clear! Thank you for adding this so quickly.
Great, happy to hear it! :)
Command Completion Case Sensitivity
(Perhaps a feature request)
I am not sure if this still counts as an issue, but I was just wondering why there is no setting for case sensitivity in completion of commands. Searching for a while in this repository I found that the switch from case sensitive to case insensitive completion was done in commit c6967b0. It is simple enough to change this back to sensitive completion, which I have done for myself since it suits me better. Is there a reason there is no option for this (besides hard coding vimtex back to case sensitive completion)? Would you mind adding the ability to switch case sensitivity as an option (perhaps I could create the pull request)?
Using completion on
yields options
\Uparrow
and\uparrow
. I wish there was an ability to just suggest\uparrow