{"action":"created","issue":{"url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/1540","labels_url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/1540/labels{/name}","comments_url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/1540/comments","events_url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/1540/events","html_url":"https://github.com/Valloric/YouCompleteMe/pull/1540","id":89018667,"number":1540,"title":"[RFC] Add support for accepting a completion","user":{"login":"wincent","id":7074,"avatar_url":"https://avatars.githubusercontent.com/u/7074?v=3","gravatar_id":"","url":"https://api.github.com/users/wincent","html_url":"https://github.com/wincent","followers_url":"https://api.github.com/users/wincent/followers","following_url":"https://api.github.com/users/wincent/following{/other_user}","gists_url":"https://api.github.com/users/wincent/gists{/gist_id}","starred_url":"https://api.github.com/users/wincent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wincent/subscriptions","organizations_url":"https://api.github.com/users/wincent/orgs","repos_url":"https://api.github.com/users/wincent/repos","events_url":"https://api.github.com/users/wincent/events{/privacy}","received_events_url":"https://api.github.com/users/wincent/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-06-17T13:37:46Z","updated_at":"2015-06-17T23:33:37Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/Valloric/YouCompleteMe/pulls/1540","html_url":"https://github.com/Valloric/YouCompleteMe/pull/1540","diff_url":"https://github.com/Valloric/YouCompleteMe/pull/1540.diff","patch_url":"https://github.com/Valloric/YouCompleteMe/pull/1540.patch"},"body":"This has come up before in a somewhat polemical thread here:\r\n\r\nhttps://github.com/Valloric/YouCompleteMe/issues/232\r\n\r\nThe argument against adding this feature was basically:\r\n\r\n> The keys can be remapped, but this is how it works. There is no accept\r\n> key because it is unnecessary. I am not willing to change YCM to force\r\n> the user to add unnecessary key presses just because \"that's how other\r\n> editors work\".\r\n\r\n(https://github.com/Valloric/YouCompleteMe/issues/232#issuecomment-15934327)\r\n\r\nHowever, I have a use case for the ability to force acceptance of a\r\ncompletion, which is pretty compelling for me personally, and I'll\r\ndetail below and see if others agree.\r\n\r\nAs implemented here, the change shouldn't \"force the user to add\r\nunnecessary key presses\", but it does enable the user to optionally make\r\nuse of the ability to declare a completion as accepted in a way that\r\nmakes working with UltiSnips considerably more pleasant.\r\n\r\nAs explained in great detail here:\r\n\r\nhttps://github.com/SirVer/ultisnips/pull/514#issuecomment-111775399\r\n\r\nI've a long-running grievance with the way YCM and UltiSnips interact\r\nwithin one another when trying to use `<TAB>` for everything (cycling\r\nthrough YCM completions, expanding snippets, and jumping among snippet\r\nplaceholders). When inside a snippet placeholder and a YCM completion is\r\navailable, it's fundamentally ambiguous what you want to do with `<TAB>`\r\nat that point: do you mean to choose a YCM completion, or jump to the\r\nnext placeholder?\r\n\r\nPrior to that pull request, UltiSnips always ended up winning (ie.\r\n`<TAB>` would always mean \"jump to next placeholder\" instead of \"pick\r\nnext YCM completion), which was counterintuitive, because the visibility\r\nof the completion menu of YCM suggests that it is the \"active\" element\r\nand should be the \"focus\" of the `<TAB>` action. The workaround was to\r\ndefine different mappings for YCM and UltiSnips, thus shattering the\r\nunthinkingly-mash-`<TAB>`-for-everything dream.\r\n\r\nWhat that pull request does is add autocommands to UltiSnips that allow\r\npeople who want to invert the prioritization to do so by overriding the\r\n\"inner\" mappings that UltiSnips sets up only for the duration of snippet\r\nexpansion. In this way, you can make YCM completion win inside of\r\nplaceholders whenever it has completions available (ie. when\r\n`pumvisible()`).\r\n\r\nBut there is one small problem. What do you do when you've finished\r\ncycling through your YCM completion options with `<TAB>` and you then\r\n_do_ want to jump to the next placeholder? Once again, we don't want to\r\nhave to define a non-`<TAB>` mapping for jumping between placeholders\r\nbecause of @jordwalke's point:\r\n\r\n> ... the popular mental model of snippets, which usually use `<Tab>`\r\n> for not only expansion, but also jumping between snippet placeholders\r\n> (which has been ingrained in users' muscle memory for thirty years of\r\n> keyboard form filling).\r\n\r\n(https://github.com/Valloric/YouCompleteMe/issues/232#issuecomment-36497678)\r\n\r\nIdeally, you should be able to accept the YCM completion (either with\r\nthe Vim default of `<CTRL-Y>`, or with something else that you deem more\r\ncomfortable, like `<CR>` or any other mapping of your choosing), which\r\nshould dismiss the menu, keep the completion, and free you to hit\r\n`<TAB>` to jump to the next placeholder. If you ever forget about how\r\nthe dual role of `<TAB>` works here and end up mashing it one time to\r\nmany, correction can be a simple `<S-TAB>` (or repeat `<TAB>`) followed\r\nby `<CR>` (away).\r\n\r\nThis commit implements that behavior in a rough way (no tests, just an\r\nRFC at this stage). This is my first incursion into the YCM codebase, so\r\nhopefully I haven't done anything stomach-churningly hacky here. What it\r\ndoes is allow the chosen \"accept completion\" binding to set some\r\ninternal state that hides the completion menu, and then forwards the\r\nnative `<CTRL-Y>` to Vim to \"accept\" the completion. Switching buffers\r\nor moving the cursor resets this internal state, effectively unhiding\r\nthe menu again.\r\n\r\nObviously I'd be happy to include docs, switch defaults, or make other\r\nrequested changes in order to see this or equivalent functionality land\r\nin upstream.\r\n\r\nFor an example of this option in use, see this commit in my dotfiles\r\nrepo:\r\n\r\nhttps://github.com/wincent/wincent/commit/bc6ed079ab148e74b74cb0e7e6c67\r\n\r\nAnd for more context on how it all first together, go back to that\r\nUltiSnips PR that I linked to further up."},"comment":{"url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/comments/112979914","html_url":"https://github.com/Valloric/YouCompleteMe/pull/1540#issuecomment-112979914","issue_url":"https://api.github.com/repos/Valloric/YouCompleteMe/issues/1540","id":112979914,"user":{"login":"Valloric","id":919444,"avatar_url":"https://avatars.githubusercontent.com/u/919444?v=3","gravatar_id":"","url":"https://api.github.com/users/Valloric","html_url":"https://github.com/Valloric","followers_url":"https://api.github.com/users/Valloric/followers","following_url":"https://api.github.com/users/Valloric/following{/other_user}","gists_url":"https://api.github.com/users/Valloric/gists{/gist_id}","starred_url":"https://api.github.com/users/Valloric/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Valloric/subscriptions","organizations_url":"https://api.github.com/users/Valloric/orgs","repos_url":"https://api.github.com/users/Valloric/repos","events_url":"https://api.github.com/users/Valloric/events{/privacy}","received_events_url":"https://api.github.com/users/Valloric/received_events","type":"User","site_admin":false},"created_at":"2015-06-17T23:33:37Z","updated_at":"2015-06-17T23:33:37Z","body":"Hi @wincent, I'm a big fan of Command-T (I use it every day), awesome work there!\r\n\r\nBack to your RFC... it does present a solid reason for why you want to be able to explicitly accept completions; _in a vacuum_, the UltiSnips interaction does seem like a problem worth solving. I'm not philosophically against this change since like you said it's backwards compatible.\r\n\r\nBut the implementation that the PR suggests and IMO most probably any other implementation that would provide the same feature is very complex. Yet more state is being added to the Vimscript layer; there's far too much of it already and it's hard to tell how it all interacts.\r\n\r\nIf I knew how to present the same YCM functionality that is currently present with a less complex vimscript layer without breaking any backwards compatibility, I'd do it. But I don't.\r\n\r\nThis change would add more complexity for a feature that in all honestly doesn't seem to be worth it. We've survived the last few years in YCM with the current menu triggering logic without really any problems. I haven't heard meaningful complaints about it in quite a while, which I'm taking as a sign of it being solid enough.\r\n\r\nIf there were a really low-cost way of implementing this, I probably wouldn't mind. But that strikes me as unfortunately unlikely. "}}