[vim/vim] Modifier keys(?) are messed up in kitty after leaving vim (Issue #11705)
Björn Steinbrink
Steps to reproduce
- Use vim in kitty for a while, doing ??? (I have no reliable way to reproduce yet)
- Leave vim, or put it in the background using Ctrl-Z
- Key combinations like Ctrl-D or Ctrl-C have stopped working.
- Running "cat" and pressing such combinations display escape sequences instead, e.g.:
$ "cat"
^[[99;5u^[[118;5u^[[100;5u
Upon re-entering vim, either by starting a new instance or resuming the one in the background, the keys combos work again within vim, but are non-functional again when leaving it.
Expected behaviour
Key combinations still work after leaving vim.
Version of Vim
9.0.993
Environment
Ubuntu 22/10
kitty 0.26.5
xterm-kitty
bash
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. Use vim in kitty for a while, doing ??? (I have no reliable way to reproduce yet)
Did you start Vim with "vim --clean"? If not, the do that.
> 2. Leave vim, or put it in the background using Ctrl-Z
> 3. Key combinations like Ctrl-D or Ctrl-C have stopped working.
> 4. Running "cat" and pressing such combinations display escape sequences instead, e.g.:
> ```
> $ "cat"
> ^[[99;5u^[[118;5u^[[100;5u
> ```
>
> Upon re-entering vim, either by starting a new instance or resuming
> the one in the background, the keys combos work again within vim, but
> are non-functional again when leaving it.
relevant entries:
set t_TE t_TI t_RK
For me the result is correct:
t_TE=<1b>[>4;m<1b>[=0;1u
t_TI=<1b>[=1;1u
t_RK=<1b>[?u
--
Experience is what you get when you don't get what you want.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Björn Steinbrink
Actually it's trivial to reproduce here, it just didn't occur to me what the key thing is that I've been doing. Simply running :! once is enough to mess up the terminal state for me. Tested used vim -u NONE
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Looks like my response didn't reach github:
Did you start Vim with "vim --clean"? If not, the do that.
This sounds like the t_TE termcap entry has been changed. To see the
relevant entries:
set t_TE t_TI t_RK
For me the result is correct:
t_TE=<1b>[>4;m<1b>[=0;1u
t_TI=<1b>[=1;1u
t_RK=<1b>[?u
It might be a problem related to a recent version of Kitty. It works fine in 0.21.2, the one that comes with Ubuntu 22.04.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
I tried with vim --clean, same result.
set t_TE t_TI t_RK
gives
t_TE=^[[>4;m^[[=0;1u
t_TI=^[[=1;1u
t_RK=^[[?u
Which at first glance seems equal to what you have.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Well, then I assume your Kitty version is broken.
It works fine for me, and I don't see any reason Vim would do differently for you.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
there two issues looks:
1, you can simply reproduce it by vim --clean -c ':!' -c ':call feedkeys("\<c-z>", "n")'
// but it is not only kitty, but xfce-term looks there stray chars also.
2, another one, ran manually as it:
a, vim --clean
b, :!<cr>
c, <c-z>
d, emit cat in bash cli
e, emit ctrl-c then there are some stray chars...
// this looks only happened at kitty vs but ok in xfce-term.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
perhaps you can use vim --log logfile.txt and check the raw key input: lines. (Not sure if this is the same as vim --clean -c 'call ch_logfile("logfile.txt")
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
Thanks @chrisbra!
The (what I think) relevant part of the log for the execution of :! seems to be this (I've manually replaced control characters with their hex code like <1b>):
raw terminal output: "<1b>[?25l:!<1b>[?1004l<1b>[?2004l<1b>[?1l<1b>>"
raw terminal output: "<1b>[?25h<1b>[>4;m<1b>[=0;1u<1b>[?1049l" <<<<---- disable alternate screen
executing shell command:
raw terminal output: "<1b>[?1006l<1b>[?1002l"
closing channel log in the child process
closing logfile log
raw terminal output: "<1b>[>4;m<1b>[=0;1u<1b>[=1;1u" <<<<---- this seems broken?
raw terminal output: "<1b>[?1006h<1b>[?1002h"
raw terminal output: "<1b>]2;[No Name] - VIM<07>"
raw terminal output: "<1b>]1;[No Name]<07>"
raw terminal output: "<1b>[?1006l<1b>[?1002l"
looking for messages on channels
raw key input: "<0d>"
raw terminal output: "<1b>[?1006h<1b>[?1002h<1b>[?1049h<1b>[=1;1u<1b>[?1h<1b>=<1b>[?2004h<1b>[?1004h" <<<<---- enable alternate screen
It seems to me, that vim sends a t_TE, t_TI sequence while the alternate screen is still disabled.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
Almost forgot: I've installed the kitty version that comes with Ubuntu, and the problem shows up there as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Now I am completely confused about what the problem is. There basically is mention of "reproduce it" without saying what "it" is. Some repro steps are for very different things and only confuse the actual problem being reported. I'll assume the actual problem is that the kitty keyboard protocol is enabled when it should not be.
I did finally manage to get Kitty in a state where, after using CTRL-Z in Vim it looks like it is still in a state with the Kitty keyboard protocol enabled, which the shell can't handle. Looking in the log I can see that Vim did send the code to disable the keyboard protocol. This points to Kitty not handling this properly. The code in the log is "<1b>[=0;1u", or "[=0;1u".
It does appear that using CTRL-Z without using ":!" before works fine. Once ":!" has been used the problem that the keyboard protocol is enabled appears. In the log I can see that what Vim sends for CTRL-Z is exactly the same in both cases. Thus this indicates there is state in Kitty that differs. I have no idea what state that is, AFAIK there should not be a difference.
@dotdash - Why do you mention the alternate screen? AFAIK the keyboard protocol has no relation with the alternate screen.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
@dotdash - Why do you mention the alternate screen? AFAIK the keyboard protocol has no relation with the alternate screen.
I was looking at https://sw.kovidgoyal.net/kitty/keyboard-protocol/ which says:
Emit the escape code CSI > 1 u at application startup if using the main screen or when entering alternate screen mode, if using the alternate screen.
Which made me assume that the keyboard protocol setting is tied to the screen. I'm sorry for the confusion if that is not the case.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
yes. that is the point.
the different is:
1. the first case which ran via feedkeys(), after that ctrl-z, would output some mess escape chars, which not only in kitty but Xfce-term also.
2. the second case which is @dotdash report ed, after that manual ctrl-z, and `cat` cmd, then try to emit ctrl-c, it output some escape chars vs but would not just cancel the `cat`.
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
Further down on the page, there's also a note:
The main and alternate screens in the terminal emulator must maintain their own, independent, keyboard mode stacks. This is so that a program that uses the alternate screen such as an editor, can change the keyboard mode in the alternate screen only, without affecting the mode in the main screen or even knowing what that mode is. Without this, and if no stack is implemented for keyboard modes (such as in some legacy terminal emulators) the editor would have to somehow know what the keyboard mode of the main screen is and restore to that mode on exit.
So the keyboard protocol does indeed seem to be tied to the screen, and enabling the kitty keyboard protocol in the main screen is probably what's causing the issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Looking through that page searching for "alternate" reveals a note above "Disambiguate escape codes" that hints at there being a keyboard state for the alternate and main screen separately. It's mixed with the use of a "stack" (which is actually totally unreliable and therefore useless).
This is problematic, because Vim often has no clue about whether things happen in the main or the alternate screen. Even when started up it doesn't know where it is. And the user may switch between screens any time, especially when executing shell commands, without Vim being aware of it. There is a habit of using t_ti and t_te for switching between screens, but it's not set in stone and Vim doesn't (can't) parse termcap entries to find out what they are doing.
I'm not sure this can be solved.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
Dont randomnly transition screens. There is no usecase for that. At startup always switch to alternate screen. Then enable the keyboard protocol. Whenever vim relinquishes control of the tty, whether that is to run a shell command, suspend itself, or quit, it is incumbent on it to restore the tty to the state it found it in, or if it is not capable of doing that, then to a known good state. Which means you turn off the keyboard protocol and preferably transition back to the main screen before relinquishing control of the tty.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
Oh and as far as I can tell for this particular issue, all you need to do is emit the restore keyboard protocol bytes before you emit the switch to main screen bytes when doing :!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
First of all: Vim runs in whatever screen is currently active. That cannot be changed, this is what has always happened and users depend on it.
It appears that the terminfo entry for xterm-kitty includes values for t_te and t_ti that switch to and from the alternate screen. I don't know why or where these entries come from, but they are an essential part of the problem. Vim doesn't parse the termcap entries (as if it could!) thus it has no clue that screen switching is happening. Note that there is no documentation for t_ti or t_te being used for screen switching. Terminfo mentions something about cursor positioning but that appears to be completely outdated.
Making assumptions that t_ti and t_te are indeed the termcap entries used for switching screens, there is an inconsistency between going in and out of termcap mode. In starttermcap() t_ti is output first, before t_TI. In stoptermcap() t_te was output after the other codes. This is kind of symmetric, but assuming (again) that switching between screens happens and it makes what follow work differently, then outputting t_te first would help. Thus asymmetry would be the goal, if you look at it this way.
I can indeed fix the specific problem by outputting t_te earlier. The big question is whether this causes problems in any other setup. It's impossible to predict. Breaking the symmetry is good in this situation, but might be bad in other situations, since we don't know what t_ti and t_te are being used for. I suppose the only way is to try and see who complains.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
FWIW, for now I'm working around the issue by having this in my vimrc:
set keyprotocol=xterm:mok2
let &term=&term
The second line is needed because keyprotocol only becomes effective when term is set.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
> First of all: Vim runs in whatever screen is currently active. That cannot be changed, this is what has always happened and users depend on it.
screen and on exit returns to main screen.
If I start vim in alternate screen it stays in alternate screen and on
exit returns to main screen. So how do your users depend on the initial state?
Demonstration:
```sh
echo 'in main screen'
tput smcup; vim
tput rmcup; vim
```
>
> It appears that the terminfo entry for xterm-kitty includes values for t_te and t_ti that switch to and from the alternate screen. I don't know why or where these entries come from, but they are an essential part of the problem. Vim doesn't parse the termcap entries (as if it could!) thus it has no clue that screen switching is happening. Note that there is no documentation for t_ti or t_te being used for screen switching. Terminfo mentions something about cursor positioning but that appears to be completely outdated.
kitty's terminfo. The relevant terminfo entries are smcup and rmcup.
te and ti are in termcap not terminfo. And they mean put terminal in
"cursor motion" mode. AKA alternate screen. What are you expecting to be
in ti and te? And does vim really read termcap rather than terminfo?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Björn Steinbrink
With patch 1063, running :!nano inside vim --clean no longer works properly, because the alternate screen stays in kitty keyboard protocol mode, and nano can't deal with that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> With patch 1063, running `:!nano` inside `vim --clean` no longer works
> properly, because the alternate screen stays in kitty keyboard
> protocol mode, and nano can't deal with that.
What terminfo/termcap are you using? What version of nano and kitty?
The problem really appears to be caused by Kitty having a different
keyboard protocol setting for the main and alternate screens. I'm not
aware of any other terminal having that. So that's the root cause of
the prolem. No application is prepared for dealing with it.
Still, this version of Kitty exists and is being used, so we'll probably
have to do extra work to deal with this weird terminal... And a
thousand other applications as well (including nano, apparently).
--
Not too long ago, compress was something you did to garbage...
Bram Moolenaar
> On Fri, Dec 16, 2022 at 04:58:45AM -0800, Bram Moolenaar wrote:
> > First of all: Vim runs in whatever screen is currently active. That
> > cannot be changed, this is what has always happened and users depend
> > on it.
>
> I dont follow, if I start vim in main screen it switches to alternate
> screen and on exit returns to main screen.
>
> If I start vim in alternate screen it stays in alternate screen and on
> exit returns to main screen. So how do your users depend on the
> initial state?
setup to cause this.
> Demonstration:
>
> ```sh
> echo 'in main screen'
> tput smcup; vim
> tput rmcup; vim
> ```
And you must start vim with "vim --clean" to avoid your config files to
change options and termcap entries.
> > It appears that the terminfo entry for xterm-kitty includes values
> > for t_te and t_ti that switch to and from the alternate screen. I
> > don't know why or where these entries come from, but they are an
> > essential part of the problem. Vim doesn't parse the termcap
> > entries (as if it could!) thus it has no clue that screen switching
> > is happening. Note that there is no documentation for t_ti or t_te
> > being used for screen switching. Terminfo mentions something about
> > cursor positioning but that appears to be completely outdated.
>
> te and ti are not in terminfo, so I dont see how they could be in
> kitty's terminfo. The relevant terminfo entries are smcup and rmcup.
enter_ca_mode smcup ti string to start pro‐
grams using cup
exit_ca_mode rmcup te strings to end pro‐
grams using cup
You do know about the relation between terminfo and termcap names,
right? They are 1:1, so either can be used to identify an entry.
> te and ti are in termcap not terminfo. And they mean put terminal in
> "cursor motion" mode. AKA alternate screen. What are you expecting to be
> in ti and te? And does vim really read termcap rather than terminfo?
I don't see where you get that "cursor motion mode" is AKA "alternate
screen". Where is that documented? The info about "cursor motion" is
wrong anyway, I don't know any terminal that requires outputting t_ti to
enable cursor positioning, it works anyway. An old comment in Vim
mentions t_ti is used to put the terminal in "termcap mode". But it
appears to be just an old thing that doesn't have a specific meaning,
other than it being output when an editor starts.
--
What the word 'politics' means: 'Poli' in Latin meaning 'many' and 'tics'
meaning 'bloodsucking creatures'.
/// 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, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
>
> > On Fri, Dec 16, 2022 at 04:58:45AM -0800, Bram Moolenaar wrote:
> > > First of all: Vim runs in whatever screen is currently active. That
> > > cannot be changed, this is what has always happened and users depend
> > > on it.
> >
> > I dont follow, if I start vim in main screen it switches to alternate
> > screen and on exit returns to main screen.
> >
> > If I start vim in alternate screen it stays in alternate screen and on
> > exit returns to main screen. So how do your users depend on the
> > initial state?
>
> That is not Vim's doing. You have have some termcap/terminfo entries
> setup to cause this.
>
> > Demonstration:
> >
> > ```sh
> > echo 'in main screen'
> > tput smcup; vim
> > tput rmcup; vim
> > ```
>
> What is $TERM set to? What are the termcap/terminfo entries for $TERM?
> And you must start vim with "vim --clean" to avoid your config files to
> change options and termcap entries.
>
> > > It appears that the terminfo entry for xterm-kitty includes values
> > > for t_te and t_ti that switch to and from the alternate screen. I
> > > don't know why or where these entries come from, but they are an
> > > essential part of the problem. Vim doesn't parse the termcap
> > > entries (as if it could!) thus it has no clue that screen switching
> > > is happening. Note that there is no documentation for t_ti or t_te
> > > being used for screen switching. Terminfo mentions something about
> > > cursor positioning but that appears to be completely outdated.
> >
> > te and ti are not in terminfo, so I dont see how they could be in
> > kitty's terminfo. The relevant terminfo entries are smcup and rmcup.
>
> The terminfo manpage has these entries:
>
> enter_ca_mode smcup ti string to start pro‐
> grams using cup
>
> exit_ca_mode rmcup te strings to end pro‐
> grams using cup
>
> You do know about the relation between terminfo and termcap names,
> right? They are 1:1, so either can be used to identify an entry.
Some examples:
Sync Tc setrgbf setrgbb fullkbd kUP kDN kbeg kBEG
If you insist on using termcap/terminfo in vim maybe you should
educate yourself about them a little.
>
> > te and ti are in termcap not terminfo. And they mean put terminal in
> > "cursor motion" mode. AKA alternate screen. What are you expecting to be
> > in ti and te? And does vim really read termcap rather than terminfo?
>
> That is irrelevant, they are the same entries.
```
infocmp xterm | grep smcup 1 master
smcup=\E[?1049h\E[22;0;0t, smglp=\E[?69h\E[%i%p1%ds,
```
So your favorite terminal also includes \e[?1049h aka turn on alternate
screen in smcup which according to you is the same as ti. And here is
smcup for kitty
```
infocmp xterm-kitty | grep smcup
smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h, smso=\E[7m,
```
So I think you can stop blaming kitty's terminfo for this bug.
>
> I don't see where you get that "cursor motion mode" is AKA "alternate
> screen". Where is that documented? The info about "cursor motion" is
> wrong anyway, I don't know any terminal that requires outputting t_ti to
> enable cursor positioning, it works anyway. An old comment in Vim
> mentions t_ti is used to put the terminal in "termcap mode". But it
> appears to be just an old thing that doesn't have a specific meaning,
> other than it being output when an editor starts.
sun has alternate screen in smcup. I demonstrated it above for xterm and
kitty. Here are some more:
```
infocmp alacritty | grep smcup
smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
infocmp tmux | grep smcup
sgr0=\E[m\017, sitm=\E[3m, smacs=^N, smcup=\E[?1049h,
infocmp gnome | grep smcup
smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
infocmp iTerm.app | grep smcup
sgr0=\E[m\017, smacs=^N, smam=\E[?7h, smcup=\E7\E[?47h,
```
Here \E[?47h also switches to alternate screen but without saving the
cursor and clearing the buffer.
So let me ask you, where do you get the idea that cursor motion mode is *not*
alternate screen. And if you think its not, what do you think it means?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Kovid Goyal wrote:
[...]
> > That is not Vim's doing. You have have some termcap/terminfo entries
> > setup to cause this.
>
> vim is outputting the bytes, so its vim's doing.
course not. Whoever put those codes in terminfo is responsible, Vim
just follows the rules (as well as possible) outputting the codes. Of
course Vim does not know what the bytes mean, that's the whole idea of
using terminfo entries.
> > The terminfo manpage has these entries:
> >
> > enter_ca_mode smcup ti string to start pro‐
> > grams using cup
> >
> > exit_ca_mode rmcup te strings to end pro‐
> > grams using cup
> >
> > You do know about the relation between terminfo and termcap names,
> > right? They are 1:1, so either can be used to identify an entry.
>
> They are not 1:1, terminfo has many capabilities that termcap lacks.
> Some examples:
>
> Sync Tc setrgbf setrgbb fullkbd kUP kDN kbeg kBEG
- Sync does not exist
- Tc does not exist
- setrgbf does not exist
- fullkbd does not exist
- kUP does not exist
- kDN does not exist
- kbeg does exist, the termcap equivalent is "@1".
- kBEG does exist, the termcap equivalent is "&9".
I'm sure the ones that do not exist in my manpage will exist somewhere,
but I don't really care about them. And giving them a termcap entry
name is just a matter of time. What matters is that the relation is
1:1, if you have the termcap entry name, you can lookup the terminfo
entry name, and vice versa. Some entries may not have both names, but
if they do then it's clear what the relation is.
> If you insist on using termcap/terminfo in vim maybe you should
> educate yourself about them a little.
> > > te and ti are in termcap not terminfo. And they mean put terminal in
> > > "cursor motion" mode. AKA alternate screen. What are you expecting to be
> > > in ti and te? And does vim really read termcap rather than terminfo?
> >
> > That is irrelevant, they are the same entries.
>
> In which case here you go
That is beside the point, I said that the entries from terminfo and
termcap are the same. Unless perhaps you have a system that was badly
configured. I mean, why would they ever be different?
> So I think you can stop blaming kitty's terminfo for this bug.
the main or the alternate screen. That is the cause of this bug.
There is some rationale hidden in the keyboard protocol spec (the note
above the "Disambiguate escape codes" section), but it ignores the
problems it introduces. Especially that no existing application can
deal with it, thus introducing a big problem. And I see no good
justification for it.
> You yourself claim ti and smcup are the same. Every terminal under the
> sun has alternate screen in smcup. I demonstrated it above for xterm and
> kitty. Here are some more:
not about switching between main and alternate screen, Vim deals with
that as well as can be expected. The problem is that the switch is not
expected to have an effect on what key protocol is used.
> So let me ask you, where do you get the idea that cursor motion mode
> is *not* alternate screen. And if you think its not, what do you think
> it means?
unrelated concepts. You are avoiding my question.
--
Apologies for taking up the bandwidth with the apology. Anything else I
can apologise for ...... er no can't think of anything, sorry about that.
Andy Hunt (Member of British Olympic Apology Squad)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
Bram Moolenaar
> With patch 1063, running `:!nano` inside `vim --clean` no longer works
> properly, because the alternate screen stays in kitty keyboard
> protocol mode, and nano can't deal with that.
after the patch another thing fails.
I guess the only solution would be to detect the situation (more or
less, we can't be 100% sure) and disable the keyboard protocol both
before and after outputing t_te.
I'm really starting to wonder what the reason is that the kitty keyboard
protocol can differ per screen. Where is that useful?
--
LAUNCELOT: At last! A call! A cry of distress ...
(he draws his sword, and turns to CONCORDE)
Concorde! Brave, Concorde ... you shall not have died in vain!
CONCORDE: I'm not quite dead, sir ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
Shane-XB-Qian
case 1 still there, but can reduce the reproduce steps just to: vim --clean -c ':call feedkeys("\<c-z>", "n")'
// manually ran is ok (no issue if manually run)
would see some stray esc chars there after that, but this is not only kitty, but xfce-term (and with gnu-screen) also.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Please be specific about what the problem is. With the command you give I don't see any problem typing keys with modifiers. I do see some escape responses ending up in the shell, that is a completely different problem and doesn't belong in this issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
I do not know how specific you want, I guess it is `restore the cursor and redraw the screen` after `ctrl-z` which happened when emitted via feedkeys() vs not press ctrl-z manually.
but I am not an expert on this, just helping you guys to fix the problem, and calm down or whatever...... :-)
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
I have created #11719 with the command you gave.
That problem has been around for a while, but I don't think we had an issue for it.
I don't think there is a single fix, but we can try some things to make it happen less often, and discuss the progress on the issue.
Otherwise, I think after patch 9.0.1065 this issue should be fixed. Can we close it?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
// or actually I wish you can invest some time on vim with Gnu-screen specially UTF issues :-)
// I opened some tickets about that (gnu-screen) before...
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
options.txt;
*'restorescreen'* *'rs'* *'norestorescreen'* *'nors'*
'restorescreen' 'rs' boolean (default on)
global
{only in MS-Windows console version}
When set, the screen contents is restored when exiting Vim. This also
happens when executing external commands.
For non-Windows Vim: You can set or reset the 't_ti' and 't_te'
options in your .vimrc. To disable restoring:
set t_ti= t_te=
To enable restoring (for an xterm):
set t_ti=^[7^[[r^[[?47h t_te=^[[?47l^[8
(Where ^[ is an <Esc>, type CTRL-V <Esc> to insert it)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #11705 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.