How do I debug normal/insert/cart mode shortcuts that don't behave as expected?

Question

I am using exactly the same version of Vim (Gvim 8.0.1123) across all my Windows machines, and only have the following problem on one of them:

Problem

That I cannot use <c-d> in insert-mode, to decrease the indentation level of the currently edited line. <c-t> does still work for increasing the indentation level.

On this particular Windows machine (Windows 10 Pro), I have tried to uninstall and reinstall Gvim.exe for a few times, and the problem is consistent;
And, <c-d> fails to take effect regardless of the filetypes.
I have tried to use a :Listmaps function (from Plug-in vim-scripts/listmaps.vim), but do not find anything thing special for <c-d> mapping.

Environment

Across all the Windows machines that I have, I should have had almost everything identical: same Gvim distribution (installed from the same *.exe file), same _vimrc: all sourcing settings from a common Dropbox folder and same directory structure etc.

Interesting observation

According to the standard Vim debugging protocol, I shall first try to start Vim (or Gvim) afresh, with no .vimrc (or _vimrc loaded at all). I have tried both of the following:

vim -u NONE -U NONE -N
gvim -u NONE -U NONE -N

While I am not confident that when I open vim in the Windows Command Prompt, key-code representing the <c-d> mapping is passed to the Vim process or not, it is interesting to observe that, the Gvim process started afresh shall have the same problem: <c-d> does not decrease the level of indentation. I think things are only getting more interesting for now.

@Mass: For filetypes that have <c-d> mapped, the :verbose command shows exactly the same mapping; and for filetypes that does not have <c-d> mapped, the :verbose command shows "No mapping found". I was thinking that there might be a third party thing that occupies <c-d> permanently. However, <c-d> works just fine in Normal mode. It is just failing in Insert-mode. — llinfeng, Oct 16 '17 at 20:17
Voting to close because the problem turned out to be unrelated to Vim, and the symptoms described turned out to be happenstance. — Rich, Oct 17 '17 at 21:15
@Rich, I totally agree with what you said; but I would instead like to have this post kept. When I was doing my search, I did not hit anything that turned out to be "happenstance". Also, I have hesitated when deciding which forum to put this question. [Please correct me if I am wrong, that "close" means wiping out everything in this post.] — llinfeng, Oct 17 '17 at 23:37
I'm inclined to vote "close", too. Looking at it from the perspective of future answer seekers there's not much value. Perhaps if the question was recast as a general "How do I debug normal mode commands/keys that don't behave as expected?" question (if there isn't already an entry along those lines)... — B Layer, Oct 18 '17 at 03:44
@llinfeng No, don't worry: closing the question doesn't mean it's deleted. It just gives future readers an indication that there's something unusual about the question. They'll still be able to read the question and the existing answers if they so desire. (But they won't be able to add new answers.) — Rich, Oct 18 '17 at 06:45
Oh, I see. Let me recast the name as @BLayer proposed. [Not sure how to "close" it on my end, though. Shall I also vote up your comment on closing?] — llinfeng, Oct 18 '17 at 13:27

score 1 · Answer 1 · answered Oct 17 '17 at 15:01

1

If your problem only happens in insert mode, then it is clear that Vim sees the key combination.

Despite you use the same _vimrc file, it might be checking for some environment variable that is different in that specific machine. In any case, as it is related to your Vim configuration, you should follow the procedure in "How do I debug my vimrc file?" (or the procedure at Vim faq-2.5). It will allow you to find which line on your _vimrc or plugin triggers the problem.

answered Oct 17 '17 at 15:01

mMontu

6,630
21
31

It is surprising that, even when I open the gvim.exe as follows: gvim -u NONE -U NONE -N, pressing<c-d> is still not doing anything in Insert mode. And, <c-t> works just fine. (I am remotely accessing the "problematic machine" for now, and let me cross-check to see if Windows RDP connection should be at fault.) – llinfeng Oct 17 '17 at 18:26
I checked through my laptop, remotely accessing the problematic machine (home PC) still have the same <c-d> issue; yet, remotely accessing the machine in my office (office PC) does not encounter a <c-d> issue. – llinfeng Oct 17 '17 at 18:34

score 0 · Answer 2 · answered Oct 17 '17 at 18:53

Third-party application has "stolen" the `<c-d>` mapping.

My particular problem is caused by a third-party application that fails to occupy the key-mapping of <c-d> all the time. For example:

At times, such third-party application shall lose control over the <c-d> mapping completely. Per my previous testing, it happens to be when I was testing the <c-d> mapping in Normal mode.
Also, AutoHotKey, an auto-script tool that handles key-mappings very well, is able to override the mapping of <c-d> at the system level

Uninstalling the third-party application solves the problem.

Takeaway

When claiming that a certain key-binding is not working for Vim, one would like to test multiple times, across multiple modes (Normal, Insert, Visual, etc). This shall help to identify whether it is an internal problem with Vim, or should it be an OS-wide problem: a third-party application is occupying the shortcut.

Also, when one is replicating his/her Vim distribution across multiple machines (and/or different operating systems), check if the same problem is occurring on any other machine/system. If the bug/problem is still specific to one of the machines, then, there is a high probability that a third-party application is causing the particular problem.

Credits:

I would like to give credits in solving this question to @mMontu, who pointed out correctly, that one shall follow the debugging procedure: "How do I debug my vimrc file?"