Terminal text editors are an evolutionary dead-end

This is overall a benefit as there is no way of a program assuming the physical keys are what you want (many games do, even in text input boxes, latest one that I have interacted with that did was the OpenTTD console) which falls into the "make your API hard to misuse" but there

Good games distinguish using physical key codes in actual gameplay, and gracefully giving you text events in input boxes. Point being - terminal programs just don't have this ability at all unless they (and emulator too!) implement some kitty protocol that doesn't really do it all that well and has its own quirks.

I don't want the game to do that, as I have no idea where the [ or whatever key is on my keyboard when it is using the US layout. Just translate it all and let me remap, don't assume everyone knows the US layout.

Ah yeah I know what you mean. As a kid, you would open a game key remap menu, and it would show WASD and I have no fucking clue what WASD is because my keyboard doesn't have English keycaps :D But still, in a lot of cases a program that has enough information can gracefully handle keyboard layout change and not poop itself like neovim or helix do

I guess the best thing would be to use the physical location _and_ show the localized keycaps

Damn it works much better with youtube thumbnail

Thanks for posting this. I hope that someday we can move away from the vt100 and into the modern and multilingual desktop world with our tools.

We already sorta did I guess. Neovim is very niche outside of very narrow tech bubble, and helix (the other editor from the video) is researching gui options, which would fundamentally solve this issue.

Editors are one class of tools that can be run in a terminal. I’m thinking of all the other classes of tools out there.

oh yeah it's also an issue with terminal mail clients, database cliens, and pretty much everything else.

Worse is that they all end up doing inconsistent things with their own terminal control libraries. It’s like the DOS days all over again. Every app works and looks different.

Theoretically, there could be something like kitty keyboard protocol but better, that just straight up forwards physical key codes as is without any preprocessing. But then you'll have 1.5 terminals and programs implementing it maybe in 5 years. And it will still have restrictions and edge cases that aren't handled

“Dead end?” This is rage bait. If someone is using a non English key map they could either implement their input protocol (a-la kitty) or just figure out an input daemon (backed plugged). Terms stick to chars 'cause they're the cross-device (non-just OS) lingua franca. Muted

Why non of the major terminal text editors just do it then? :)

My text editor, Acme, is from 1994, but it's still using 20+ years more modern technology than what people consider good today. It's embarrassing.

Да-да, только теперь ctrl-c/ctrl-v надо отдельно маппить и настраивать. Всё те же костыли. И ctrl-z свернёт редактор кек

И ctrl+z нихуя не свернёт.

почему по-твоему тебя заставляют делать шифт+инсерт ) Это всё костыли. Суть в том, то терминальные приложения не видят нажатия кнопок на клавиатуре. Все способы это обойти ломаются, если на них посмотреть не под тем углом. У mc edit свой набор воркараундов. Здесь нет магии, которую мейнтейнеры неовима или любой другой программы могут просто сделать и все починить, к сожалению

Вот не надо искать проблему не там, где она находится на самом деле. На самом деле все комбинации Ctrl+ и Alt+ должны выдавать нажатия в латинице, как того весь софт и ожидает.

Ты наверное еще думаешь, что на свете бывают только две раскладки - US ANSI и русский ЙЦУКЕН :) Чел, ты либо не понял сути ограничений, либо тебя оно почему-то лично задело.

Ты как раз сам кое-чего не понял: раскладки должны быть для ввода букв, и только для ввода букв. А когда никаких букв подходящих нету в раскладке, то пусть отдают ASCII, чтобы не ломать UI.

Just like chopsticks and non-alphabet languages. :P

Terminals, as a whole, are a dead end. The industry moving back to terminals (e.g., codex) is stupid. They are a subset of GUI programs with historical baggage we don't need. GUIs and human computer interfaces have barely been explored, and yet we are stuck in the 70s 💀.

It's not a dead end! I use a Dvorak variant as my layout but frequently want to insert and edit Turkish or Russian. To do this setup a keymap so that all the VIM keys still work but inserted text is mapped to the other language. Here is my DVP→JCU map:

Very nice vid but I disagree. Terminal editors are quite fit for their purpose as programmer editors capable of thriving in minimalist environments. Programmers use English. I'm bilingual too & my 2nd lang, Czech, kinda sucks with vim too. Solution: I just don't use vim with it.

I'm familiar with the device input mapping (scan codes in this case) across Linux/macOS/Windows and how to solve this problem, I was scrolling before bed and saw this post, so I'll share some code tomorrow which handles everything seamlessly. (I code in C++ mainly, but same same)

How you want to read physical key when you connect using ssh?

Right. I'll just keep using emacs. I have no issues with any glyphs, keyboards, tabs or anything special. thanks though.

i love vim and agree

i fully agree with what you said given that i'm using my own keyboard layout that is not used by almost anyone else:

Very interesting video. But are there real people that only use Terminal for “EVERYTHING”? I mean, I’m a terminal junky but even I only use for specific technical stuff.

With text editors in particular, it's quite stupid to use one text editor "only for code" and then have to have some other editor for writing "normal text" :/

I like my Micro, but sometimes it doesn't recognize the keyboard correctly. Then again, WSL shells are absolutely garbage in that regard anyways, which carries to GUI software too. Oh the workarounds!

I use vim keybindings in VSCode and face same issues with the Bulgarian language.

It's because vim plugin for vscode goes through actual neovim afaik, and that one needs characters instead of key codes, so you just get screwed for the same reason lol

yeah.. we have to spam layout change to keep using our native languages

Couldn't we fix this via terminal emulators (and i think some do? Havent written TUIs in a while)? Although getting all terminal emulators to support that new protocol would also be a big pain

bigger problem is that modal editors use [], ctrl+Letter and shift+Letter to begin with, how's that different from normie VS Code F4 I'm of half mind to dedicate time to remap Helix bindings for my 34-key latin-colemak+3 other different languages and stuff like this blocks me

No, the problem is the terminal. It's not an editor issue.

How would you do that in gui emacs? If I press "M-b" in ru layout, it still interprets it as "M-и" and fails to execute the command. I know that there's an option to switch the layout from within emacs, but that makes for 2 ways of switching: DE and emacs, meh.

Emacs doesn't handle it because it's old and bad, not because it inherently can't, so it's kind of special haha :) Its workaround is to switch layouts inside if emacs, M-x set-input-method

I guess they just historically didn't do it and nobody bothered implementing it after emacs became a gui program. Or maybe for backwards compatibility, idk

Yeah, maybe it's something like that. But at least it's possible!

Good video

I'm surprised no one made an updated protocol for terminals with better UI support. the VT standard should be updated for modern day. Perhaps with some client side scripting for better responses. Maybe asm-html, just the bare bones everything else can be built with scripting.

Wouldn't a set of alias + the keymap solve the issue? I know it is not optimal, but no piece of software is perfect out of the box and always needs some config effort

Works for me.

i've been thinking about this ever since i watched it. how is the russian in your example using the terminal CLI at all? they certainly `cd` around, pipe programs, write some awk, etc. -- all ascii -- where they would have problems long before vim.

would it still be a problem with something with mouse support?

Is it because your terminal is set to Russian, and is it possible to terminal source a different language from within nvim, so that the terminal language changes and not necessarily the nvim language? That way, the terminal is expecting english and allows movement and <ctrl+[>.

I'm interested in knowing how this issue could be solved. I'm curious to know if the physical keybinds can be passed through the terminal emulator directly to the terminal application.

I'm not sure about this whole physical key stuff. I have french keyboard, the [ is on 5 and the ] is on the key after 0. I'd need to know where [ and ] are on qwerty to type them and get them act like it should.

The point is that if you knew physical key locations you wouldn't care about [ or ] - you would just know that it's that key in the top-right somewhere

Yes of course, but for that we need the UI to show the virtual key from the keyboard because I wouldn't know that I have to press $ instead of ] ^^

This is not a problem to implement... Unless the program runs in a terminal, which circles back to the topic of my video :D

seems like all the terminal emulator devs could band together and make a standardized "extension" that allows direct crossplatform keymap reading

There is kitty keyboard protocol, but it's not that good, and also adoption is, well, you know

I've had these problems you mentioned in the past, but my current approach (I speak croatian, basically latin english but with additional "č, ć, dž, đ, lj, nj, š, and ž" letters, what works is the "Linux Compose Key", and here is the cheatsheet:

I don't think it works with cyrillic, but with compose key I can just hold alt, type " c' ", and get "ć"

No. Terminal emulators and terminal text editors will forever be peak.