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

Chain YCM's insert-mode mappings with any existing mapping (or only define unique mappings for insert mode) [Feature Request] #4127

Open
12 tasks done
excited-bore opened this issue Feb 8, 2023 · 6 comments
Labels
enhancement PR Welcome A good quality PR for this feature would be considered.

Comments

@excited-bore
Copy link

Issue Prelude

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your issue:

  • I have read and understood YCM's CONTRIBUTING document.
  • I have read and understood YCM's CODE_OF_CONDUCT document.
  • I have read and understood YCM's README, especially the
    Frequently Asked Questions section.
  • I have searched YCM's issue tracker to find issues similar to the one I'm
    about to report and couldn't find an answer to my problem. (Example Google
    search.
    )
  • If filing a bug report, I have included the output of vim --version.
  • If filing a bug report, I have included the output of :YcmDebugInfo.
  • If filing a bug report, I have attached the contents of the logfiles using
    the :YcmToggleLogs command.
  • If filing a bug report, I have included which OS (including specific OS
    version) I am using.
  • If filing a bug report, I have included a minimal test case that reproduces
    my issue, using vim -Nu /path/to/YCM/vimrc_ycm_minimal, including what I
    expected to happen and what actually happened.
  • If filing a installation failure report, I have included the entire output
    of install.py (or cmake/make/ninja) including its invocation
  • I understand this is an open-source project staffed by volunteers and
    that any help I receive is a selfless, heartfelt gift of their free time. I
    know I am not entitled to anything and will be polite and courteous.
  • I understand my issue may be closed if it becomes obvious I didn't
    actually perform all of these steps.

Thank you for adhering to this process! It ensures your issue is resolved
quickly and that neither your nor our time is needlessly wasted.

Issue Details

Provide a clear description of the problem, including the following key
questions:

  • What did you do?

Include steps to reproduce here.

  1. `vim .config/nvim/init.vim'
  2. inoremap <Up> <Up><C-o>zz
  3. Enter insert mode and type go up, but without recentering

Include description of a minimal test case, including any actual code required
to reproduce the issue.

If you made changes to vimrc_ycm_minimal, paste them here:

inoremap <Up> <Up><C-o>zz

  • What did you expect to happen?

It doesn't really matter. All that matters is that i rebound a key that YCM already binds

I just have suggestion how rebinding keys that YCM already use might become less off an issue:
: in ~/.config/bundle/YouCompleteMe/autoload/youcompleteme.vim , line 349, 354 and 361, in that order:
exe 'lnoremap <expr>' . key . ' pumvisible() ? "\<C-n>" : "\' . key .'"'
exe 'lnoremap <expr>' . key . ' pumvisible() ? "\<C-p>" : "\' . key .'"'
exe 'lnoremap <expr>' . key . ' <SID>StopCompletion( "\' . key . '" )'

instead of their respective inoremap variants

in :h modes
lnoremap png

When keys YCM uses keys that get rebound by user for insert mode, they stop working for YCM, instead of getting rebound and breaking whatever gets rebound in the userconfig. Seems like the more appropriate kind of breaking

  • What actually happened?

It didn't recenter

Diagnostic data

Output of vim --version

Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Output of YcmDebugInfo

Printing YouCompleteMe debug information...
-- Resolve completions: Up front                                                                                                                                                                           
-- Client logfile: /tmp/ycm_jszpbsqk.log
-- Server Python interpreter: /usr/bin/python3
-- Server Python version: 3.10.9
-- Server has Clang support compiled in: True
-- Clang version: clang version 15.0.1 (https://github.com/ycm-core/llvm 708056a3d8259ce1d9fc0f15676d13b53cc23835)
-- No extra configuration file found
-- Server running at: http://127.0.0.1:38045
-- Server process ID: 45931
-- Server logfiles:
--   /tmp/ycmd_38045_stdout_89aeor9p.log
--   /tmp/ycmd_38045_stderr_1jq7iuru.log
-- Semantic highlighting supported: False
-- Virtual text supported: False
-- Popup windows supported: False

Output of YcmDiags

Native filetype completion not supported for current file, cannot force recompilation

Output of git rev-parse HEAD in YouCompleteMe installation directory

50379d35ddc38ee3651f568d080442d5e4cb4a3a

Contents of YCM, ycmd and completion engine logfiles

Reproduce the issue with vim -Nu /path/to/YCM/vimrc_ycm_minimal, which
enabled debug logging and other useful diagnostics. Include a link to a
gist containing all of the log files listed by :YcmToggleLogs.

OS version, distribution, etc.

Include system information here.

██████████████████  ████████   user@mybuild 
██████████████████  ████████   ---------------- 
██████████████████  ████████   OS: Manjaro Linux x86_64 
██████████████████  ████████   Host: X570S AORUS PRO AX -CF 
████████            ████████   Kernel: 5.15.91-1-MANJARO 
████████  ████████  ████████   Uptime: 2 hours, 18 mins 
████████  ████████  ████████   Packages: 2133 (pacman) 
████████  ████████  ████████   Shell: bash 5.1.16 
████████  ████████  ████████   Resolution: 1920x1080, 1920x1080 
████████  ████████  ████████   DE: Xfce 4.18 
████████  ████████  ████████   WM: Xfwm4 
████████  ████████  ████████   WM Theme: Matcha-sea 
████████  ████████  ████████   Theme: Adwaita-dark [GTK2/3] 
████████  ████████  ████████   Icons: Papirus-Maia [GTK2], Adwaita [GTK3] 
                               Terminal: kitty 
                               CPU: AMD Ryzen 5 3400G (8) @ 3.700GHz 
                               GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
                               GPU: NVIDIA GeForce GTX 1070 
                               Memory: 4875MiB / 29973MiB 

                                                       
                                                       

Output of build/install commands

Include link to a gist containing the invocation and entire output of
install.py if reporting an installation issue.

@puremourning
Copy link
Member

Sorry I don't understand exactly what bug you're reporting.

I think you're saying that you've remapped <Up> in insert mode to do something other than the default, then you've set g:ycm_key_list_previous_completion to include <Up> (or left it as the default value) and your complaint is that YCM overrides your mapping?

Unfortunately it's not really possible to chain mappings in a convenient and robust way. I suggest you just remove <Up> from g:ycm_key_list_previous_completion, or add some invented mapping (such as <Plug>YcmUP) to it and adjust your mapping to output the <Plug>YcmUp sequence.

@excited-bore
Copy link
Author

To elaborate:
Yes, chaining off mapping doesn't become easier with this. Debugging does.
My problem was that it looked at first glance that i just mapped inoremap <up> poorly, while in fact it just got overwritten by YCM. It doesn't help that this still occurs even if you made sure your config loads after your plugins do.
The likelihood of breaking user defined mappings gets lowered since most people that use mapping usually gravitate to nnoremap, inoremap or vnoremap, wich also get priority by vim/nvim over mappings made by lnoremap

@puremourning
Copy link
Member

lnorenap is incorrect, because YCM's mappings should only apply in insert mode, so I don't get why you're suggesting that?

@puremourning
Copy link
Member

if your ask is "only set the mapping if there isn't already a mapping for that key", then we can do that with inoremap <unique> but you then have a conflict in your config which YCM is trying to work around. I'm not sure if that will break some existing user.

@excited-bore
Copy link
Author

excited-bore commented Feb 8, 2023

Userconfig would break, but only for the YCM side. Like if there were remappings with keys (f.ex. inoremap <Up>) YCM uses, mappings that YCM wouldn't overwrite any longer would suddenly take effect. But fair enough.

@puremourning puremourning changed the title Suggestion for YCM rebinds using inoremap Chain YCM's insert-mode mappings with any existing mapping (or only define unique mappings for insert mode) [Feature Request] Feb 8, 2023
@puremourning
Copy link
Member

This is quite fiddly to implement correctly, and has been working this way for a very long time with no complaints, so while I acknowledge your concern, I'm not sure that it's going to be high on my priority list. I would consider high quality PR using maparg or proper use of unique mappings including appropriate tests though.

@puremourning puremourning added enhancement PR Welcome A good quality PR for this feature would be considered. labels Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement PR Welcome A good quality PR for this feature would be considered.
Projects
None yet
Development

No branches or pull requests

2 participants