Skip to content

Implement focus tracking for terminals#7673

Closed
vimpostor wants to merge 1 commit intovim:masterfrom
vimpostor:termfocus
Closed

Implement focus tracking for terminals#7673
vimpostor wants to merge 1 commit intovim:masterfrom
vimpostor:termfocus

Conversation

@vimpostor
Copy link
Contributor

This implements focus tracking for terminals supporting this sequence. See https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-FocusIn_FocusOut for the specification.

This is largely based on the initial patch by saitoha on the mailing list 5 years ago.

Problem:	Only gVim supports focus events.
Solution:	Listen for CSI I/CSI O sequences (FocusIn/FocusOut).
		(Closes vim#5526, closes vim#609)
@codecov
Copy link

codecov bot commented Jan 13, 2021

Codecov Report

Merging #7673 (458d710) into master (6601b62) will decrease coverage by 0.10%.
The diff coverage is 69.23%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7673      +/-   ##
==========================================
- Coverage   88.64%   88.54%   -0.11%     
==========================================
  Files         148      148              
  Lines      164279   162146    -2133     
==========================================
- Hits       145627   143571    -2056     
+ Misses      18652    18575      -77     
Flag Coverage Δ
huge-clang-none 86.17% <ø> (-1.89%) ⬇️
huge-gcc-none 88.44% <69.23%> (+<0.01%) ⬆️
huge-gcc-unittests 2.48% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/term.c 80.95% <69.23%> (-0.50%) ⬇️
src/help.c 89.76% <0.00%> (-1.08%) ⬇️
src/textobject.c 91.69% <0.00%> (-0.71%) ⬇️
src/gui.c 59.18% <0.00%> (-0.68%) ⬇️
src/profiler.c 92.39% <0.00%> (-0.65%) ⬇️
src/clipboard.c 82.05% <0.00%> (-0.57%) ⬇️
src/ops.c 91.80% <0.00%> (-0.57%) ⬇️
src/ex_cmds2.c 90.68% <0.00%> (-0.54%) ⬇️
src/move.c 93.60% <0.00%> (-0.54%) ⬇️
src/bufwrite.c 76.47% <0.00%> (-0.53%) ⬇️
... and 90 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6601b62...e1c1b9c. Read the comment docs.

@vimpostor
Copy link
Contributor Author

Sry I had a compiler warning, but I fixed it already and rebased. Tests should pass now.

@brammool
Copy link
Contributor

Thanks, I'll include it now.
If anybody notices an undesired side effect, please let us know.

@brammool brammool closed this in 681fc3f Jan 14, 2021
@Shane-XB-Qian

This comment was marked as off-topic.

@Shane-XB-Qian

This comment was marked as off-topic.

@liskin
Copy link

liskin commented Jan 20, 2021

Thanks a lot for this! ♥

It does not seem to work in tmux out of the box, however, because find_builtin_term("tmux-256color") returns the end marker, not the xterm entry, so t_fe and t_fd stay empty. It's a bit confusing as 681fc3f#diff-de432db93b351dd11d91c892d506b5ba9de1c98ef632d358c8590a312ed5a18aR2058 suggests it might work in tmux.

Is that intentional? Should we perhaps document it somewhere that tmux users are supposed to set t_fe and t_fd (and also t_BE, t_BD, t_PS and t_PE, btw)?

@vimpostor
Copy link
Contributor Author

vimpostor commented Jan 20, 2021 via email

@vimpostor
Copy link
Contributor Author

I think it might be the line set -g default-terminal "xterm-256color", which if I remember correctly you need regardless of this for stuff like true color support everywhere.

@liskin
Copy link

liskin commented Jan 20, 2021

@vimpostor Oh, that's because you have set -g default-terminal "xterm-256color" so vim thinks it's an xterm and so obviously find_builtin_term("xterm-256color") does return the xterm entry. But that is definitely not the standard way to configure tmux, is it?

@vimpostor
Copy link
Contributor Author

vimpostor commented Jan 20, 2021

Well I don't know if there is a better way to detect terminals that do support such sequences. I believe there are many other tools that check for xterm-256color to enable such features, but if you know a better way let me know.

@liskin
Copy link

liskin commented Jan 20, 2021

I'm not sure if there are better ways to detect this, but I have found something:

tmux checks the XT terminfo capability and enables bracketed paste and focus reporting if it's present:
https://github.com/tmux/tmux/blob/9ff017e908243f3e24e0e26769c8e5aadfa3cb57/tmux.1#L5948-L5959

XT is documented here:

# The screen program uses the termcap interface.  It recognizes a few useful
# nonstandard capabilities.  Those are used in this file.
#
#       AX   (bool)  Does  understand  ANSI  set  default fg/bg color (\E[39m /
#                    \E[49m).
#       G0   (bool)  Terminal can deal with ISO 2022  font  selection sequences.
#       E0   (str)   Switch charset 'G0' back to standard charset.
#       S0   (str)   Switch charset 'G0' to the specified charset.
#       XT   (bool)  Terminal understands special xterm sequences  (OSC,  mouse
#                    tracking).
#
# AX is relatively straightforward; it is interpreted by ncurses to say that
# SGR 39/49 reset the terminal's foreground and background colors to their
# "default".
#
# XT is harder, since screen's manpage does not give more details.  For that,
# we must read screen's source-code.  For example, when XT is set, screen
# assumes
#
# a) OSC 1 sets the title string, e.g., for the icon.  Recent versions of
#    screen may also set the terminal's name, which is (for xterm) distinct
#    from the icon name.
# b) OSC 20 sets the background pixmap.  This is an rxvt feature.
# c) OSC 39 and OSC 49 set the default foreground/background colors.  Again
#    this is an rxvt feature.
# d) certain mode settings enable the mouse: 9, 1000, 1001, 1002, 1003.
#    These are from xterm, although xterm accepts mouse codes that may not be
#    recognized by screen, e.g., 1005, 1006.
# e) colors beyond 0..7 are implemented by xterm's aixterm-like 16-color
#    sequence.  However, because screen uses only termcap, the values returned
#    by Af/Ab are not usable because they rely on expressions that termcap
#    does not support.  Therefore, screen uses a hardcoded string to work
#    around the limitation.  In a few cases, screen also uses tparm, which
#    is a terminfo function rather than termcap.
# f) all entries named "*xterm*" or "*rxvt*" have the bce flag set.
# g) screen also uses the feature to decide whether to pay attention to other
#    xterm-related features which are unrelated to the description in the
#    manual page.
#
# Since XT is useful only when the outer terminal matches screen's assumptions,
# it is appropriate to use it in the derived terminal descriptions such as
# "screen.xterm", but not in the generic "screen", "screen-bce" entries

Unfortunately XT is not present in tmux terminfo entry so this doesn't help us at all.

Personally, instead of overriding tmux to pretend it's xterm-256color, I use a custom terminfo: https://github.com/liskin/dotfiles/blob/8e1e8d9c3c5e0bfad62dccef78c4f524f9c49489/.terminfo/terminfo.src, so adding XT would be easy (that is, assuming it doesn't break anything else…), but that doesn't help anyone else so it's useless.

So unfortunately I don't know of anything that is clearly better. :-/
I was thinking that maybe some of the builtin termcaps for xterm could be used for tmux as well, given that vim already specialcases tmux in use_xterm_like_mouse, although I'm not sure which ones and how to best do it.

janlazo added a commit to janlazo/neovim that referenced this pull request Mar 6, 2021
…guioptions

Problem:    MS-Windows: No color in shell when using "!" in 'guioptions.
Solution:   Don't stop termcap when using a terminal window for the shell.
            (vim-jp, closes vim/vim#4117)
vim/vim@049ca59

N/A patches for version.c:

vim-patch:8.2.2345: no focus events in a terminal

Problem:    No focus events in a terminal.
Solution:   Add the t_fd and t_fe termcap entries and implement detecting
            focus events. (Hayaki Saito, Magnus Groß, closes vim/vim#7673,
            closes vim/vim#609, closes vim/vim#5526)
vim/vim@681fc3f

vim-patch:8.2.2564: focus events end Insert mode if 'esckeys' is not set

Problem:    Focus events end Insert mode if 'esckeys' is not set.
Solution:   Do not enable focus events when 'esckeys' is off. (closes vim/vim#7926)
vim/vim@51b477f
janlazo added a commit to janlazo/neovim that referenced this pull request Mar 7, 2021
…guioptions

Problem:    MS-Windows: No color in shell when using "!" in 'guioptions.
Solution:   Don't stop termcap when using a terminal window for the shell.
            (vim-jp, closes vim/vim#4117)
vim/vim@049ca59

N/A patches for version.c:

vim-patch:8.2.0890: no color in terminal window when 'termguicolor' is set

Problem:    No color in terminal window when 'termguicolor' is set.
Solution:   Clear the underline color. (closes vim/vim#6186)
vim/vim@1e5f8f6

vim-patch:8.2.1805: Unix: terminal mode changed when using ":shell"

Problem:    Unix: terminal mode changed when using ":shell".
Solution:   Avoid calling settmode() when not needed. (issue vim/vim#7079)
vim/vim@80361a5

vim-patch:8.2.2345: no focus events in a terminal

Problem:    No focus events in a terminal.
Solution:   Add the t_fd and t_fe termcap entries and implement detecting
            focus events. (Hayaki Saito, Magnus Groß, closes vim/vim#7673,
            closes vim/vim#609, closes vim/vim#5526)
vim/vim@681fc3f

vim-patch:8.2.2564: focus events end Insert mode if 'esckeys' is not set

Problem:    Focus events end Insert mode if 'esckeys' is not set.
Solution:   Do not enable focus events when 'esckeys' is off. (closes vim/vim#7926)
vim/vim@51b477f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants