Description of problem: Vim has recently started behaving strangely when my terminal loses focus with 'set compatible'. When I'm in insert mode and move to a different window to select some text to paste in, vim exits insert mode. Somehow it still allows the text to be pasted in but it remains in normal mode so I can't just carry on typing. This is wreaking havoc on my normal workflow. Version-Release number of selected component (if applicable): vim-enhanced-8.2.2541-1.fc33.x86_64 Why isn't vim-enhanced available as a component in Bugzilla? I've selected the component 'vim', which claims to be for GVim. I'm NOT using GVim. How reproducible: Very. Steps to Reproduce: 1. Start vi without a custom .vimrc 2. Enter compatibility mode: ':set compatible' 3. Enter insert mode and type some text 4. Shift focus to a different window: vim exits insert mode Additional info: This happened between version 8.2.1770-1.fc33 and 8.2.2541-1.fc33. I'd bisect it more thoroughly but the mirrors only have the latest version.
I've bisected the issue by building from source. The commit that enables the strange behaviour is 681fc3fa7 (patch 8.2.2345: no focus events in a terminal). I think this means the first affected Fedora package is 8.2.2465-1.fc33. The commit message says handling of focus events in the terminal can be disabled with 'set t_fd=' and 'set t_fe='. I've put these in my .vimrc and the problem has gone away. What I haven't been able to figure out is: - where the strange behaviour is implemented; - why it only affects the Fedora package when 'set compatible' is in force.
Hi Ron, thank you for reporting the issue! (In reply to Ron Yorston from comment #0) > Why isn't vim-enhanced available as a component in Bugzilla? I've selected > the component 'vim', which claims to be for GVim. I'm NOT using GVim. Looks like a bug in bugzilla, filed here https://bugzilla.redhat.com/show_bug.cgi?id=1933696 . > > How reproducible: > > Very. > > > Steps to Reproduce: > 1. Start vi without a custom .vimrc > 2. Enter compatibility mode: ':set compatible' > 3. Enter insert mode and type some text > 4. Shift focus to a different window: vim exits insert mode > I'll try to reproduce it. Though I'm interested in the reason why you use 'compatible' mode with Vi - IIUC it disables some Vim newer features to try to be compatible with previous Vi project as much as it can. (In reply to Ron Yorston from comment #1) > I've bisected the issue by building from source. The commit that enables the > strange behaviour is 681fc3fa7 (patch 8.2.2345: no focus events in a > terminal). I think this means the first affected Fedora package is > 8.2.2465-1.fc33. Thank you for bisecting, Ron! > > The commit message says handling of focus events in the terminal can be > disabled with 'set t_fd=' and 'set t_fe='. I've put these in my .vimrc and > the problem has gone away. Ok, then it seems like an expected change, but the current behavior looks odd. > > What I haven't been able to figure out is: > > - where the strange behaviour is implemented; > > - why it only affects the Fedora package when 'set compatible' is in force. To be honest, I always avoid using 'compatible' mode with Vim - it triggers some completely different behavior from usual Vim. The Vim project looks like to doesn't even count those issues as errors in Vim - see https://vimhelp.org/vim_faq.txt.html#faq-2.5 - all steps for reproducers contains '-N', which turns off the compatible mode. From what I found out till now - the feature added the code in check_termcode() which does stuff based on what event comes from a terminal - right now, the key which Vim works with in check_termcode() if compatible mode is on and you lose focus is 'b' - which is defined as KE_FOCUSGAINED constant. This looks wrong - you should get KE_FOCUSLOST. I will track where and how we get key_name.
KE_FOCUSLOST is defined as 'c'.
Hi Zdenek, Thanks for looking into this. Don't waste too much time on it: there is a workaround. >Though I'm interested in the reason why you use 'compatible' mode with Vi Familiarity. I learned vi forty years ago and have just stuck with the features I know from that era. In 1986 I implemented a vi clone for the CP/M-based Amstrad PCW 8256 computer and released it as charityware. Pleased to see Bram is carrying on the tradition with vim.
On further investigation I found that in compatible mode the focus lost event wasn't being fired when in insert mode. This is because the option esckeys is disabled in compatible mode. The focus lost sequence 'ESC[O' isn't interpreted and the ESC causes insert mode to be exited. The code is near the top of check_termcode() in src/term.c: /* * Skip this position if p_ek is not set and tp[0] is an ESC and we * are in Insert mode. */ if (*tp == ESC && !p_ek && (State & INSERT)) continue; p_ek is the variable set by the esckeys option. An alternative workaround for compatible mode is thus adding 'set esckeys' to .vimrc. I'm not sure there's much else that can be done about it.
Ok, so 'b' is in key_name because of this code in term.c: 5385 if (slen == 2 && len > 2 5386 && termcodes[idx].code[0] == ESC 5387 && termcodes[idx].code[1] == '[' 5388 && !isdigit(tp[2])) 5389 { 5390 if (mouse_index_found < 0) 5391 mouse_index_found = idx; 5392 } 5393 else 5394 { 5395 key_name[0] = termcodes[idx].name[0]; 5396 key_name[1] = termcodes[idx].name[1]; 5397 break; 5398 } The condition is false, so the code assigns name from termcodes to key_name indexed by idx (which is an iterator in the nearest loop). We get into the block because of the following condition being true: 5356 if (STRNCMP(termcodes[idx].code, tp, 5357 (size_t)(slen > len ? len : slen)) == 0) 5358 { termcodes is just a list of structures which represent possible inputs from terminal to Vim - both codes which we are interested in (FOCUSLOST and FOCUSGAIN) are defined in both modes (though compatible mode has more available termcodes - check the attached files...). But what is different between compatible and nocompatible is the value of 'tp' - nocompatible has 'tp' = "\033[O" and compatible has 'tp' = "\033[I". 'tp' is defined here, because 'buf' parameter is NULL: 5275 for (offset = 0; offset < max_offset; ++offset) 5276 { 5277 if (buf == NULL) 5278 { 5279 if (offset >= typebuf.tb_len) 5280 break; 5281 tp = typebuf.tb_buf + typebuf.tb_off + offset; 5282 len = typebuf.tb_len - offset; // length of the input 5283 } compatible has typebuf.tb_off = 106 and nocompatible typebuf.tb_off = 88, but right know I'm not sure where typebuf is modified like that ... ============================================================================================================================================================== Looks like you were quicker and get further than me :)
Ron, I reported the issue upstream as https://github.com/vim/vim/issues/7926 so we can follow up there. I'll close this issue as UPSTREAM.
Thanks, Zdenek. It didn't take long for upstream to provide a fix!
FEDORA-2021-cab0530bf6 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab0530bf6
FEDORA-2021-e093395723 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e093395723
FEDORA-2021-cab0530bf6 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cab0530bf6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab0530bf6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e093395723 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e093395723` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e093395723 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e093395723 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.