Verschiedene Tasten funktionieren in manchen Shells nicht
Closed this issue · 10 comments
Hi Max,
Wenn ich mit diesem Treiber (der übrigens genial ist!) Vim benutze, funktionieren manche Tasten der Ebene 3 nicht. Tasten, die ich bisher mit dem Problem gefunden habe (ich benutze den Treiber auch schon einige Zeit mit Vim), sind [, ] und {.
Beim normalen QWERTZ und dem offiziellen Neo2-Treiber funktionieren die Tasten in Vim, und alles funktioniert normal in anderen Anwendungen.
Getestet mit leerer Vim-Config und leerer settings.ini des Treibers.
Betriebssystem: Windows 10 Version 2004
Hallo Hallo89,
ja, das ist mir auch schon aufgefallen. Allerdings hat es meiner Meinung nach nichts mit vim, sondern mit dem Terminal zu tun.
Bei mir funktionieren die Symbole @{}|[]\~ nicht in Git Bash und MobaXTerm. Sie funktionieren aber in cmd.exe, Cmder und Neovim. In welchem Terminal (Emulator) benutzt du denn vim? Funktionieren dieses Tasten bei dir im selben Terminal außerhalb von vim?
Ich versuch mal rauszufinden, woran das liegt.
Aah das stimmt, nur im Terminal habe ich das gar nicht nachgeprüft, danke.
Ich nutze das Windows Terminal; darin gehen dann nur die drei oben angegebenen Tasten nicht, unabhängig von der benutzten Shell. In PowerShell und cmd.exe selbst funktioniert aber alles, stimmt.
Im Windows Terminal hat es auch nichts mit den Terminal-Settings zu tun.
@MaxGyver83 aus Interesse: Verwendest du diesen Treiber noch, oder bist du komplett auf KMonad umgestiegen?
Ich nutze das Windows Terminal
Oh, interessant, das kenne ich noch gar nicht! Muss ich mal ausprobieren!
@MaxGyver83 aus Interesse: Verwendest du diesen Treiber noch, oder bist du komplett auf KMonad umgestiegen?
Ich benutze sowohl privat als auch bei der Arbeit zu 99% Linux (und da benutze ich KMonad).
Wenn ich es bei der Arbeit Windows benutze, kommt es drauf an, was ich mache. neo2-llkh hat zwar oben genannte Einschränkungen, dafür funktioniert KMonad nicht in NoMachine. Mit neo2-llkh habe ich auf dem Remote-Rechner nur QWERTZ, mit KMonad funktionieren überhaupt keine Tastatur-Eingaben.
Prinzipiell benutze ich lieber KMonad, weil ich da die CapsLock-Taste als One-Shot-Layer für Shift verwenden kann (also erst CapsLock antippen, der nächste Buchstabe wird dann groß geschrieben). Andererseits will ich nicht völlig abhängig von KMonad sein, weil es in Haskell programmiert ist und ich nicht einmal triviale Bugs selbst fixen kann. Deshalb maintaine ich weiterhin neo2-llkh und bau auch ab und zu neue Funktionen ein. Zum Beispiel das mit den One-Shot-Layers würde ich gerne noch umsetzen.
Das Windows Terminal kann ich empfehlen, hat auch recht gute Configurability. KMonad sieht cool aus, kannte ich auch noch nicht, danke :D
Das Problem liegt vermutlich hier. GetKeyboardLayout gibt in manchen Terminals aus dubiosen Gründen null zurück, statt eines validen Input Locale Handles. Mit null fällt VkKeyScanEx auf irgendein Legacy-Layout zurück, deshalb werden die Zeichen falsch in Tastenkombinationen übersetzt. Eine potentielle Lösung ist, auf Layoutänderungen in Windows zu lauschen, und das letzte brauchbare HKL zu cachen.
Danke für den Hinweis! Ich wusste gar nicht, dass solche Funktionen vom Terminal abhängen können. Ich schau mir das bei nächster Gelegenheit mal genauer an.
@hallo89 : Die Symbole [, ] und { funktionieren mit dem neuen Release v0.6.2 auch im Windows Terminal. Interessanterweise kann im Windows Terminal } statt mit AltGr+0 alternativ mit Strg+Alt+0 eingegeben werden (mit QWERTZ), bei den anderen drei Klammern funktioniert das nicht. Deswegen hat } bisher wohl auch bisher mit neo2-llkh funktioniert. Das Problem lag jedenfalls darin, dass Windows ja AltGr intern als LCtrl + RAlt behandelt und wenn mal eine Taste, die man normalerweise mit AltGr erzeugt, injizieren will, man ein Extended Key Bit für die rechte Alt-Taste setzen muss. In den meisten Programmen macht das wohl keinen Unterschied, aber im Windows Terminal ist es entscheidend.
@Rojetto : Ich hab in einer Testversion bei jeder Tasteneingabe den Wert von GetKeyboardLayout(0) ausgegeben und hab kein einziges Mal null zurückbekommen, egal in welchem Terminal. Es ist immer 0x4070407, wenn das Windows-Tastaturlayout beim Start von neo2-llkh auf DEU steht, und 0x4090409 wenn es auf ENG steht. Benutzt du auch Windows 10? Hast du mit v0.6.2 immer noch Probleme in bestimmten Terminals? Wenn ja, würde ich das Ticket dann nochmal öffnen.
Sorry für die Verwirrung, da habe ich wohl voreilig geschlossen. null kommt nur, wenn man GetKeyboardLayout mit der Thread-ID der Konsolenanwendung aufruft (siehe hier). Mit 0 bekommst du immer das Layout von neo2-llkh selber, das passt also (außer man wechselt zur Laufzeit das Layout in Windows). Mit dem Fix scheint es jetzt in den Terminals zu gehen 👍