[vim/vim] Vim receives ^[[O and ^[[I when FocusLost and FocusGained respectively in alacritty terminal emulator when mouse=a is set (Issue #12499)
FosRexx
Steps to reproduce
- Start vim in alacritty
- Open some other application in another window
- Switch back and fourth from vim to that another window
- Vim requests for "urgent focus" and the color of window will change if you are on i3wm(windows manager) when vim loses focus
- If vim again gains focus then two things might happen a. If your cursor was over a keyword then displays all lines that contain the keyword under cursor. b. If your cursor was not over empty space then, vim returns an error "E349: No identifier under cursor"
Expected behaviour
Vim did not used to do Step 4 and 5 of 'Steps to reproduce' and I only started to have this problem recently when I updated ncurses from ncurses-6.4-2 to ncurses 6.4_20230520-1.
Version of Vim
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 20 2023 16:56:14) Included patches: 1-1572 Compiled by Arch Linux
Environment
OS: Arch Linux x86_64
Kernel: 6.3.6-arch1-1
Shell: bash 5.1.16
Terminal: alacritty 0.12.1
$TERM: alacritty
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> 1. Start vim in alacritty
> 2. Open some other application in another window
> 3. Switch back and fourth from vim to that another window
> 4. Vim requests for "urgent focus" and the color of window will change if you are on i3wm(windows manager) when vim loses focus
> 5. If vim again gains focus then two things might happen a. If your cursor was over a keyword then displays all lines that contain the keyword under cursor. b. If your cursor was not over empty space then, vim returns an error "E349: No identifier under cursor"
>
> ### Expected behaviour
>
> Vim did not used to do Step 4 and 5 of 'Steps to reproduce' and I only started to have this problem recently when I updated ncurses from ncurses-6.4-2 to ncurses 6.4_20230520-1.
>
>
> VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 20 2023 16:56:14) Included patches: 1-1572 Compiled by Arch Linux
>
>
> OS: Arch Linux x86_64
> Kernel: 6.3.6-arch1-1
> Shell: bash 5.1.16
> Terminal: alacritty 0.12.1
> $TERM: alacritty
terminal-specific code inside Vim. The termcap/terminfo mechanisms
should take care of this, but for a long time hardly any improvements
were made and the quality deteriorated with recently created terminal
emulators that added features that are not reflected in termcap/terminfo.
Disagreements between maintainers made this worse. Hopefully we can
move this in the right direction again.
The codes for focus-gained and focus-lost have not changed. They are
mentioned in terminfo with kxIN and kxOUT, but they are hardly used.
And there are no (two letter) termcap codes for these. Vim guesses that
for xterm-like terminals the codes CSI I and CSI O will be received.
alacritty is not considered xterm-like though.
I'm not sure if it would be OK to recognize CSI I and CSI O for all
terminals. It would break things if these codes are actually used for
something else, e.g. a prefix for some key. And it still won't work if
the terminal actually sends different codes for focus lost/gained.
In the Vim help you can find the section with the tag
"xterm-focus-event" with some information.
Adding the proper codes to terminfo/termcap can be expected to take a
long time. We use t_fe and t_fd to enable and disable focus tracking,
but I don't think "fe" and "fd" are actual termcap entries.
On my system t_fe and t_fd are empty when using "alacritty", perhaps
your system does define them somewhere? You might get info with:
verbose set t_fe? t_fd?
Supporting focus events when the terminal implements them is less
important than recognizing the codes, no matter if Vim knows how to
enable or disable them. One way to handle this is to change the code to
always recognize CSI I and CSI O and then wait until someone
complains...
--
hundred-and-one symptoms of being an internet addict:
131. You challenge authority and society by portnuking people
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
>
> > ### Steps to reproduce
> >
> > 1. Start vim in alacritty
> > 3. Switch back and fourth from vim to that another window
> > 4. Vim requests for "urgent focus" and the color of window will change if you are on i3wm(windows manager) when vim loses focus
> > 5. If vim again gains focus then two things might happen a. If your cursor was over a keyword then displays all lines that contain the keyword under cursor. b. If your cursor was not over empty space then, vim returns an error "E349: No identifier under cursor"
> >
> > ### Expected behaviour
> >
> > Vim did not used to do Step 4 and 5 of 'Steps to reproduce' and I only started to have this problem recently when I updated ncurses from ncurses-6.4-2 to ncurses 6.4_20230520-1.
> >
> >
> > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 20 2023 16:56:14) Included patches: 1-1572 Compiled by Arch Linux
> >
> >
> > OS: Arch Linux x86_64
> > Kernel: 6.3.6-arch1-1
> > Shell: bash 5.1.16
> > Terminal: alacritty 0.12.1
> > $TERM: alacritty
>
> terminal-specific code inside Vim. The termcap/terminfo mechanisms
> should take care of this, but for a long time hardly any improvements
> were made and the quality deteriorated with recently created terminal
> emulators that added features that are not reflected in termcap/terminfo.
> Disagreements between maintainers made this worse. Hopefully we can
> move this in the right direction again.
>
> The codes for focus-gained and focus-lost have not changed. They are
> mentioned in terminfo with kxIN and kxOUT, but they are hardly used.
> And there are no (two letter) termcap codes for these. Vim guesses that
> for xterm-like terminals the codes CSI I and CSI O will be received.
> alacritty is not considered xterm-like though.
>
> I'm not sure if it would be OK to recognize CSI I and CSI O for all
> terminals. It would break things if these codes are actually used for
> something else, e.g. a prefix for some key. And it still won't work if
> the terminal actually sends different codes for focus lost/gained.
>
> In the Vim help you can find the section with the tag
> "xterm-focus-event" with some information.
>
> Adding the proper codes to terminfo/termcap can be expected to take a
> long time. We use t_fe and t_fd to enable and disable focus tracking,
> but I don't think "fe" and "fd" are actual termcap entries.
> On my system t_fe and t_fd are empty when using "alacritty", perhaps
> your system does define them somewhere? You might get info with:
> verbose set t_fe? t_fd?
>
> Supporting focus events when the terminal implements them is less
> important than recognizing the codes, no matter if Vim knows how to
> enable or disable them. One way to handle this is to change the code to
> always recognize CSI I and CSI O and then wait until someone
> complains...
So always recognizing them looks fairly safe.
However, making it configurable with t_fe/t_fd should accommodate the
rare user who's tinkered with key definitions.
A few terminals use/used the codes (some long-obsolete AT&T terminals,
as well as those based on SCO console, including the effectively obsolete
FreeBSD console -- replaced by "teken", which pretends to be xterm(*)).
(*) teken can also pretend to be the original FreeBSD cons25, but it's
debatable which is worse :-)
--
Thomas E. Dickey ***@***.***>
https://invisible-island.net
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
FosRexx
Most of the things you said went over my head. I am not that familiar with vim jargons.
If it was not clear from the initial comment, this issue started happening when I updated ncurses from ncurses-6.4-2 to ncurses 6.4_20230520-1 and downgrading ncurses fixes this issue. I made a post in r/vim and other people are facing the same problem and all of us started facing this problem when updating from ncurses-6.4-2 to ncurses 6.4_20230520-1 and most of us use alacritty. So, maybe I should have started from making a bug report in alacritty before here since alacritty has ncursers as dependency and it seems to be the main cause of this. And I agree on your stance to not write terminal specific code and following a standard.
Anyways, t_fe and t_fd are empty on both versions of ncursers. I also followed the documentation on xterm-focus-event but it did not help.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
James Holderness
I'm not sure if it would be OK to recognize CSI I and CSI O for all terminals.
@brammool Alacritty wouldn't be sending those sequences for a focus change unless you specifically requested that behavior by setting mode ?1004. So if you don't want to recognise CSI I and CSI O for all terminals, then just don't set mode ?1004 for all terminals.
As for how you determine whether it's safe to set mode ?1004, the standard way to do that on DEC-based terminals would be a DECRQM request. Not everyone supports that (I don't think Alacritty does), but quite a lot do, and if you consider this a non-essential feature, it's not unreasonable to have it off by default, and then enable it only when you can positively confirm support with DECRQM.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Most of the things you said went over my head. I am not that familiar
> with vim jargons.
>
>
> If it was not clear from the initial comment, this issue started
> 6.4_20230520-1 and downgrading ncurses fixes this issue. I made a
> in r/vim and other people are facing the same problem and all of us
> started facing this problem when updating from ncurses-6.4-2 to ncurses
> 6.4_20230520-1 and most of us use alacritty. So, maybe I should have
> started from making a bug report in alacritty before here since
> alacritty has ncursers as dependency and it seems to be the main cause
> of this. And I agree on your stance to not write terminal specific code
> and following a standard.
>
> Anyways, t_fe and t_fd are empty on both versions of ncursers. I also
> followed the documentation on xterm-focus-event but it did not help.
Perhaps it has an effect on alacritty? For Vim you can do ":set
termcap" with either version and check if the output changed.
Especially look out for "<1b>[?1004h". Normally t_fe would be set to
that, but the hints so far indicate that this doesn't happen. It might
appear as part of another termcap entry though.
--
hundred-and-one symptoms of being an internet addict:
do with your own neighbors.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > I'm not sure if it would be OK to recognize CSI I and CSI O for all
> > terminals.
>
> @brammool Alacritty wouldn't be sending those sequences for a focus
> change unless you specifically requested that behavior by setting mode
> terminals, then just don't set mode `?1004` for all terminals.
system, and someone else also mentioned that t_fe and t_fd are empty,
even when the problem does happen.
It is possible that the terminal sends focus events by default, or that
another program that has been run in the terminal enabled it. Keep in
mind that when a program exits the terminal state is not automatically
restored. A well behaving program will restore terminal settings it has
changed, but a crash can easily prevent that from happening.
If someone wants to see what happens exactly, start Vim with:
vim --clean --log logfile
And "logfile" will contain all the raw input and output.
> As for how you determine whether it's safe to set mode `?1004`, the
> standard way to do that on DEC-based terminals would be a `DECRQM`
> request. Not everyone supports that (I don't think Alacritty does),
> but quite a lot do, and if you consider this a non-essential feature,
> it's not unreasonable to have it off by default, and then enable it
I don't see how this helps. Especially if we don't know whether it
works. We could just set t_fe and t_fd to the values used for xterm.
Either they work or they should be ignored.
--
hundred-and-one symptoms of being an internet addict:
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
James Holderness
I have no idea what effect changing the ncurses version has.
A recent ncurses commit added mode ?1004 to the XM terminfo entry for xterm+sm+1006, so I'm assuming that would affect anyone with a TERM value derived from that.
I don't see how this helps. Especially if we don't know whether it
works. We could just set t_fe and t_fd to the values used for xterm.
Either they work or they should be ignored.
It's not about the mode being ignored - it's the fact they you're choosing not to process the CSI I and CSI O reports after setting the mode. So either you always accept those reports, or you selectively enable the mode on terminals that you believe it's safe to do so. I'm suggesting DECRQM is one way to determine that. Or you could just rely on the terminfo, but that appears be what triggered this issue in the first place.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > I have no idea what effect changing the ncurses version has.
>
> A [recent ncurses
> added mode `?1004` to the XM terminfo entry for `xterm+sm+1006`, so
> I'm assuming that would affect anyone with a `TERM` value derived from
> that.
makes sense to add this to the "mouse reporting" entry. Focus can also
change in other ways, but using the mouse is the most obvious way.
> > I don't see how this helps. Especially if we don't know whether it
> > works. We could just set t_fe and t_fd to the values used for xterm.
> > Either they work or they should be ignored.
>
> It's not about the mode being ignored - it's the fact they you're
> choosing not to process the `CSI I` and `CSI O` reports after setting
> the mode. So either you always accept those reports, or you
> selectively enable the mode on terminals that you believe it's safe to
> do so. I'm suggesting `DECRQM` is one way to determine that. Or you
> could just rely on the terminfo, but that appears be what triggered
> this issue in the first place.
assuming what codes are used. Anyway, I have not heard or seen anything
but those CSI I and CSI O codes, always recognizing those seems the easy
way out.
--
Birthdays are healthy. The more you have them, the longer you live.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #12499 as completed via 85ef2df.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
James Holderness
Note that XTerm defines mode ?1004 as "Send FocusIn/FocusOut events". And if you follow the FocusIn/FocusOut link, you'll see "it causes xterm to send CSI I when the terminal gains focus, and CSI O when it loses focus."
So those codes are literally part of the definition for mode ?1004 - terminals don't have any other option if they're claiming to support that mode.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Note that XTerm defines mode ?1004 as ["Send FocusIn/FocusOut events"](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-?-Pm-h:Ps-=-1-0-0-4.1F7C
> ). And if you follow the [FocusIn/FocusOut](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-FocusIn_FocusOut) link, you'll see "it causes xterm to send CSI I when the terminal gains focus, and CSI O when it loses focus."
> So those codes are literally part of the definition for mode ?1004 -
> terminals don't have any other option if they're claiming to support
> that mode.
otherwise, for whatever reason. There have been discussions in the past
between terminal emulator maintainers that ended up in doing something
else. These discussions often put the personal opinion of a maintainer
above the interest of the users. The lack of a recognized authority
also plays a role. The disappointing result is that I have a lot of
trouble making Vim work properly with all terminals. It will take time.
--
hundred-and-one symptoms of being an internet addict:
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\