lervag / vimtex

VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
MIT License
5.42k stars 389 forks source link

Command Completion Case Sensitivity #1250

Closed Rahlir closed 5 years ago

Rahlir commented 5 years ago

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)?

  1. A concise description of the issue and the steps to reproduce it:

Using completion on

\uparr<CTRL-X><CTRL-O>

yields options \Uparrow and \uparrow. I wish there was an ability to just suggest \uparrow

lervag commented 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.

lervag commented 5 years ago

See also #794, which motivated the case insensitive version that is implemented now.

kiryph commented 5 years ago

@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).

lervag commented 5 years ago

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?

kiryph commented 5 years ago

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.

  1. deoplete disables filtering for omni_patterns:
                    *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.
  1. YCM, ncm2: Since I do not use YCM or ncm2 and I could not find an explicit answer in their respective docs, I cannot answer this question. For example YCM lists in general:
    
    General (all languages) ~

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.

BREAKING CHANGE FOR DEOPLETE SETUP IN 2018

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.

Rahlir commented 5 years ago

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.

lervag commented 5 years ago

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.

lervag commented 5 years ago

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!

Rahlir commented 5 years ago

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.

lervag commented 5 years ago

Great, happy to hear it! :)