On Mon, 8 Jul 2024, David Leadbeater wrote:>manifestation of the problem. As mentioned in the Kitty issue, shells >should really gain support for input modes.Pretty sure that not. That would totally mess up things like OS/2 console windows and possibly VT100 (hardware) terminals and just look like extra junk spewed before the prompt (also throwing off the shell surrounding the ssh client?s calcula? tion of the input line length / cursor position). bye, //mirabilos -- Infrastrukturexperte ? Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn ? https://www.qvest-digital.com/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 18196 ? USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter N?then
On Mon, 8 Jul 2024 at 12:36, Thorsten Glaser <t.glaser at qvest-digital.com> wrote:> >manifestation of the problem. As mentioned in the Kitty issue, shells > >should really gain support for input modes. > > Pretty sure that not. That would totally mess up things like > OS/2 console windows and possibly VT100 (hardware) terminals > and just look like extra junk spewed before the prompt (also > throwing off the shell surrounding the ssh client?s calcula? > tion of the input line length / cursor position).Older hardware or software terminals will ignore any escape sequences they don't recognise, it won't result in any "extra junk" (I'm using Zsh with the configuration I posted on a VT520 without problem). This is the openssh list so I wasn't going to go into the details of it, but roughly the shell would first detect likely support via $TERM or another method (there are reporting sequences for what key modes are enabled / supported which for example is how Vim does this) then enable the mode if needed. David