[vim/vim] After 9.0.1080, &tgc doesn't work in kitty (Issue #11729)
chdiza
Steps to reproduce
I have not tried the patch that 9.0.1080 adjusted, but now &tgc doesn't work in kitty. Reproduce:
vim --clean
:colo desert
Observe the desert colorscheme. Now:
:se tgc
Observe what looks like no coloring at all (I see white text on a black background).
For the record, :se term shows xterm-kitty.
Expected behaviour
I expect &tgc to work.
Version of Vim
9.0.1080
Environment
Ubuntu 20.04
kitty 0.26.5
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.
chdiza
9.0.1073 has the same problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
You need to set t_8f and t_8b:
let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"
These are apparently missing from the kitty terminfo entry.
Before they were coming from the built-in xterm termcap entries, but since
it turned out that kitty is not xterm compatible these should not be used.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
It's not just truecolor support that 9.0.1073 broke. Focus events will be broken as well. As will bracketed paste. And underlines. And no doubt lots of other things as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
@brammool I'm hoping you will revert 1073 (and its descendant 1080). I don't know what problem they were meant to solve, but they have made things worse now. Please revert until a better solution is found.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
You need to set t_8f and t_8b:
let &t_8f = "<Esc>[38;2;%lu;%lu;%lum"
let &t_8b = "<Esc>[48;2;%lu;%lu;%lum"
Setting those does not fix the &tgc problem. It seems to have no effect at all.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > You need to set t_8f and t_8b:
> > let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
> > let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"
>
> Setting those does not fix the &tgc problem. It seems to have no effect at all.
it in your vimrc make sure not setting 'term' after that.
The problem is that we were using xterm settings for kitty, but it turns
out that kitty is not xterm compatible. So either kitty has to change
to become xterm compatible or the terminfo entry for kitty has to
contain the right values.
This is no different from what we do for other terminals. The only
weird thing is that the value for $TERM is "xterm-kitty", which suggests
being xterm compatible. Kovid mentioned he was "forced to" use this
value, which seems strange. Anyway, Vim now ignores the "xterm-"
prefix, since kitty is not xterm compatible.
--
Q: How many hardware engineers does it take to change a lightbulb?
A: None. We'll fix it in software.
/// 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
> It's not just truecolor support that 9.0.1073 broke. Focus events will
> be broken as well. As will bracketed paste. And underlines. And no
> doubt lots of other things as well.
missing from the "xterm-kitty" terminfo entry. Why are they missing
from there?
--
Windows
M!uqoms
/// 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.
Kovid Goyal
>
> > It's not just truecolor support that 9.0.1073 broke. Focus events will
> > be broken as well. As will bracketed paste. And underlines. And no
> > doubt lots of other things as well.
>
> You mean that the built-in xterm termcap entries have these, but they are
> missing from the "xterm-kitty" terminfo entry. Why are they missing
> from there?
have no idea what you invented for these in your personal "hardcoded terminfo".
Whatever it is, since you invented it for yourself you cant expect to
find it anywhere but in your own source code.
Some terminals use the non-standard Smulx for underline style, and this
is present in xterm-kitty. There is nothing, standard or not, for
underline color in any terminfo. If you need me to add something you
invented, I would even be willing to discuss that.
As for truecolor, that exists in terminfo since ncurses-6.0 and is
present in xterm-kitty
```
infocmp -1 xterm-kitty | grep seta 130 master
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
```
It is even present in Dickey's made up kitty terminfo
```
infocmp -1 kitty | grep seta master
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
```
Why you are not using them, only you know.
Reference: https://github.com/termstandard/colors
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
Or just revert your last two commits, and dont worry about the t_ut issue, as I said I will send you a PR for it if I can find the time if not the status quo is preferable.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> On Wed, Dec 21, 2022 at 01:20:09AM -0800, Bram Moolenaar wrote:
> >
> > > It's not just truecolor support that 9.0.1073 broke. Focus events will
> > > be broken as well. As will bracketed paste. And underlines. And no
> > > doubt lots of other things as well.
> >
> > You mean that the built-in xterm termcap entries have these, but they are
> > missing from the "xterm-kitty" terminfo entry. Why are they missing
> > from there?
>
> There is no terminfo entry for bracketed paste or underline color. I
> have no idea what you invented for these in your personal "hardcoded terminfo".
> Whatever it is, since you invented it for yourself you cant expect to
> find it anywhere but in your own source code.
xterm. I thought that someone was working on making this available more
widely, but that might have not happened (yet). Bracketed paste is a
security issue, I'm surprised authors of terminal emulators haven't
worked on this. Or at least not resulted in a terminfo entry yet.
> Some terminals use the non-standard Smulx for underline style, and this
> is present in xterm-kitty. There is nothing, standard or not, for
> underline color in any terminfo. If you need me to add something you
> invented, I would even be willing to discuss that.
It's not used much, leave this for later.
> As for truecolor, that exists in terminfo since ncurses-6.0 and is
> present in xterm-kitty
>
> ```
> infocmp -1 xterm-kitty | grep seta 130 master
> setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
> setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
> ```
>
> It is even present in Dickey's made up kitty terminfo
>
> ```
> infocmp -1 kitty | grep seta master
> setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
> setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
> ```
>
> Why you are not using them, only you know.
> Reference: https://github.com/termstandard/colors
one value. The document you point to seems just a collection of what
people found, with unclear status. It doesn't even have an author or
organisation mentioned.
It has a link to ncurses, but the hint to find "RGB" does not work,
there is no info related to RGB there. Perhaps the link is oudated.
I'll have to search around if these values can be used.
--
Seen on the back of a biker's vest: If you can read this, my wife fell off.
/// 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.
chdiza
It works for me, make sure you do this in the right place. If you have it in your vimrc make sure not setting 'term' after that.
I copy and pasted it verbatim into my vimrc. Did github markdown mangle it before I copied it? I am not setting $TERM after that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
copy it from :h xterm-true-color (and use : or ; depending on what kitty actually uses, according to https://github.com/termstandard/colors it seems to support either one).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
> I had to temporarily add some codes to make this work at least for
> xterm. I thought that someone was working on making this available more
> widely, but that might have not happened (yet). Bracketed paste is a
> security issue, I'm surprised authors of terminal emulators haven't
> worked on this. Or at least not resulted in a terminfo entry yet.
given up trying to get anything into terminfo. That said if terminfo
were to grow a property for this I would of course add it to kitty's
terminfo.
> I was only aware of "setab" and "setaf" being used to set a color with
> one value. The document you point to seems just a collection of what
> people found, with unclear status. It doesn't even have an author or
> organisation mentioned.
these degenerate times. If it helps here's what man terminfo says about
them:
set_a_foreground setaf AF Set foreground color to #1, using ANSI escape
I believe they are limited to only a single parameter in ncurses, unless
the RGB flag is set, you are correct in that, as ncurses at least until recently didnt have
support for RGB colors. However the ANSI escape code itself is capable
of supporting true color as you know. But yes, I think these are not
really suitable for detection without RGB. And RGB is not suitable for
other reasons, discussed below.
>
> It has a link to ncurses, but the hint to find "RGB" does not work,
> there is no info related to RGB there. Perhaps the link is oudated.
> I'll have to search around if these values can be used.
different TERM values, so it was decided not to adopt it. You can see
some discussion here:
https://github.com/kovidgoyal/kitty/commit/18fe2e8dfa34038aabd5c3a2fdb3624e2b27932a
This reminds me that you can use the non-standard (aka not blessed by
Dickey) properties setrgbb/setrgbf. These are what neovim uses if memory
serves. xterm-kitty has them as shown below:
```
infocmp -1 -x xterm-kitty | grep -i rgb
initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
setrgbb=\E[48:2:%p1%d:%p2%d:%p3%dm,
setrgbf=\E[38:2:%p1%d:%p2%d:%p3%dm,
```
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
> copy it from `:h xterm-true-color` (and use `:` or `;` depending on what kitty actually uses, according to https://github.com/termstandard/colors it seems to support either one).
The semicolon based form makes it impossible to combine setting RGB
colors with setting other SGR style attributes in one escape code.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
Oh and just for the record, I will mention one trick I have used personally in my vimrc for many years for RGB colors and improved performance. Basically you add escape codes to the t_ti setting to change the default background/foreground of the terminal emulator to the colors used by your color scheme. Then you run "hi Normal NONE" to remove all colors from the normal style. And add codes to reset the colors to t_te.
This has the advantage of allowing not requiring vim to set the colors for blank cells since the default color already matches. I noticed significant performance improvements with this trick over a slower network. Sadly I dont have the perf numbers with me.
In theory vim could use this trick out of the box.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
How much does a pardon cost in the US?
Applications generally will not be considered unless the applicant has been discharged from probation or parole for at least 10 years without further criminal activity during that period. There is no fee for applying for a pardon.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > It works for me, make sure you do this in the right place. If you have it in your vimrc make sure not setting 'term' after that.
>
> I copy and pasted it verbatim into my vimrc. Did github markdown mangle it before I copied it? I am not setting $TERM after that.
--
ARTHUR: You fight with the strength of many men, Sir knight.
I am Arthur, King of the Britons. [pause]
I seek the finest and the bravest knights in the land to join me
in my Court of Camelot. [pause]
You have proved yourself worthy; will you join me? [pause]
You make me sad. So be it. Come, Patsy.
BLACK KNIGHT: None shall pass.
The Quest for the Holy Grail (Monty Python)
/// 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 cant speak for other terminal emulator authors, but I personally have
> given up trying to get anything into terminfo. That said if terminfo
> were to grow a property for this I would of course add it to kitty's
> terminfo.
make things very messy and take us into the wrong direction. See below.
> This reminds me that you can use the non-standard (aka not blessed by
> Dickey) properties setrgbb/setrgbf. These are what neovim uses if memory
> serves. xterm-kitty has them as shown below:
>
> ```
> infocmp -1 -x xterm-kitty | grep -i rgb
> initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
> setrgbb=\E[48:2:%p1%d:%p2%d:%p3%dm,
> setrgbf=\E[38:2:%p1%d:%p2%d:%p3%dm,
> ```
somehow make this work.
One of the main problems appears to be that for new features there is no
right way to get them supported. Everybody comes up with workarounds,
an tell others how to use them. Which makes some people think this is
the official way, while it is actually built upon a workaround.
In Vim I have added the builtin xterm termcap, because there were too
many systems with an incomplete or even wrong terminfo/termcap. Over
time various xterm features have been added, quite often with invented
termcap codes, since they didn't exist. This worked OK, the entries
have not change very often and xterm doesn't change that much.
Other terminals popped up, quite a few more than I expected in the past.
And they added new features, quite often at least the ones that xterm
has. And since the terminal developers ran into similar problems with
terminfo/termcap, they started taking advantage of the builtin xterm
termcap entries, so that with Vim their fancy features worked without
the user having to manually tweak their config. Usually by prefixing
"xterm" to the value of $TERM.
Now this mostly worked well, until users found that some things did not
work properly. Then usually blaming Vim, before it was figured out that
the builtin termcap entry works for xterm, but not for that particular
terminal. The solution usually meant making some hard coded exception
in Vim, just because it was the simplest solution. Not that it was the
right solution.
By now all this has put us in a very messy position. We have $TERM
values that start with "xterm" even though the terminal is not an xterm.
Sometimes the terminal isn't really xterm compatible, as we have with
this kitty issue right now. And various things in Vim are hard coded,
and the number of exceptions has a tendency to grow and takes into an
even worse position.
Now, what can we do? And I don't mean right now but longer term. I
actually think we need to stop making short term fixes and workarounds,
because it takes away the motivation to solve it properly.
1. Keep using the xterm termcap entries for anything that looks like an
xterm and then make workarounds and fixes for the things that don't
work. This is basically what we have now.
This is not a real solution, puts a lot of maintenance responsibility
into Vim. Other applications, especially editors, will have to find
their own solution, thus the total amount of work is huge and the
chance of things not working properly (aka bugs) is very big. I
generally consider this a dead end.
2. Add a way for the application to directly request properties from the
terminal. This requires using an API (which may be similar to what
is currently used for terminfo) and a communication channel. A huge
advantage is that no matter what configuration options the terminal
has, what version is being used, what no matter terminal name is set,
the application will get the current and accurate values. This
sounds like an ideal long term solution. What is blocking this is
the communication channel, there is no good solution for this (yet).
3. Rely on terminfo/termcap. This requires figuring out what the current
problems are and solving them. This actually sounds simple, but
then: why hasn't this happened yet? Why has nobody managed to get
this going? I would think that with the right changes and enough
developers agreeing on using them and some implementation work
(likely very little) this could take us into a much better situation,
avoiding nearly all the workarounds.
4. Give up on a generic solution and adding all kinds of workarounds
inside Vim. This likely means adding more builtin termcap entries
and some way to select which one to use for what terminal.
The recently added support for keyboard protocols is an example. The
'keyprotocol' option can be used to tune this, but the default should
work for most users (and the default would need to be tuned over time
to match various terminals). Depending on this a set of termcap
entries is then selected to control the key protocol used.
This is just one feature, we would need a dozen more (setting colors,
underline style, bracketed paste, etc.).
I would think this is the "if everything else fails" solution. It's
going to be a lot of maintenance in Vim, and every other application
will run into the same problems and will have to find their own
solution.
5. Somehow combine the builtin xterm termcap entries with what is found
in terminfo. I actually don't know how to do this. And it will run
into the problem that terminfo has no entries for quite a few things.
This is likely to not lead to a good long term solution, and a mix of
Vim workarounds and hard coded stuff. A combination of the solutions
and drawbacks of other solutions.
There are probably some more ways to tackle this and variants of the
above. I would not worry about variants too much, but if there is a
real alternative missing it would be good to hear.
In my opinion the first thing to work on right now is the third one:
Make terminfo work as it should. I have not found useful information
about why this hasn't happened yet. That is the first to dig up.
--
ARTHUR: What?
BLACK KNIGHT: None shall pass.
this bridge.
BLACK KNIGHT: Then you shall die.
The Quest for the Holy Grail (Monty Python)
/// 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.
Kovid Goyal
>
> [...]
>
> > I cant speak for other terminal emulator authors, but I personally have
> > given up trying to get anything into terminfo. That said if terminfo
> > were to grow a property for this I would of course add it to kitty's
> > terminfo.
>
> We need a plan to get this going again. All the workarounds start to
> make things very messy and take us into the wrong direction. See below.
to agree to add properties to terminfo. It took him nearly a decade to
add support for truecolor and when he did his implementation was tied to
ncurses internal structure and wasn't fit for purpose (it requires end
users to set TERM before running individual terminal programs to a different value
based on whether the program in question supports truecolor or not).
But if you wish to try, I think you said you have a good relationship
with him, I will be happy to provide any assistance needed.
>
> > This reminds me that you can use the non-standard (aka not blessed by
> > Dickey) properties setrgbb/setrgbf. These are what neovim uses if memory
> > serves. xterm-kitty has them as shown below:
> >
> > ```
> > infocmp -1 -x xterm-kitty | grep -i rgb
> > initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
> > setrgbb=\E[48:2:%p1%d:%p2%d:%p3%dm,
> > setrgbf=\E[38:2:%p1%d:%p2%d:%p3%dm,
> > ```
>
> This looks like what Vim is using as t_8f and t_8b. Perhaps we can
> somehow make this work.
them. They are basically meant just for this.
>
> One of the main problems appears to be that for new features there is no
> right way to get them supported. Everybody comes up with workarounds,
> an tell others how to use them. Which makes some people think this is
> the official way, while it is actually built upon a workaround.
A few of us tried setting up a new authority but it went down in flames.
https://gitlab.freedesktop.org/terminal-wg/
>
> In Vim I have added the builtin xterm termcap, because there were too
> many systems with an incomplete or even wrong terminfo/termcap. Over
> time various xterm features have been added, quite often with invented
> termcap codes, since they didn't exist. This worked OK, the entries
> have not change very often and xterm doesn't change that much.
was a long time when the terminal ecosystem was completely stagnant and
basically whatever xterm did was all that mattered. However, this
approach isn't appropriate now.
> There are probably some more ways to tackle this and variants of the
> above. I would not worry about variants too much, but if there is a
> real alternative missing it would be good to hear.
to turn on/off various things based on each individual case. Some things
can be queried via escape codes, such as the keyboard protocol. In such
cases you can use the querying mechanism.
This obviously is less than optimal but given the lack of
co-ordination/standards in this space it's all there is.
For the current situation, I would suggest the following way which isn't
in your list.
1) Turn on bracketed paste, focus events and cursor
shape/color controls always, unless the TERM value is in a blacklist.
This blacklist will be very small and grow smaller over time. It is easy
to maintain.
All of these involve sending CSI escape codes to the terminal. CSI
escape codes are fairly safe, all terminals parse them correctly and
most will simply ignore ones they dont know about. You will gather proof
of that since you are now sending the kitty keyboard protocol CSI codes.
The failure mode for them ignoring the codes is not catastrophic, and is
anyway something you can easily tell your users to report to their
terminal developers since vim does it unconditionally apart from a small
blacklist.
2) For the t_ut issue, turn it on only if bce is in the actual terminfo
database of the terminal you are running on. Or if that is too difficult
to implement, then just use your pre 9.0.1073 strategy and add a black
list of TERM values. Not implementing bce is an uncommon choice
currently, so hopefully the black list will not grow too large. You can
start with putting xterm-kitty and kitty in it. If in the future more
terminals follow kitty, you can change this strategy.
2.5) You can also query bce using xterms XTTGETTCAP mechanism (i.e.
using escape codes). However these are DCS escape codes and not as safe
to use as CSI ones. If you like I can design a protocol that uses CSI
escape codes to query terminfo properties directly. Then assuming other
terminals implement this protocol you can use it to query terminfo
without going through the chokepoint of Dickey. Or you can roll the dice
and use DCS, I think currently the only major terminal that has issues
with it is Apple's Terminal.app.
3) For truecolor use the setrgb properties discussed above. Or query the
terminal by setting the color and using DECRQSS escape code to query the
current color. This is described here: https://github.com/termstandard/colors#querying-the-terminal
> In my opinion the first thing to work on right now is the third one:
> Make terminfo work as it should. I have not found useful information
> about why this hasn't happened yet. That is the first to dig up.
properly, which is why you went down the route of a private termcap. Now
with far more activity in this space terminfo is completely unsuitable.
Remember that you first have to get Dickey to agree and then wait for
him to implement something and then wait years for Linux distributions,
Apple, etc. to update their packages. kitty has this neat trick where
it always exports the latest terminfo to programs running inside it so
at least this delay is not present. But the problem of Dickey remains.
That said, I am happy to be proved wrong about terminfo.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
And just for completeness, emacs uses the Tc boolean property from terminfo (a non-standard one introduced by tmux)
emacs-mirror/emacs@f30f531
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
How much of the hard-coded customisations can be externalised to editable .vim config files? They can be distributed as part of the Vim runtime files.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> How much of the hard-coded customisations can be externalised to
> editable .vim config files? They can be distributed as part of the
> Vim runtime files.
configuration when using a particular terminal. And preferably the Vim
code and runtime files do not need to be changed to support a particular
terminal.
Also keep in mind there are many applications (call this Na) and many
different terminals (call this Nt). We do not want to configure every
application for every terminal, you end up with Na * Nt combinations.
Not to mention the chance of mistakes and the amount of maintenance work.
I still have good hope to make this work by updating the
terminfo/termcap mechanism. It was made specifically for this kind of
problem, but it has been neglected in the past years. About time to
make it work properly again.
--
Shaw's Principle: Build a system that even a fool can use, and
only a fool will want to use it.
/// 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.
Christopher Plewright
Thanks @brammool That sounds hopeful. Was only suggesting it as an interim possibility as a stepping stone towards that. I think most users wouldn't touch 99% of the runtime files, and Na = 1, ie. Vim. if the Vim project was to maintain a terminfo database, if the ncurses project doesn't keep up. Anyway, I'm now just remembering how many stepping stones end up being the final destination... I'm reading up on https://invisible-island.net/ncurses/#download_database to get my head around that, it has quite the history.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
And here is an update to the kitty FAQ on vim so people can workaround this issue. It contains a (hopefully mostly complete) list of vim terminal settings that vim fails to set.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
After looking around for alternatives and reading some of the
discussions and proposals of the past, I have settled down on setting
t_8f and t_8b always. They are non-standard entries and don't belong in
terminfo anyway. They are only used when 'termguicolors' is set, thus
it's up to the user when these termcap entries are actually used. If
they don't work then there likely is no way to make it work anyway, thus
'termguicolors' should be kept off. If the terminal uses different
escape sequences to set RGB colors you'll have to set the termcap
entries yourself. But I haven't found any terminal that needs this.
Adding this to terminfo won't help much, since it takes three parameters
and the API that Vim is using (because older systems don't support the
new mechanisms) only supports up to two parameters. Using one 24-bit
parameter probably won't work either.
The difference with the past is that the entries were only set for an
xterm-like terminal, now they are set for all terminals. Thus there no
longer is need for having $TERM start with "xterm", which takes away one
reason for using this hack.
I'm still working on other entries that are currently in the builtin
xterm termcap, such as bracketed paste support. That requires more
work, since for these it does matter that the terminal supports it.
--
BRIDGEKEEPER: What is the air-speed velocity of an unladen swallow?
ARTHUR: What do you mean? An African or European swallow?
BRIDGEKEEPER: Er ... I don't know that ... Aaaaarrrrrrggghhh!
BRIDGEKEEPER is cast into the gorge.
"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.
Bram Moolenaar
> And here is an update to the kitty FAQ on vim so people can workaround
> this issue. It contains a (hopefully mostly complete) list of vim
> terminal settings that vim fails to set.
>
> https://github.com/kovidgoyal/kitty/blob/master/docs/faq.rst#using-a-color-theme-with-a-background-color-does-not-work-well-in-vim
preferences (such as setting the 'mouse' option), setting options that
were already the right value (such as 'ttymouse'), some misleading
comments and omits all the things that Kitty does wrong. It is also
missing version numbers and forgets to mention that part of the problem
is that kitty sets $TERM to "xterm-kitty", indicating it is xterm
compatible, while it isn't. Thus it tells Vim to use xterm termcap
entries and then complains that they are wrong for kitty (e.g. the
back_color_erase flag will have the wrong value). Well, that's caused
by the $TERM value, not by Vim.
I'm trying to figure out ways to get away from workarounds and manually
setting options, but there is a long history of terminal authors not
agreeing on proper solutions, hacks that got adopted by more than a few,
etc. The terminfo database is lacking a lot of this because if
disagreements and unpleasant discussions. Which means we are currently
in a bad starting position, it will take effort to get back on track.
For example, the code to set the underline color was added to the
builtin xterm termcap. Since no termcap entry name was known,
terminfo/termcap do not appear to have an entry for this, Vim uses t_AU.
Terminals pretend to be xterm compatible, so that the Vim builtin xterm
code gets used. This is all wrong, the proper solution is to add a
terminfo/termcap entry for this string. I don't know why this
particular one is missing, it should be really simple to add (the
setaf/AF and setab/AB entries exist, why not just add setau/AU ?).
So this is not because Vim is not able to detect features, this is
because terminal authors have not added the possibility to detect
features. Every application has this problem and having each
application coding their own solution is the wrong strategy. It is very
disappointing to see lots of effort has been put in adding features to
terminals and very little has been done making it possible for
applications to actually use these features.
--
Every exit is an entrance into something else.
/// 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.
Kovid Goyal
Please take this text with a grain of salt. It is a mix of personal preferences (such as setting the 'mouse' option), setting options that were already the right value (such as 'ttymouse'),
Nope, vim does not set ttymouse for xterm-kitty before 9.0.1080 and I doubt it sets it after it for other TERM values. Since all terminals actually support SGR for mouse reporting these days, it makes perfect sense to set it unconditionally.
some misleading comments and omits all the things that Kitty does wrong.
Yeah, in YOUR opinion. You've already added what you think of kitty in the vim FAQ, am returning the favor.
It is also missing version numbers
I have zero interest in tracking the random version numbering scheme you use for vim
and forgets to mention that part of the problem is that kitty sets $TERM to "xterm-kitty",
That's a problem for YOU because you think seeing TERM=xterm* is a license to ignore the actual terminfo. A mistake you seem to have finally realized you need to correct.
indicating it is xterm compatible, while it isn't.
No terminal other than xterm itself is xterm compatible. And even xterm is not xterm compatible because most of its features can be configured away by the user.
Thus it tells Vim to use xterm termcap entries and then complains that they are wrong for kitty (e.g. the back_color_erase flag will have the wrong value). Well, that's caused by the $TERM value, not by Vim.
Nope that's cause by vim hardcoding its terminfo for xterm* instead of using the actual terminfo database, because apparently its too hard to read the terminfo database and use hardocded values as fallbacks. Which is BASIC design.
So this is not because Vim is not able to detect features,
It's because you refused to use the existing properties for it. Which I pointed out to you. setrgf/b and Tc. Used by emacs, neovim, tmux, just not vim.
this is because terminal authors have not added the possibility to detect features. Every application has this problem and having each application coding their own solution is the wrong strategy. It is very disappointing to see lots of effort has been put in adding features to terminals and very little has been done making it possible for applications to actually use these features.
I agree that really sucks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
It contains a (hopefully mostly complete) list of vim terminal features that vim fails to support out of the box.
Thanks to @kovidgoyal for compiling this list, but... why can we not just revert patches 1073/1080 instead of making the kitty users carry around a massive list of settings?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > Please take this text with a grain of salt. It is a mix of personal
> > preferences (such as setting the 'mouse' option), setting options
> > that were already the right value (such as 'ttymouse'),
>
> Nope, vim does not set ttymouse for xterm-kitty before 9.0.1080 and I
> doubt it sets it after it for other TERM values. Since all terminals
> actually support SGR for mouse reporting these days, it makes perfect
> sense to set it unconditionally.
"sgr" when $TERM is "xterm-kitty". Perhaps there was a small range of
versions where it didn't work, but it worked in the past and it works
now.
Many terminals do not support SGR mouse reporting. I don't know what
"these days" means for you, Vim supports as many systems as possible,
also ones that are more than ten years old. Have a look at the possible
values for 'ttymouse' and it's clear that setting it to "sgr" will cause
problems for quite a few users.
> > some misleading comments and omits all the things that Kitty does wrong.
>
> Yeah, in YOUR opinion. You've already added what you think of kitty in
> the vim FAQ, am returning the favor.
>
> > It is also missing version numbers
>
> I have zero interest in tracking the random version numbering scheme
> you use for vim
made in this FAQ entry only apply to a short range of patches, or do not
apply before or after a certain patch level. You are not helping users
by leaving this information out.
> > and forgets to mention that part of the problem is that kitty sets
> > $TERM to "xterm-kitty",
>
> That's a problem for YOU because you think seeing TERM=xterm* is a
> license to ignore the actual terminfo. A mistake you seem to have
> finally realized you need to correct.
everybody else is doing it wrong. I think this is the root of the
problem we need to deal with.
> > indicating it is xterm compatible, while it isn't.
>
> No terminal other than xterm itself is xterm compatible. And even
> xterm is not xterm compatible because most of its features can be
> configured away by the user.
support kitty that we get into trouble.
> > Thus it tells Vim to use xterm termcap entries and then complains
> > that they are wrong for kitty (e.g. the back_color_erase flag will
> > have the wrong value). Well, that's caused by the $TERM value, not
> > by Vim.
>
> Nope that's cause by vim hardcoding its terminfo for xterm* instead of
> using the actual terminfo database, because apparently its too hard to
> read the terminfo database and use hardocded values as fallbacks.
> Which is BASIC design.
that it would use the terminfo entries. However, several entries that
kitty relies on do not exist in terminfo/termcap. Which I believe was
the reason for prefixing "xterm" to $TERM, so that the Vim builtin xterm
entries were used. Now that I have disabled it we get all kinds of
complaints. Thus we can't do it right with the current choices
available. Which is what I am trying to fix.
> > So this is not because Vim is not able to detect features,
>
> It's because you refused to use the existing properties for it. Which
> I pointed out to you. setrgf/b and Tc. Used by emacs, neovim, tmux,
> just not vim.
those to some terminfo entries, but they are not widely used. I could
not find documentation for the meaning of the "Tc" flag. I don't
understand the use of it,
This is part of the problem: some applications come up with random
terminfo names, start using them, and then somehow claim they are
official entries and everybody should use them. This doesn't work.
I understand that the whole true-color discussion did not lead to a good
solution. There is some documentation of the "RGB" flag, but what it
does is, well, weird and useless. It seems the people involved got so
frustrated and discussions went into blaming people, with the result
that a proper solution was never made.
> > this is because terminal authors have not added the possibility to
> > detect features. Every application has this problem and having each
> > application coding their own solution is the wrong strategy. It is
> > very disappointing to see lots of effort has been put in adding
> > features to terminals and very little has been done making it
> > possible for applications to actually use these features.
>
> I agree that really sucks.
others, to be constructive and try to find a good, long-term solution.
As I mentioned earlier, the first try is to make terminfo work as well
as we can. It is an existing mechanism and adding entries is simple
enough. The bottleneck is in agreeing on what entries to add and what
they mean, something we should be able to work out.
--
It is illegal for a driver to be blindfolded while operating a vehicle.
[real standing law in Alabama, United States of America]
/// 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.
chdiza
Side note: in that big list of things to set, there is this:
execute "set <FocusGained>=\<Esc>[I"
execute "set <FocusLost>=\<Esc>[O"
Are <FocusGained> and <FocusLost> vim options? They don't appear in the output of :set<CR>. There is no documentation for either of those in the vim help; there are just a couple of spots where the above settings are advised. Nowhere does the vim help say what the are.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
>
> > > Please take this text with a grain of salt. It is a mix of personal
> > > preferences (such as setting the 'mouse' option), setting options
> > > that were already the right value (such as 'ttymouse'),
> >
> > Nope, vim does not set ttymouse for xterm-kitty before 9.0.1080 and I
> > doubt it sets it after it for other TERM values. Since all terminals
> > actually support SGR for mouse reporting these days, it makes perfect
> > sense to set it unconditionally.
>
> The "/usr/bin/vi" on my system is 8.2.4919 and it sets 'ttymouse' to
> "sgr" when $TERM is "xterm-kitty". Perhaps there was a small range of
> versions where it didn't work, but it worked in the past and it works
> now.
with *kitty* or with any poor new terminal that does not pay the xterm
tax and set its TERM to xterm*. Proof
TERM=bramterm vim --clean
:set ttymouse?
ttymouse=
>
> Many terminals do not support SGR mouse reporting. I don't know what
> "these days" means for you, Vim supports as many systems as possible,
> also ones that are more than ten years old. Have a look at the possible
> values for 'ttymouse' and it's clear that setting it to "sgr" will cause
> problems for quite a few users.
superseded by sgr. No current terminal (by this I mean a terminal that
is actively maintained at this time) I know of supports one of those
legacy ones but not sgr. If you know of one do let me know and I will
add a note about it to the FAQ.
>
> > > some misleading comments and omits all the things that Kitty does wrong.
> >
> > Yeah, in YOUR opinion. You've already added what you think of kitty in
> > the vim FAQ, am returning the favor.
> >
> > > It is also missing version numbers
> >
> > I have zero interest in tracking the random version numbering scheme
> > you use for vim
>
> The Vim patch numbering is very simple and clear. Some of the remarks
> made in this FAQ entry only apply to a short range of patches, or do not
> apply before or after a certain patch level. You are not helping users
> by leaving this information out.
any semantic meaning. The vimrc additions I suggest will work in any vim
version old or new as long as its new enough that those properties
exist. So probably not vim 1 :) Adding revision numbers to them is
pointless. But sure if you send me a PR adding revision numbers to the
FAQ entry I promise to merge it.
>
> > > and forgets to mention that part of the problem is that kitty sets
> > > $TERM to "xterm-kitty",
> >
> > That's a problem for YOU because you think seeing TERM=xterm* is a
> > license to ignore the actual terminfo. A mistake you seem to have
> > finally realized you need to correct.
>
> This is not a place to make statements that you know everything and
> everybody else is doing it wrong. I think this is the root of the
actual terminfo database when TERM=xterm*, is wrong. I stand by that
statement.
> problem we need to deal with.
>
> > > indicating it is xterm compatible, while it isn't.
> >
> > No terminal other than xterm itself is xterm compatible. And even
> > xterm is not xterm compatible because most of its features can be
> > configured away by the user.
>
> This has worked well for a long time. It's only now that we try to
> support kitty that we get into trouble.
9.0.1080. I will continue to deal with the t_ut issue for kitty users as
I have been for nearly a decade.
>
> > > Thus it tells Vim to use xterm termcap entries and then complains
> > > that they are wrong for kitty (e.g. the back_color_erase flag will
> > > have the wrong value). Well, that's caused by the $TERM value, not
> > > by Vim.
> >
> > Nope that's cause by vim hardcoding its terminfo for xterm* instead of
> > using the actual terminfo database, because apparently its too hard to
> > read the terminfo database and use hardocded values as fallbacks.
> > Which is BASIC design.
>
> I actually stopped using the builtin xterm termcap entries for Kitty, so
> that it would use the terminfo entries. However, several entries that
> kitty relies on do not exist in terminfo/termcap. Which I believe was
> the reason for prefixing "xterm" to $TERM, so that the Vim builtin xterm
> entries were used. Now that I have disabled it we get all kinds of
> complaints. Thus we can't do it right with the current choices
> available. Which is what I am trying to fix.
I will tell users how to fix the issue for themselves. Once that
changes, I will remove the FAQ entry.
>
> > > So this is not because Vim is not able to detect features,
> >
> > It's because you refused to use the existing properties for it. Which
> > I pointed out to you. setrgf/b and Tc. Used by emacs, neovim, tmux,
> > just not vim.
>
> "setrgbf" and "setrgbb" are not valid entries. Someone started adding
> those to some terminfo entries, but they are not widely used. I could
> not find documentation for the meaning of the "Tc" flag. I don't
> understand the use of it,
>
> This is part of the problem: some applications come up with random
> terminfo names, start using them, and then somehow claim they are
> official entries and everybody should use them. This doesn't work.
>
> I understand that the whole true-color discussion did not lead to a good
> solution. There is some documentation of the "RGB" flag, but what it
> does is, well, weird and useless. It seems the people involved got so
> frustrated and discussions went into blaming people, with the result
> that a proper solution was never made.
come up with a workable alternative for vim. I have repeatedly told you
what would be a workable solution in my opinion. You dont like my ideas,
that's fine. But until you come up with a solution you do actually like
I have to make it possible for kitty users to use vim.
>
> > > this is because terminal authors have not added the possibility to
> > > detect features. Every application has this problem and having each
> > > application coding their own solution is the wrong strategy. It is
> > > very disappointing to see lots of effort has been put in adding
> > > features to terminals and very little has been done making it
> > > possible for applications to actually use these features.
> >
> > I agree that really sucks.
>
> I would suggest that instead of blaming and throwing mud around at
> others, to be constructive and try to find a good, long-term solution.
> As I mentioned earlier, the first try is to make terminfo work as well
> as we can. It is an existing mechanism and adding entries is simple
> enough. The bottleneck is in agreeing on what entries to add and what
> they mean, something we should be able to work out.
adopt a property and as I stated before, several times, kitty will add
it to its terminfo immediately (provided of course its not something
completely unuseable like the RGB flag). I have also offered to add
non-standard properties you want for vim. Or to design an escape code
protocol to query them that works more robustly than XTGETTCAP, but you
were not interested. So you tell me what we do next. I stand here ready
to co-operate.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
i just saw a joke which make me 🤣 i'd like to share with you all..
// i was thinking what's the most official vim advantage.....
// please continue to discuss the better solution, and nice. :-)
// as for @chdiza after v9.0.1111 i think tgc is working for kitty which those workaround.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
> > It contains a (hopefully mostly complete) list of vim terminal features that vim fails to support out of the box.
>
Yes, that would be much preferable. But Bram doesnt want to do that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
> Side note: in that big list of things to set, there is this:
> ```
> execute "set <FocusGained>=\<Esc>[I"
> execute "set <FocusLost>=\<Esc>[O"
> ```
>
As I understand it, they are events. So what the lines above do is make
vim dispatch those events when it sees the bytes on the right hand side
of the = sign.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > It contains a (hopefully mostly complete) list of vim terminal
> > features that vim fails to support out of the box.
>
> Thanks to @kovidgoyal for compiling this list, but... why can we not
> just revert patches 1073/1080 instead of making the kitty users carry
> around a *massive* list of settings?
Instead of using a half-fix, broken workaround, or whatever you want to
call it I want to fix this properly now. I had hoped that some people
would pick up this work, but it appears that since the hack/workaround
worked well enough the problem has remained and we keep making small
fixes on top of a messy solution, taking us into a wrong direction
with no hope of a long-term solution. Thus we need to break it to get
it fixed.
It will take some time to fix each part properly. Also keep in mind
that these settings are not needed for other terminals, it's really a
problem with Kitty.
--
Men may not be seen publicly in any kind of strapless gown.
[real standing law in Florida, United States of America]
/// 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
> Side note: in that big list of things to set, there is this:
> ```
> execute "set <FocusGained>=\<Esc>[I"
> execute "set <FocusLost>=\<Esc>[O"
> ```
>
> Are `<FocusGained>` and `<FocusLost>` vim options? They don't appear
> in the output of `:set<CR>`. There is no documentation for either of
> those in the vim help; there are just a couple of spots where the
> above settings are advised. Nowhere does the vim help say what the
> *are*.
more readable. At some point they were also made available to set the
options.
They are indeed not listed in the help, I'll make a note of that. Not
sure yet how to make them easy to find, there is overlap with other
functionality, e.g. "FocusGained" is also an autocommand event name.
Including <> in the tag name might work.
--
The Law, in its majestic equality, forbids the rich, as well as the
poor, to sleep under the bridges, to beg in the streets, and to steal
bread. -- Anatole France
/// 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.
chdiza
Most of the settings are actually not needed, as I pointed out earlier.
I'm not sure why you're saying this. I compared Kovid's list with the output of :set termcap (making sure I did not have anything from his list in my vimrc, apart from t_ut). Setting aside the codes for truecolor stuff (8f, 8b, 8u) because a new patch just built those in, and setting aside t_ut, his list differs from :set termcap on every single code. In every case but one (t_ds), :set termcap shows it to be empty or doesn't show it at all.
Did you mean that the relevant functionality doesn't require Kovid's term codes to be set in vimrc? Or did you mean to say that most things on Kovid's list already match what is in :set termcap. If the latter, it's false. If the former, I am skeptical. E.g., cursor shape won't change when going between normal/insert/replace unless I put what Kovid has in my vimrc.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
Not sure yet how to make them easy to find, there is overlap with other functionality, e.g. "FocusGained" is also an autocommand event name. Including <> in the tag name might work.
I don't think you need a <FocusGained> help tag specifically. There should perhaps be something in the help for the :set cmd that shows e.g. a table of everything like that one could set.
—
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 settings are actually not needed, as I pointed out earlier.
>
> I'm not sure why you're saying this. I compared Kovid's list with the
> output of `:set termcap` (making sure I did not have anything from his
> list in my vimrc, apart from t_ut). Setting aside the codes for
> truecolor stuff (8f, 8b, 8u) because a new patch just built those in,
> *every single code*. In every case but one (t_ds), `:set termcap`
> shows it to be empty or doesn't show it at all.
> Did you mean that the relevant functionality doesn't require Kovid's
> term codes to be set in vimrc? Or did you mean to say that most
> the latter, it's false. If the former, I am skeptical. E.g., cursor
> shape won't change when going between normal/insert/replace unless I
> put what Kovid has in my vimrc.
already set properly. I haven't checked the whole list.
The cursor shape settings are user preferences, not terminfo/termcap
values.
Anyway, feel free to include the whole list. It will probably work for
now. But it's a mix of user preferences and useful codes. I can't use
these values as defaults, users would complain.
--
It is illegal to rob a bank and then shoot at the bank teller with a water
pistol.
[real standing law in Louisana, United States of America]
/// 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
> > Not sure yet how to make them easy to find, there is overlap with
> > other functionality, e.g. "FocusGained" is also an autocommand event
> > name. Including <> in the tag name might work.
>
> I don't think you need a `<FocusGained>` help tag specifically. There
> should perhaps be something in the help for the `:set` cmd that shows
The table is below ":help terminal-options".
--
Biting someone with your natural teeth is "simple assault," while biting
someone with your false teeth is "aggravated assault."
[real standing law in Louisana, United States of America]
/// 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.
chdiza
The table is below ":help terminal-options".
But it doesn't say anything about <FocusGained> (or lost, or any other constructs). I think you can add a description of those but not worry about tagging them. A user can find that with :helpgrep if needed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
chdiza
The cursor shape settings are user preferences, not terminfo/termcap values.
I don't quite understand that distinction, but given that kitty is the only terminal I've ever used that didn't have cursor shape changes/blinking stuff working correctly out of the box, I would be surprised if there were complaints if those were to become baked in.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
1, most others in that kovid's workaround list in the list is required to manually set something too for gnu-screen, but just if it ran based on xterm-like terminal it had default value.
2, looks except bracketed paste, per on the reproduce steps in #10632 i saw kitty (v0.21.2) also No raw key input: "�[200~foo�[201~" esc chars around with foo same like gnu-screen.
// so it really was a problem of terminal (or something like gnu-screen) or vim?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Kovid Goyal
>
> > > It contains a (hopefully mostly complete) list of vim terminal
> > > features that vim fails to support out of the box.
> >
> > Thanks to @kovidgoyal for compiling this list, but... why can we not
> > just revert patches 1073/1080 instead of making the kitty users carry
> > around a *massive* list of settings?
>
>
> Instead of using a half-fix, broken workaround, or whatever you want to
> call it I want to fix this properly now. I had hoped that some people
> would pick up this work, but it appears that since the hack/workaround
> worked well enough the problem has remained and we keep making small
> fixes on top of a messy solution, taking us into a wrong direction
> with no hope of a long-term solution. Thus we need to break it to get
> it fixed.
revert 9.0.1080 people need to be able to use vim.
>
> It will take some time to fix each part properly. Also keep in mind
> that these settings are not needed for other terminals, it's really a
> problem with Kitty.
use xterm* for TERM.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > The table is below ":help terminal-options".
>
> But it doesn't say anything about `<FocusGained>` (or lost, or any
> other constructs). I think you can add a description of those but not
> worry about tagging them. A user can find that with :helpgrep if
> needed.
terminal-options is a relevant place.
--
Close your shells, or I'll kill -9 you
Tomorrow I'll quota you
Remember the disks'll always be full
And then while I'm away
I'll write ~ everyday
And I'll send-pr all my buggings to you.
[ CVS log "Beatles style" for FreeBSD ports/INDEX, Satoshi Asami ]
/// 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
> > The cursor shape settings are user preferences, not terminfo/termcap values.
>
> I don't quite understand that distinction, but given that kitty is the
> changes/blinking stuff working correctly out of the box, I would be
> surprised if there were complaints if those were to become baked in.
only used in a terminal window.
What you are probably referring to are the codes that Vim outputs when
changing into and out of Insert and Replace mode. These do not have
default values, you have to set them yourself.
See ":help termcap-cursor-color".
Users may have various ways to set the cursor color and shape, it would
be bad for Vim to overrule that without asking.
--
Yesterday, all my deadlines seemed so far away
now it looks as though it's freeze in four days
oh I believe in cvs..
[ CVS log "Beatles style" for FreeBSD ports/INDEX, Satoshi Asami ]
/// 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
so looks there would be no good conclusion shortly :-), but anyway there was workaround mostly.
// this is the last day of 2022, happy new year anyway~ 😄
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.