Extraenous `5u` appears on the terminal when using fish shell
Funny characters like 5u appear in the qterminal widget when using fish shell. This problem does not seem to occur in konsole or foot.
Note that when you hit enter, this 5u is not a part of the executed command.
Have you tried the latest git?
I did:
$ fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
stef@archlinux ~> 5u
0ustef@archlinux ~5u
Just hitting enter produces an initial 0
Other artefacts when using arrow up to repeat command, it adds the last 2 characters again:
stef@archlinux ~> 5ufunctions fish_promptpt
stef@archlinux ~> 5uls /tmpmp
Sure it's a regression, haven't around Qterminal 2.0 or 2.1 but 1.4 works.
Yes, seeing them now. I just installed fish and entered it in QTerminal to see them.
Checked my debian VM with 2.1:
user@vbox:~$ fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
user@vbox ~> 5u
So it's between 1.4 and 2.1....
So it's between 1.4 and 2.1....
Oh, that's before my text rendering patches; happy to know that I didn't break it :) Thanks for testing!
The issue disappeared here after I used set -Ua fish_features no-keyboard-protocols, exited fish and re-entered it.
But they say that terminals that require no-keyboard-protocols have bug. They may be right, but I have no idea where the supposed bug is; hence keeping this report open.
EDIT: It should be done in Vt102Emulation.cpp. Too complex!
A probably relevant report for Konsole: https://bugs.kde.org/show_bug.cgi?id=423990
Some background information:
- I have been using qtermwidget6 (git:master) for a long time, and it is always updated.
- This problem started after the recent update of my system, which included Qt 6.8.2-3 (I am not sure of the older version), fish from 4.0.0 -> 4.0.1, and a bunch of other things. I am not sure "what other things" might be relevant here.
- I compiled and installed the latest fish (git:master), and the problem is no longer there. However, 4.0.0/4.0.1/4.0.2 all show issues.
Keeping all this in mind, I think there is some underlying issue with QTermWidget, and it was made apparent by some bug in fish and Qt (and potentially other) updates.
I compiled and installed the latest fish (git:master), and the problem is no longer there.
Please see https://github.com/lxqt/qtermwidget/issues/586#issuecomment-2745194143. Probably, they've set no-keyboard-protocols by default.
But the issue is in QTermWidget → Vt102Emulation.cpp.
Supposing that N is an integer (1, 12, 345, …) and L is a letter (a, A, z), XTerm and Konsole don't show anything on entering
printf '\x1b[=NL'
But QTerminal shows NL.
Unfortunately, I have no experience with the kind of code Vt102Emulation.cpp contains, but the fix shouldn't be difficut for those who are familiar with that code. Contribution is needed.
Please see https://github.com/lxqt/qtermwidget/issues/586#issuecomment-2745194143. Probably, they've set no-keyboard-protocols by default.
This is possible. I will look into it.
But the issue is in QTermWidget → Vt102Emulation.cpp.
This is something I might be able to look into. I am working on an ambitious project - deKDEfy the latest Konsole code. While working on this I will pay attention to this \x1b[=NL business.
PS: Once I complete the work on libQonsole, we can talk about integrating the code (whole or a part) into qtermwidget.
This is something I might be able to look into.
Excellent! Looking forward to your PR.
I am working on … deKDEfy the latest Konsole code.
Please note that QTermWidget/Qterminal has become considerably different from Konsole over time. We can't use Konsole codes directly anymore. It may possible to use Konsole's code for finding solutions, but that isn't straightforward. I did so when fixing various kinds of text rendering problems, but adapting their solutions to our code was really cumbersome: it became possible only after I understood the underlying logic.
As for Vt102Emulation.cpp, I'm not familiar with the underlying logic, and IMO, the code doesn't have enough comments.
If I'm not mistaken (https://en.wikipedia.org/wiki/ANSI_escape_code#Control_Sequence_Introducer_commands), a string consisting of the following characters, in the following order, should not be shown:
| Chars | Code/Decimal | Number |
|---|---|---|
| ESC | 27 | One |
| 0–9:;<=>? | 0x30–0x3F (48-63) | Any (including none) |
| SPACE!"#$%&'()*+,-./ | 0x20–0x2F (32-42) | Any (including none) |
@A–Z[\]^_`a–z{|}~ |
0x40–0x7E (64-126) | One |
Thank you for this list. I was looking at processToken function. I think this is where the error is.
I think this is where the error is.
Yes, I suspected it should happen there but found no way to include the above pattern in it. I also played with Vt102Emulation::receiveChar to no avail.
The code has become more acrobatic in Konsole's recent versions ;) However, I understand that this kind of code is dirty by nature, having dealt with similar situations elsewhere.