can't type with TERM=xterm-kitty

[tomkel]

When using kitty terminal, I can press hotkeys, but I can't type in any text entry.
I can hit ! to open the shell command line, but then I can't type the command.
I can hit / to open a search, but I can't type anything to search.

However if I set TERM=xterm-256color in kitty, I can type and search again.

TERM=xterm-256color LESSNOCONFIG="-" /opt/homebrew/bin/less /usr/share/dict/words

I installed less with brew install less on macOS. I'm running less v691.

[tomkel]

Here is the difference in terminfo, if that is helpful

> /opt/homebrew/opt/ncurses/bin/infocmp -dx xterm-256color xterm-kitty

comparing xterm-256color to xterm-kitty.
    comparing booleans.
		OTbs: T:F.
		bce: T:F.
		bw: F:T.
		hs: F:T.
		AX: T:F.
		Su: F:T.
		Tc: F:T.
		XT: T:F.
		fullkbd: F:T.
    comparing numbers.
		pairs: 65536, 32767.
    comparing strings.
		acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', '++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'.
		blink: '\E[5m', NULL.
		cnorm: '\E[?12l\E[?25h', '\E[?12h\E[?25h'.
		dsl: NULL, '\E]2;\E\\'.
		fsl: NULL, '^G'.
		invis: '\E[8m', NULL.
		is2: '\E[!p\E[?3;4l\E[4l\E>', NULL.
		kBEG: NULL, '\E[1;2E'.
		ka1: '\EOw', ''.
		ka3: '\EOy', ''.
		kb2: '\EOu', NULL.
		kc1: '\EOq', ''.
		kc3: '\EOs', ''.
		kent: '\EOM', NULL.
		kf15: '\E[1;2R', '\E[13;2~'.
		kf27: '\E[1;5R', '\E[13;5~'.
		kf39: '\E[1;6R', '\E[13;6~'.
		kf51: '\E[1;3R', '\E[13;3~'.
		kf63: '\E[1;4R', '\E[13;4~'.
		khlp: NULL, ''.
		kmous: '\E[<', '\E[M'.
		kund: NULL, ''.
		mc0: '\E[i', NULL.
		mc4: '\E[4i', NULL.
		mc5: '\E[5i', NULL.
		meml: '\El', NULL.
		memu: '\Em', NULL.
		mgc: '\E[?69l', NULL.
		nel: '\EE', NULL.
		rmcup: '\E[?1049l\E[23;0;0t', '\E[?1049l'.
		rmkx: '\E[?1l\E>', '\E[?1l'.
		rmm: '\E[?1034l', NULL.
		rs1: '\Ec\E]104\007', '\E]\E\\\Ec'.
		rs2: '\E[!p\E[?3;4l\E[4l\E>', NULL.
		sgr: '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m', '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m'.
		smcup: '\E[?1049h\E[22;0;0t', '\E[?1049h'.
		smglp: '\E[?69h\E[%i%p1%ds', NULL.
		smglr: '\E[?69h\E[%i%p1%d;%p2%ds', NULL.
		smgrp: '\E[?69h\E[%i;%p1%ds', NULL.
		smkx: '\E[?1h\E=', '\E[?1h'.
		smm: '\E[?1034h', NULL.
		tsl: NULL, '\E]2;'.
		E3: '\E[3J', NULL.
		Ms: '\E]52;%p1%s;%p2%s\007', '\E]52;%p1%s;%p2%s\E\\'.
		Setulc: NULL, '\E[58:2:%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m'.
		Smulx: NULL, '\E[4:%p1%dm'.
		Sync: NULL, '\EP=%p1%ds\E\\'.
		XM: '\E[?1006;1000%?%p1%{1}%=%th%el%;', NULL.
		kBEG3: NULL, '\E[1;3E'.
		kBEG4: NULL, '\E[1;4E'.
		kBEG5: NULL, '\E[1;5E'.
		kBEG6: NULL, '\E[1;6E'.
		kBEG7: NULL, '\E[1;7E'.
		ka2: '\EOx', NULL.
		kb1: '\EOt', NULL.
		kb3: '\EOv', NULL.
		kc2: '\EOr', NULL.
		kp5: '\EOE', NULL.
		kpADD: '\EOk', NULL.
		kpCMA: '\EOl', NULL.
		kpDIV: '\EOo', NULL.
		kpDOT: '\EOn', NULL.
		kpMUL: '\EOj', NULL.
		kpSUB: '\EOm', NULL.
		kpZRO: '\EOp', NULL.
		rv: '\E\\[>41;[1-6][0-9][0-9];0c', NULL.
		setrgbb: NULL, '\E[48:2:%p1%d:%p2%d:%p3%dm'.
		setrgbf: NULL, '\E[38:2:%p1%d:%p2%d:%p3%dm'.
		xm: '\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;', NULL.
		xr: '\EP>\\|XTerm\\(([1-9][0-9]+)\\)\E\\\\', NULL.

[DiegoBaldassarMilleuno]

I encountered the same issue, seems to be introduced between v685 and v686 (built locally).

[avih]

I encountered the same issue, seems to be introduced between v685 and v686 (built locally).

If you can do git bisect to identify the exact commit where it starts, it can help.

I'm guessing it might be related to adding terminfo support, but there are a lot of commits between 685 and 686, so a bisect should help.

[DiegoBaldassarMilleuno]

On my end it is introduced by b635bc2.

[avih]

On my end it is introduced by b635bc2.

Interesting. And your issue is as described earlier - that you can for instance press / to start a search, but when you then press normal text keys, like a or x and expect them to show at the search input, then it does not get typed, as if you didn't press them at all?

As far as I can tell this commit doesn't make any actual code changes, and only adds new keys which it can identify, so I wouldn't have guessed that it could prevent normal text input from working... but it's still possible.

Thanks.

[DiegoBaldassarMilleuno]

Correct. For instance:

1. press / to start a search
2. type letter keys -> nothing is shown
3. press Return to start the search -> the previous search string is used (as if nothing was typed in)

Here's the result of the bisection for reference:

GOOD v685
BAD  v686
BAD  [a13e486012e0f807c2d938fc593011d67a3c3851] Merge branch 'master' into master
GOOD [03440d45a502da013cb7c7ab55bc4304b7a1d352] Document `-"cc` option in less(1) synopsis.
BAD  [6ca3c73d33a414f9562c3e827bf319b0f15c20fe] Make lesskey support keypad keys.
BAD  [998a60d0af5a82878891be76311fcf2cada742e6] Implement F1 key for help when using termcap or terminfo.
BAD  [b635bc202491304fa7288419cfc290d04dab0e8b] Implement command bindings for keypad keys.
GOOD [7bf5441da53139e834024cd4157915f4ebc0ee9e] Initial work to support terminfo.

Let me know if you need me to test other commits.

[avih]

No need for now. It looks like a good bisect. Thanks.

[gwsw]

Fixed in 18db5ae.

The problem was that the xterm-kitty terminfo entry defines some capabilities as empty strings, rather than just omitting them from the entry. I didn't know that this was allowed, and I don't understand why it's done. It seems to be rare. Among the 119 xterm variants on my system, only xterm-kitty does this.

[avih]

The problem was that the xterm-kitty terminfo entry defines some capabilities as empty strings, rather than just omitting them from the entry.

Does the issue really start at b635bc2 ? If yes, mind explaining roughly how adding few more supported keys end up apparently ignoring normal text keys?

[gwsw]

Some of the new keypad capabilities added in b635bc2 happen to be ones that xterm-kitty defines as empty strings. Less was therefore adding some empty strings into the edittable command table. The command parser doesn't expect to see empty strings in a command table, and it turns out that it thinks that any input string matches an empty string. So when any character was entered in a search string, we would check edittable to see if it was an editing command, and decide that it was indeed one. In fact the EC_END command was the first one that matched, so we would just try to move to the end of the search string rather than entering the character into the string.

This has always been a bug, but apparently no termcap entry defines an empty capability, and very few terminfo entries do so, so it wasn't noticed until now.

[avih]

Appreciated. For what it's worth, if it was my commit, I'd have mentioned at least some of that explanation at the commit message.

But at least the commit message refers to this issue, and this issue now has an explanation, so better than nothing ;)

[tomkel]

Looks like it was done in this commit: kovidgoyal/kitty@27170a4

We could report it as a bug to kitty if you think that's appropriate

Thank you for the fix!

[gwsw]

It seems weird to me for a terminfo entry to have empty capabilities, but I don't think it's a bug. I don't see anything in the terminfo man page that says anything about it one way or the other. But there are a few other terminals that define empty entries, so it's rare but not unique to kitty. In any case, less should now handle the case correctly if it appears in any terminal.