Actualización: Lo mismo sucede con todos los dígitos cuando se combinan con Alt Gr .

Sabes, esto probablemente sea por mí. Probablemente no obtengamos vkey correctamente para combos AltGR en algún lugar de TermControl.cpp, cuando obtenemos el evento KeyDown.

Algo no relacionado, pero ¿qué software usaste para obtener una grabación con las teclas que presionaste en el gif

@watermelonpizza Usé Carnac para mostrar las pulsaciones de teclas y ScreenToGif para capturar la ventana.

¡Oh carnac, increíble gracias! Agregaré eso a mi lista de golosinas :)

Creo que este es un duplicado del # 487.

Vaya, parece que la mano izquierda no sabe lo que hace la mano derecha, y acabo de crear un enlace circular duplicado.

Puede confirmar este problema en Windows versión 10.0.18362.30 con distribución de teclado húngaro. El comportamiento es diferente, dependiendo de la consola que esté usando:

• cmd: solo escribe el carácter pero en mayúsculas
• powershell: no hace nada en absoluto
• git bash: no escribe nada, pero reproduce el pitido predeterminado

@ zadjii-msft Encontré tu (?) comentario relacionado con AltGr en terminalInput.cpp .
En mi teclado alemán, el estado de la tecla de control es LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED lugar del aparentemente esperado LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED .
Además, la tecla virtual presionada es, por ejemplo, "Q" en lugar de algún carácter Unicode ya transformado.

Así reemplacé ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
con...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

...¡y funciona! Por ahora. 😅 Delegará el manejo a WM_CHAR / _CharacterHandler que según Google es más robusto para el manejo de AltGr. (?) (Todavía no estoy muy familiarizado con la programación de Windows).
¿Qué piensas de esto? ¿Debo enviar un PR?

@lhecker ¡Impresionante! Ahora bien, esto es realmente utilizable 🎉

@lhecker Sí, envíe un PR. En los teclados alemanes no puedo ingresar la tubería en este momento, lo que hace que el terminal sea un poco difícil de usar.

Sin embargo, siento que mi cambio es incorrecto. Debe haber una razón por la cual no todos los caracteres son manejados por WM_CHAR ¿verdad?
Por eso, me gustaría esperar primero los comentarios de @ zadjii-msft o @ DHowett-MSFT. ¿Yo creo que? 😅

La causa real está en Terminal.cpp

DWORD modifiers = 0
                      | (ctrlPressed? LEFT_CTRL_PRESSED : 0)
                      | (altPressed? LEFT_ALT_PRESSED : 0)
                      | (shiftPressed? SHIFT_PRESSED : 0);

Puede ver que RIGHT_ALT_PRESSED nunca se detecta correctamente aquí, lo que hace que keyEvent.IsAltGrPressed en TerminalInput :: HandleKey devuelva falso.

Por cierto, el estado de los modificadores es adquirido por _GetPressedModifierKeys () en TermControl :: _ KeyDownHandler (). en lugar de un valor booleano, puede pasar el estado de los modificadores directamente a SendKeyEvent y determinar si se presiona más adelante ctrl izquierda / derecha, alt izquierda / derecha, desplazamiento izquierda / derecha.

Y ya están definidos de la siguiente manera en VirtualKey, que se pueden usar en TermControl :: _ GetPressedModifierKeys ()

        LeftShift = 160,
        RightShift = 161,
        LeftControl = 162,
        RightControl = 163,
        LeftMenu = 164,
        RightMenu = 165,

¡Ah, buena captura @sagood!
Desafortunadamente, arreglar este problema no será suficiente por lo que puedo ver ...
TerminalInput::HandleKey aparentemente asume que cuando se presiona AltGr, el sistema operativo ya ha "pretraducido el UnicodeChar al valor alternativo adecuado", que no es el caso, por ejemplo, de AltGr + Q (= @) en un teclado alemán.
Lo que significa que la lógica actual alrededor de IsAltGrPressed() ya es algo defectuosa.

@lhecker He intentado usar RIGHT_ALT_PRESSED en su lugar para inicializar modificadores DWORD. Probé AltGr + '+' (= ~), se mostrará correctamente en la consola.
AltGr + <(= |) también funciona.

Pero AltGr + Q no parece funcionar de hecho. extraño.
AltGr + E (= €) tampoco funciona.

Al configurar un nuevo C # UWP, observé que la secuencia de teclas al usar AltGr es la siguiente:

Menu
Control
Q

(tome AltGr + Q como ejemplo)

La depuración adicional muestra que si fuerza al programa a ejecutar la primera rama de condición de TerminalInput :: HandleKey desde terminalInput.cpp como se muestra a continuación,

if (!fKeyHandled)
            {               
                if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') &&
                    keyEvent.GetVirtualKeyCode() != VK_CANCEL)
                {
                     // !!!force the AltGr+'Q/E' case to run here, not the one below
                    fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent));  
                }
                else
                {
                    ...
                }
            }

AltGr + Q funcionará.

¿Qué tal AltGr + ß para \ en el teclado alemán, ese tiene el mismo problema?

Todas las combinaciones de teclado AltGr se ven afectadas por el mismo problema.

¿Algún progreso en esto? Pude replicar el comportamiento, pero no estoy seguro de cómo se debe manejar realmente el caso AltGr. En caso de que ayude, aquí hay algunas cosas que miré:

• Verifiqué que, en un teclado alemán, AltGr se traduce en Left_CTRL && LEFT_ALT , probado para CMD, PS y WSL
• Parece que el error está relacionado con pruebas que no pasan. Las siguientes pruebas me fallan al cambiar a un teclado alemán, pero pasan en el teclado en inglés:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 hasta e incluyendo set10
  
  

@lhecker Por curiosidad, apliqué su primera idea de reemplazar isAltGrPressed() con isAltPressed() && isCtrlPressed() , y verifiqué que:

• funciona para CMD incluyendo @ y €, pero no en PS o WSL
• en realidad no corrige las pruebas que no pasan
• pero en su lugar rompe MouseInputTest::SgrModeTests#metadataSet20 para el teclado en inglés.

Aunque no llegué muy lejos en reducir aún más el problema, pensé que la información podría ser útil.

Eso es muy interesante @MattKuhr. @ y € realmente funcionan para mí tanto en PowerShell como en WSL. 🤔
(Solo para estar 100% seguro: esta es mi diferencia con el maestro actual 67f68eb).

De hecho, lo actualicé al maestro actual y lo probé nuevamente. Ahora los caracteres especiales funcionan, excepto € en PS.

No estoy seguro de qué causó el comportamiento que observé anteriormente, se usaron exactamente los mismos cambios de código. Estoy empezando a pensar que podría haber estropeado algo con la implementación mientras probaba, aunque probé varias veces, o algunas actualizaciones de Windows que se instalaron mientras tanto tuvieron un efecto.

Esta es una captura de pantalla con el teclado alemán configurado al probar en el maestro actual:

Lo probé tanto en Debug como en Release (x64), Win 10.0.18362.116. También intenté cambiar el idioma del sistema, lo que no tuvo ningún efecto. Parece un poco extraño, que solo en este caso específico el € no se traduzca correctamente.

Diga, ¿comienza a funcionar en PowerShell si primero Remove-Module PSReadline ? (No se preocupe: solo afectará su sesión actual). Si es así, ¡tenemos algunas ideas!

@ DHowett-MSFT Lo probé con una compilación de la caja maestra de ayer sin cambios en un diseño de teclado alemán en 18362.113 (la configuración del idioma es inglés)

Alt Gr + q => Q , esperado @
Alt Gr + < => < , esperado |
Alt Gr + + => + , esperado ~
Alt Gr + ß => ß , esperado \
Alt Gr + 2 => 2 , esperado ²
Alt Gr + 3 => 3 , esperado ³
Alt Gr + e => E , esperado €

Para personajes normales, Alt Gr funciona como shift. Cualquier otro carácter se deja en el valor sin modificador.

@ DHowett-MSFT De hecho

Las otras teclas siguen funcionando. Además, anteriormente el pequeño 3 se escribiría como 3 normal, ahora aparece correctamente, como puede ver en la captura de pantalla a continuación.

Hola,

Solo aquí para decir que esto también afecta el diseño QWERTY finlandés, haciendo que todas las combinaciones AltGr como @, |, {}, [], ~, \ etc. sean inutilizables.

Todos parecen funcionar bien con el parche de @lhecker en WSL, cmd y powershell. ¡Gracias @lhecker !

Hola, también funciona con la distribución del teclado francés Azerty. Gracias @lhecker

Tiene problemas con las combinaciones Alt Gr, por ejemplo, "Alt Gr + <" (barra invertida, pero da como resultado "<") en un teclado alemán suizo.

He actualizado el título de este número para que sea más obvio para los transeúntes lo que está rastreando.

@ zadjii-msft Encontré su (?) comentario relacionado con AltGr en terminalInput.cpp.
Así reemplacé ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
con...
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
falso retorno;
}
...¡y funciona! Por ahora. 😅

Este cambio también me proporciona un AltGr utilizable en mi teclado francés. Probado hasta ahora con CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (ambos con el PSReadline 2.0.0beta4 no oficial que se necesita para trabajar en VScode)

Este cambio también me proporciona un AltGr utilizable en mi teclado francés. Probado hasta ahora con CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (ambos con el PSReadline 2.0.0beta4 no oficial que se necesita para trabajar en VScode)

Revisé mi versión de PSReadline y actualicé de 2.0.0 a 2.0.0-beta4 y eso funcionó, ahora € y ³ también funcionan correctamente en PS, tanto 5.1 como 6.2.1. 😄

Aunque encontré otro error que también parece estar relacionado con PSReadline, pero no con AltGr o la distribución del teclado directamente. Como puede ver a continuación, en la Terminal CTRL 2 se traduce a " y CTRL 7 (en el diseño GER, en EE. UU. Es CTRL / ) a ^_

Para el primer caso, Eliminar PSReadline funciona, para el segundo no. Probé el otro número y las teclas de caracteres especiales, pero estos dos fueron los únicos dos casos que pude encontrar hasta ahora. El comportamiento es idéntico para 5.1 y 6.2.1. PSReadline es 2.0.0beta4.

¿Deberíamos abrir un tema aparte para esto?

También veo problemas relacionados en un teclado portugués (Portugal).
Esperado: Alt Gr + 2/3/4/7/8/9/0 debería generar @ £ § {[]}, Alt Gr + e debería obtener €

Terminal de Windows:
-PS Core: Alt Gr + dígito activa PSReadline DigitFunction, excepto 7 salidas ^ _
-PS Core: Alt Gr + € no hace nada
-Windows Powershell: Igual que PS Core
-CMD: Alt Gr + dígito genera el dígito, excepto 7 salidas ^ _
-CMD: Alt Gr + e salidas E

Consola incorporada:
PS Core: Alt Gr + salida 2/3/4/7/8/9/0 @ £ § {[]}, Alt Gr + E no hace nada
Windows PowerShell: igual que PS Core
CMD - Todas las obras

Windows 10 1903 18362.116
PS Core 6.2
Terminal de Windows 0.1.1431.0
PSReadline 2.0.0

Una solución probada y verdadera cuando las combinaciones de teclas "Alt Gr" no funcionan es usar Alt + Código numérico .

¡Pero esto tampoco funciona!

657 "Alt + teclado numérico no funciona"

Aconsejaría que quienquiera que se dirija a este también aborde este estrechamente relacionado.

Puedo verificar esto también para el teclado islandés. Usamos AltGr para escribir estos:
@ | € {[]} \ µ ~ `^

Solo una nota al margen: este problema surge en casi todas las tecnologías de línea de comandos de Microsoft. Ya surgió en OpenSSH , surgió un problema similar en PSReadline , y aquí nuevamente, donde ninguna de las combinaciones AltGr no funciona.

Cada vez que intento algo en la línea de comandos, siempre surgen problemas de entrada. Todavía no puedo usar PowerShell en sesiones remotas, porque Home-End no funciona y todavía no funcionan a través de SSH.

De alguna manera, este triángulo terminal-SSH-PSReadline está maldito.

Aquí estoy usando la distribución del teclado PT-BR.

Para obtener / uso Alt Gr + Q

Cuando se usa en Terminal, funciona como un comando de deshacer. Simplemente vuelva a escribir mi último comando / letra / palabra

@Mathiasmagnus

donde ninguna de las combinaciones AltGr no funciona.

¿Quiere decir que ninguna de las combinaciones AltGr funciona?

Diga, ¿comienza a funcionar en PowerShell si primero Remove-Module PSReadline ? (No se preocupe: solo afectará su sesión actual). Si es así, ¡tenemos algunas ideas!

No me funciona (diseño francés AZERTY)

así que ... ¿alguna idea nueva? porque la solución ...

`` `c ++
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
falso retorno;
}
...

no funcionó para mí <. <

Editar:

¿No es más inteligente detectar el idioma principal del teclado, que está definido en la máquina, y luego hacer el reenlace @microsoft ?

@Hedrauta es extraño que el cambio de código no funcione para ti. ¿Qué distribución de teclado estás usando? ¿Qué hace Ctrl+Alt+xxx por usted en un CMD normal para valores de xxx que se utilizan en combinación con AltGr? Por lo que puedo recordar, Ctrl+Alt siempre debería ser equivalente a AltGr ...

Entonces, para recopilar algunos datos de prueba: para mí, el parche de @lhecker parece funcionar bien. Esto está en un diseño de teclado alemán:

Terminal | Alt Gr + ß? \ | Strg + Alt + ß? \
- | - | -
Legado cmd.exe | \ | \
Legado pwsh.exe | \ | \
Terminal de Windows, master , cmd.exe | ß | ß
Terminal de Windows, master , pwsh.exe | _ (nada) _ | _(nada)_
Terminal de Windows, master + Parche de @lhecker , cmd.exe | \ | \
Terminal de Windows, master + Parche de @lhecker , pwsh.exe | \ | \

mismo resultado que en https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
con el parche de @lhecker

Pero en pwsh el signo € todavía no funciona en el diseño alemán.

cmd:
C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€
pwsh:
PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E

@Hedrauta es extraño que el cambio de código no funcione para ti. ¿Qué distribución de teclado estás usando? ¿Qué hace Ctrl+Alt+xxx por usted en un CMD normal para valores de xxx que se utilizan en combinación con AltGr? Por lo que puedo recordar, Ctrl+Alt siempre debería ser equivalente a AltGr ...

Tampoco me ayudó ...
Incluso intenté hacer mi propia solución basada en ese código, pero hasta ahora no tuve suerte ...

Estoy usando la distribución del teclado PT-BR, probando la siguiente combinación:

CMD, Powershell y WSL.exe
AltGr + Q = /

Al usar la Terminal de Windows
WSL: AltGr + Q = funciona como un comando de deshacer, reescribe mis últimos caracteres escritos.
Powershell, CMD: AltGr + Q = produce este carácter extraño impresiones como ^_

Editar:
Para ayudar a visualizar:

La entrada correcta debe ser
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 ¿Qué se obtiene con CtrlAlt en lugar de AltGr?

@ renatop7 ¿Qué se obtiene con CtrlAlt en lugar de AltGr?

El mismo resultado

¿Y fuera de Terminal, es decir, en CMD estándar o Windows Powershell o Powershell Core? ¿CtrlAlt siempre se comporta como AltGr?

¿Y fuera de Terminal, es decir, en CMD estándar o Windows Powershell o Powershell Core? ¿CtrlAlt siempre se comporta como AltGr?

Sí, fuera de la Terminal funciona perfectamente.
Usando con AltGr o Ctrl + Alt obtengo el resultado esperado.

obtenido hace 15 minutos: no funciona en absoluto
Bueno, ¿Microsoft siquiera trabaja en una solución relacionada con este problema?

@Hedrauta es extraño que el cambio de código no funcione para ti. ¿Qué distribución de teclado estás usando? ¿Qué hace Ctrl+Alt+xxx por usted en un CMD normal para valores de xxx que se utilizan en combinación con AltGr? Por lo que puedo recordar, Ctrl+Alt siempre debería ser equivalente a AltGr ...

Uhm, ¿alemán estándar ?. aquí una pantalla de cómo se ve: https://i.imgur.com/mvgHkxi.png
Intentaré escribir la clave a través de una macro ... probando

es como, mi alt izquierdo es Shift, no Alt ...
resultado probado
Ctrl + Q ^ Q
CTRL + Alt + QQ
solo Q q
Alt + QQ

Intentaré giflo, actualizando el comentario luego
Editar: mientras intentaba regalarlo, me di cuenta de que mi tecla Alt se reconoce mal ... ¿alguien sabe dónde están definidas las teclas virtuales? también lo investigaré;) pero no tengo tanta experiencia en c ++ o .... cualquier codificación;)

Solo para mí, como novato de cpp, verifiqué varios archivos y encontré el
C: \ Archivos de programa (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Entonces ... para diseños alemanes, el VK_Menu no existe, ¿verdad? solo somos dueños del VK_LMENU, ¿verdad?
intentaré algunos cambios y haré algunas pruebas ... editaré los resultados más tarde
Edición 1: la construcción está tardando mucho, como si reconstruyera todos mis sistemas oO
Edición 2: después de compilar todo, no funciona ... pero me di cuenta de que VK_RMENU es AltGr, mientras que VK_LMENU es la tecla que queremos ver presionada para obtener nuestro @ o \
pero VK_MENU también parece funcionar, pero puede que esté mal asignado
Esto me confunde un poco, lo comprobaré después de una búsqueda limpia, la reconstrucción y una siesta

Para la distribución del teclado en alemán es aún peor, porque Alt Gr + Q que solo debería generar @ , elimina la entrada de línea actual.
Eso no sucede con wsl, ni lo veo configurado para WT, entonces, ¿cómo sucede esto?

Sigue siendo un problema:
Teclado: belga (punto) AZERTY, funciona en shell normal
Winver: 18362.175
Versión del terminal: 0.2.1715.0

_Me gustaría pedirles a todos que se abstengan de comentar que también están lidiando con este problema.

A estas alturas, debería estar claro para todos que este problema afecta a una gran cantidad de combinaciones de teclas y puede resultar en una cantidad igualmente amplia de efectos secundarios inesperados, para una cantidad igualmente amplia de idiomas, versiones de Windows, teclados, etc.
Más de la mitad de los comentarios son de estilo #metoo, lo que no ayuda a solucionar este problema en absoluto y
solo hace que los comentarios útiles sean menos visibles .
Lo que realmente falta y sería de gran ayuda es que un desarrollador de Windows con conocimientos aborde este problema y envíe un PR.

Mientras tanto, todos los que sean capaces de compilar este proyecto pueden reemplazar este fragmento de código: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L396

con esta solución experimental mía:

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

Esto debería corregir la mayoría de las combinaciones de teclas para la mayoría de los idiomas de teclado, incluidos, por ejemplo, caracteres como @{}[] en un teclado alemán (o similar).

PD: No estoy afiliado a Microsoft de ninguna manera o forma y estoy escribiendo esto porque personalmente considero estos comentarios "#metoo" como demasiado ruidosos / improductivos. 🙂
PPS: Estoy seguro de que algunos se preguntan por qué no presento un PR yo mismo. Para citarme : "Siento que mi cambio es incorrecto. Debe haber una razón por la cual no todos los caracteres son manejados por WM_CHAR ¿verdad?" Lo que significa que en realidad no sé cuáles son las desventajas de la solución anterior y cómo hacerlo correctamente.

PPS: Estoy seguro de que algunos se preguntan por qué no presento un PR yo mismo. Para citarme: "Siento que mi cambio es incorrecto. Debe haber una razón por la que WM_CHAR no maneja todos los caracteres, ¿verdad?" Lo que significa que en realidad no sé cuáles son las desventajas de la solución anterior y cómo hacerlo correctamente.

Una forma de saberlo sería enviar un PR y ser corregido por el equipo. Es un poco exagerado, pero creo que haría que las cosas se movieran más rápido.

@NatoBoram 😤👉 # 1436

Tenga en cuenta que al usar las aplicaciones de ejemplo, por ejemplo, VtPipeTerm, la tecla alt-gr funciona allí.

@HBelusca VtPipeTerm no se basa en la nueva Terminal para UWP y, por lo tanto, no tendrá este problema.
Puede leer el n. ° 1436 para obtener una posible explicación del problema subyacente.

@lhecker no está basado en Cascadia, pero usa la misma implementación de pseudoconsola subyacente ... ¡así que es extremadamente útil saber que no se aplica a todos los consumidores de pseudoconsola!

Gracias @HBelusca

Las teclas especiales han funcionado durante años en terminales y aplicaciones de Windows. ¿Por qué tenemos este problema ahora en 2019? ¿Ha vuelto a implementar por completo el sistema de entrada para el programa de terminal? Espero que haya sido necesario hacer eso y volver a introducir los errores que se solucionaron hace años: s. Este problema era típico en Linux debido a páginas de códigos, asignaciones de teclado de idioma y teclas específicas de Windows, pero este error crítico se encuentra en la versión de vista previa de la aplicación, que está disponible en la tienda y se publica en todas partes.

@ifilgud Es una versión de vista previa disponible en la tienda por razones de vista previa . Este problema ha sido clasificado y también hay un RP enviado para él, por lo que no es necesario comentar sobre este tema solo para quejarse.

@patriksvensson Sé que me estaba quejando principalmente y eso no es "educado", pero también estoy pidiendo una razón técnica para explicar la razón de un error como este. Esperaba tener algunos errores menores para corregir en una versión casi terminada (vista previa), pero no uno que no debería haber existido en una evolución de un terminal, a menos que esté escrito desde cero y solo probado en inglés (supongo que esa es la razón para no detectar esto en la primera versión alfa). Abrí la terminal e intenté escribir "cd \" como el segundo comando (el primero fue "dir"), y simplemente no funcionó. Como desarrollador de software, esto me impactó mucho.

@lhecker hasta ahora, todo bien, después de aplicar su corrección experimental. ¡¡Muchas gracias!!

Muchas gracias por todas las personas que señalaron esto y ya lo arreglaron. 🌷

¿Con qué frecuencia se actualizará la aplicación MS Store?
Entonces, ¿cuándo podemos esperar arreglar cosas en la aplicación de las tiendas?

Me encantaría trabajar con el terminal, pero con el teclado alemán, ni siquiera puedes escribir { } sin altgr. 😅

También tengo el mismo problema para la distribución del teclado noruego Bokmål (nb-NO). No se puede crear [] o {} o $. PowerShell está básicamente roto sin esos.
Usando UWP / Microsoft Store versión 0.2.1715.0 en Windows 10 1903 18362.175.

diseño hu_HU a través de AltGr: \ | & @ $ ; # <> {} [] Me refiero a con qué frecuencia abro llaves, corchetes angulares o cuadrados, barra invertida, barra vertical, signo de dólar, marca de almohadilla, "arroba", "y", punto y coma ... oh espera, cada línea? :)

_Me gustaría pedirles a todos que se abstengan de comentar que también están lidiando con este problema.

A estas alturas, debería estar claro para todos que este problema afecta a una gran cantidad de combinaciones de teclas y puede resultar en una cantidad igualmente amplia de efectos secundarios inesperados, para una cantidad igualmente amplia de idiomas, versiones de Windows, teclados, etc.
Más de la mitad de los comentarios son de estilo #metoo, lo que no ayuda a solucionar este problema en absoluto y
_sólo hace que los comentarios útiles sean menos visibles_.

Actualización: Lo mismo sucede con todos los dígitos cuando se combinan con Alt Gr .

¿Cómo hiciste esta grabación gif?

@ Karl-WE Mira más abajo en el hilo.

@ DHowett-MSFT Podría ser una buena idea bloquear este hilo con un mensaje en la parte inferior

Si bien el terminal es muy inutilizable para Powershell mientras este problema está vivo
Me gustaría presentar una solución para Windows 10 1903 para aquellos que no pueden abstenerse hasta que se solucione.

Solución alterna:
use la tecla de Windows +.
ve a la pestaña de personaje especial selecciona tu personaje
cambiar a Terminal e insertar el carácter

Dejarlo desbloqueado les da a las personas un espacio para informar cada clave individual que no funciona, de modo que dejen de presentar _problemas_ individuales sobre cada clave individual que no funciona. Estoy desgarrado.

Puede haber más casos en los que los caracteres especiales no funcionen como se esperaba. Si quiero hacer un carácter @ en un teclado danés, hay 3 formas de hacerlo: Alt Gr + 2, Ctrl izquierdo + Alt izquierdo + 2 o Alt izquierdo + Teclado numérico 64
Las 2 primeras opciones dan el resultado OP informado.
La última opción lo hace en powershell:
Onpres Izquierda Alt + Teclado numérico 64 digit-argument: 64
Alt izquierdo en la liberación: 64 @ caracteres
En cmd
Onpres Izquierda Alt + teclado numérico 64: 64
Al lanzar Alt izquierdo: @ resultando en 64@
En wsl
Onpres Izquierda Alt + teclado numérico 64: (arg: 64)
Alt izquierdo en la liberación: 64 @ caracteres

Buen punto @saadanerdetbare!

Su problema Alt + Teclado numérico parece deberse al hecho de que la nueva Terminal (Cascadia) envía los códigos de escape apropiados al shell cuando ingresa estos códigos. Pero simultáneamente, otra parte de la aplicación _también_ maneja este caso, traduciendo el código Alt + Teclado numérico en un carácter apropiado e insertándolo en el shell. Esto lleva al efecto secundario divertido de que su carácter @ se repita 64 veces (debido a haber enviado los siguientes bytes al shell: \x1b6\x1b4@ ).

Puede probar esto agregando el siguiente código adicional entre estas dos líneas :

if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b')
{
    return;
}

Esto evitará que Cascadia envíe estos códigos de escape al shell. Posteriormente, sus caracteres (por ejemplo, @) aparecerán normalmente.
Alternativamente, puede eliminar este bloque de código para obtener el mismo efecto.

~ @saadanerdetbare Sería genial si pudieras crear un problema separado detallando tu problema, ya que este es un error que no está relacionado con la funcionalidad AltGr. 🙂 ~
👉 # 1401
Debería haber buscado otros problemas primero. 🤦‍♂️

PD: Sin embargo, tengo que decir que ver una mayor disposición de la comunidad para depurar estas cosas ellos mismos en lugar de depender de otros desconocidos me enorgullecería personalmente. 🙈🙂

@saadanerdetbare posterga la presentación de un nuevo número, ese es el # 1401: smile:

Todavía estoy experimentando esto en la aplicación de vista previa, tengo un teclado belga, imposible escribir @

@solispauwels , tendrá que esperar hasta la próxima versión (o construir la rama maestra actual usted mismo por ahora).

Hola, acabo de probar esta confirmación en un teclado alemán y todo funciona aparte de altgr-E, que debería imprimir el símbolo €. Para ser honesto, realmente no necesito esto en una terminal tan a menudo, pero pensé que podría mencionarlo de todos modos. Sin embargo, a otros les gusta altgr-m para µ.

Actualización: creo que puede ignorar eso, el símbolo € tampoco funciona en un PowerShell estándar, por lo que no parece ser culpa del terminal, debería haberlo verificado antes.

Todo parece funcionar aquí en un teclado francés: AltGr+é"'(-è_çà)=$e produce el ~#{[|`\^@]}¤€ esperado

También estoy usando un teclado francés (pero estoy en Bélgica) y tengo problemas con AltGr +caracteres. | # {} @, por ejemplo, no funcionan. Estoy usando la última versión de la tienda de Windows 0.2.1715.0 en Windows 10 v1903.

@meuter , tendrá que esperar hasta la próxima versión (o construir la rama maestra actual usted mismo por ahora).

La corrección de # 1436 aún no está incluida en la versión de vista previa disponible en Microsoft Store

@antoineco @ sba923 gracias, eso es lo que pensé. Acabo de clonar el repositorio. Tan pronto como mi vs2017 termine con la actualización, lo reconstruiré desde la fuente :-)

Gracias a todos por trabajar tan duro en esto y llenar nuestras bandejas de entrada con informes. ¡Gracias específicamente a @lhecker por enviar una solución! Lo acabamos de enviar a la tienda con la versión de servicio v0.2.1831.0. Es posible que la tienda tarde un poco en procesarlo.

Lo acabamos de enviar a la tienda.

Entonces, según mi experiencia con la publicación de aplicaciones en la Tienda Windows, debería tomar de 3 días a 3 semanas 😉

Lo acabamos de enviar a la tienda.

Entonces, según mi experiencia con la publicación de aplicaciones en la Tienda Windows, debería tomar de 3 días a 3 semanas 😉

Parece que menos de 6 horas. 😋

De todos modos, en mi teclado sueco todo parece estar bien ahora. 👍

Funciona con el teclado alemán ahora 👍

¡Funciona con teclado francés con la versión 0.2.1831.0! Gracias

¡Funciona con teclado francés con la versión 0.2.1831.0! Gracias

¡Confirmado!

¡Gran trabajo!

@ DHowett-MSFT La v0.2.1831.0 parece incluir esta corrección, pero no otras correcciones de errores como fuentes powerline o copiar / pegar teclas, ¿es esto normal?

Confirmo que Alt-Gr funciona, pero usar Ctrl-Alt para acceder a las mismas teclas del teclado no funciona de manera confiable (si es que lo hace).

En la versión 0.2.1831.0, las combinaciones AltGr ahora funcionan con el teclado finlandés.

@solispauwels, las únicas correcciones en la versión 0.2.1831.0 son las mencionadas en las notas de la versión.

Tenga en cuenta que muchos sistemas operativos 1803 o posteriores pueden sufrir un error con la versión 11905.1001.4.0 de Windows Store
La tienda "apilará" las aplicaciones para que se descarguen (consulte la imagen) pero no las descargará, incluso con la descarga automática habilitada y la red no es una conexión medida.

Los usuarios afectados deben presionar "Buscar actualizaciones" en Microsoft Store para finalmente obtener una aplicación de la tienda fija e iniciar todas las descargas de aplicaciones pendientes.

Confirmo que este problema se solucionará con la nueva versión de Terminal. Muchas gracias.

También puedo confirmar que esto está arreglado ahora. Es posible que desee desanclar el problema.

Funciona excepto la tecla Euro, que es AltGr + e, al menos en el teclado español. El resto de combinaciones funcionan correctamente

De @ifilgud

Funciona excepto la tecla Euro, que es AltGr + e, al menos en el teclado español. El resto de combinaciones funcionan correctamente

Probado en Windows 10 1903 (18362.175) con la última versión el 2019-07-08 con el teclado AZERTY "belga (punto)".

Resultado de la prueba:

• todas las combinaciones que tengo disponibles en mi teclado, incluido el símbolo de moneda Euro (€), funcionan en 2 de las 3 consolas configuradas por defecto en Windows Terminal: PowerShell Core y 'cmd' (Símbolo del sistema de Windows)
• Sólo en "Windows PowerShell" hace el símbolo del Euro (€) no trabajo
  
  
  
  • Sin embargo, no funciona en la consola de PowerShell clásico lanzado directamente de Inicio de Windows, así
  
  

Imo, este es un problema nuevo relacionado con Windows PowerShell, no específico de la Terminal de Windows que aloja esa Consola.

Confirmo la observación de

Aquí en Windows 10 acumulación 18.362,175 con Windows Vista preliminar Terminal versión 0.2.1831.0, con un teclado francés, AltGr+E cede € en todas las siguientes conchas:

• cmd
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-preview.1

¿Alguien con AltGr problemas restantes _en PowerShell_ puede comprobar qué versión de PSReadLine están ejecutando?

$psrl = Get-Module PSReadLine $psrl.Version $psrl.PrivateData.PSData['Prerelease']

@ sba923 :

PS C:\Users\myself> $psrl = Get-Module PSReadLine
PS C:\Users\myself> $psrl.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      0      -1

PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease']
beta2

@HBelusca, ¿ podrías intentar:

1. deshabilitar PSReadLine
2. actualizando a la última beta4 , consulte https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Terminal de Windows 0.2.1831.0
• PowerShell v7 (que incluye PSReadline 2.0.0-beta4)
• Distribución del teclado alemán QWERTZ

✅ AltGr + Q → @
✅ AltGr + E → €
❌ Ctrl + Alt + Q → q

Esto es especialmente frustrante ya que hay otro error relacionado con mstsc que Microsoft ha estado ignorando durante al menos una década donde AltGr + Q deja de funcionar si una sesión RDP está abierta. En estas situaciones, Ctrl + Alt + Q todavía funciona, por lo que mucha gente lo usa como solución alternativa.

Lo que Microsoft DEBE hacer es NO TOCAR LA TRANSMISIÓN DEL TECLADO.

El shell (explorer.exe) debería capturar cualquier pulsación de tecla que necesite y pasar todo lo demás en sentido descendente.
En última instancia, Terminal.exe SOLO debería detectar Alt-F4, y quizás ni siquiera eso, explorer.exe realmente debería detectarlo y aplicarlo al proceso activo.

Lo que significa que Terminal.exe solo debe tomar la secuencia del teclado y pasarla al proceso secundario activo. Nada más.

CMD.exe [command.com] debería saber cómo captar lo que necesita y luego pasar el resto a sus propios hijos.

WSL debería obtener la mayor cantidad de entrada sin procesar posible. NO manipule AltGr. Ctrl-Alt y AltGr NO son las mismas secuencias de teclado. En Linux existen atajos que usan ctrl-alt -... que producen resultados diferentes a AltGr -...

Solo tiene UNA oportunidad para hacerlo correctamente. La primera oportunidad en casi 40 años. Por favor, no pierdas esa oportunidad - Microsoft, te estoy mirando :)

@thorsig ah, si tan solo lo hubiéramos tenido cuando se diseñó la pila de entrada de Win32 hace cuarenta y tantos años. Desafortunadamente, no lo hicimos, por lo que hay dos formas principales de recibir entradas de teclado:

• como caracteres, sin modificadores (por lo que no podemos detectar ALT para enviarlo a través de las tuberías terminales) o la dirección de pulsación de tecla
• como códigos de escaneo, que tienen modificadores e instrucciones, pero en realidad son solo representaciones de _ ubicaciones de claves físicas_

Cuando empiece a buscar por debajo del nivel del sistema operativo, los códigos de escaneo _son_ el modo de "entrada lo más cruda posible". Sin embargo, requieren un poco de cocción antes de que puedan pasar a aplicaciones que requieren entrada de texto. (Editar para agregar :) Las aplicaciones de terminal realmente prefieren su entrada como texto. ¡No podemos enviar códigos de escaneo a través de una conexión SSH! Incluso si pudiéramos, el destinatario _el mismo_ necesitaría comprender la distribución del teclado para realizar la traducción. Probablemente las máquinas sin cabeza no tengan una distribución de teclado. (/editar)

Si fuera tan fácil como "obtener el carácter literal que presionaron y enviarlo", debe confiar en que estaríamos haciendo precisamente eso. ¡No diseñamos soluciones locas porque somos locos! :sonreír:

Bueno, yo estaba por aquí aunque no tenía ni idea de cómo manejar el flujo de entrada en ese momento.

Sin embargo, Linux funciona con los códigos clave sin formato de forma predeterminada, por lo que no es un problema. Sin embargo, su ejemplo de una conexión ssh es defectuoso, ya que la aplicación de terminal nunca ejecuta ssh directamente; hay un shell dentro (o una abstracción completa del sistema operativo como WSL) que es responsable de lo que llega al shell.

Si lo que está afirmando es correcto, todas las aplicaciones que se hayan escrito para Windows (que se ejecuten sobre el explorador) tendrían que implementar su propio manejo intrínseco del teclado. No lo hacen. Porque se ocupa de aguas arriba y aguas abajo.

Miré el código y tuve mi parte de "SMH". ¿Podría hacerlo mejor? Probablemente, dado el tiempo. ¿Puedo permitirme quejarme de eso? Dado que no tengo tiempo para hacerlo yo mismo, probablemente no.

Aún así, me pareció que vale la pena mencionarlo, está siendo diseñado en exceso como está, y causará problemas en algún momento (probablemente más temprano que tarde).

Bueno, yo estaba por aquí aunque no tenía ni idea de cómo manejar el flujo de entrada en ese momento.

Sin embargo, Linux funciona con los códigos clave sin formato de forma predeterminada, por lo que no es un problema. Sin embargo, su ejemplo de una conexión ssh es defectuoso, ya que la aplicación de terminal nunca ejecuta ssh directamente; hay un shell dentro (o una abstracción completa del sistema operativo como WSL) que es responsable de lo que llega al shell.

WSL no realiza ningún tipo de traducción en particular. conhost.exe o el terminal de Windows (o Gnome-terminal si ejecuta una aplicación gráfica a través de, digamos, XMing) hace la traducción adecuada para enviar al pty. E incluso el caparazón ... no es el caparazón en sí el que hace la mayor parte del trabajo. Es el controlador de terminal y la aplicación en el extremo maestro (que, nuevamente, es conhost.exe, Windows Terminal, quizás Cygwin Terminal si lo desea, y las aplicaciones de terminal de Linux).

Si lo que está afirmando es correcto, todas las aplicaciones que se hayan escrito para Windows (que se ejecuten sobre el explorador) tendrían que implementar su propio manejo intrínseco del teclado. No lo hacen. Porque se ocupa de aguas arriba y aguas abajo.

La mayoría de las aplicaciones no se preocupan por la entrada de teclado sin procesar. Eso se maneja a través de algunas bibliotecas Win32 de formas que son inherentemente con pérdidas. No utilizan la entrada de teclado sin procesar directamente. La mayoría de las aplicaciones solo se preocupan por los personajes, además de los juegos que pueden preocuparse exactamente por la entrada de diseño físico. De cualquier manera funciona bien.

Miré el código y tuve mi parte de "SMH". ¿Podría hacerlo mejor? Probablemente, dado el tiempo. ¿Puedo permitirme quejarme de eso? Dado que no tengo tiempo para hacerlo yo mismo, probablemente no.

Aún así, me pareció que vale la pena mencionarlo, está siendo diseñado en exceso como está, y causará problemas en algún momento (probablemente más temprano que tarde).

Le sugiero que busque en Gnome-Terminal, el análogo de Linux, y compruebe si es más simple o más complejo. Sospecho que es más complejo ya que X es en realidad más extraño que el GDI32 o cualquier API de ventanas que esté en uso.

¿Existe una regresión desde 0.2.1831.0 ?
En el teclado danés, Windows Terminal Preview v0.3.2142.0 no responde a AltGr.

Terminal de Windows (vista previa)
Versión: 0.3.2142.0
Microsoft Windows 1903 [Versión 10.0.18362.267]

Tengo un teclado danés y v0.3.2142.0 Windows build 10.0.18362.239 Es un sistema operativo en inglés sin paquetes de idioma. Los caracteres especiales Alt Gr funcionan aquí, la secuencia Ctrl + Alt no

Tengo un teclado danés y v0.3.2142.0 Windows build 10.0.18362.239 Es un sistema operativo en inglés sin paquetes de idioma. Los caracteres especiales Alt Gr funcionan aquí, la secuencia Ctrl + Alt no

Mi sistema operativo: Win10 Home 1903 Build 10.0.18362.267
Sistema operativo danés con paquete de idioma estadounidense adicional instalado, aunque el paquete de idioma danés es el predeterminado.
Hmm - Compilación 10.0.18362.267 vs 10.0.18362.239 - ¡¡¿Hay alguna pista ahí? !!!

Mi sistema operativo: Win10 Home 1903 Build 10.0.18362.267
Sistema operativo danés con paquete de idioma estadounidense adicional instalado, aunque el paquete de idioma danés es el predeterminado.
Hmm - Compilación 10.0.18362.267 vs 10.0.18362.239 - ¡¡¿Hay alguna pista ahí? !!!

Para obtener todos los detalles:
Estoy en
Win 10 Enterprise en-US 1903 compilación 18362.239
Teclado danés, sin paquete de idioma

Intenté iniciar sesión en una cuenta con el paquete de idioma de EE. UU. Por defecto, instalé el terminal allí y cambié al teclado danés para ver si el paquete de idioma elegido tenía alguna influencia, pero no hubo suerte allí.

No sé si esto podría ser una pista para alguien que lo sepa, pero antes de actualizar a 1903 desde 1809, el teclado en pantalla ( c:\windows\system32\osk.exe ) mostraba el mismo comportamiento en todas las aplicaciones conhost, cmd.exe, ubuntu / wsl y powershell.exe (ignorando AltGr) pero en 1903 esto parece arreglado.

Puedo confirmar que _algunas_ secuencias AltGr no funcionarán.
AltGr Q (= @ ) funciona para mí, mientras que, por ejemplo, AltGr 8 (= [ ) no.

Construí la versión de la tienda v0.3.2142.0 localmente para depurar este problema. Debido a que no pude averiguar cómo construir el AzureConnector, tuve que excluirlo: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Resulta que mi v0.3.2142.0 construido localmente funciona bien. Todas las secuencias AltGr funcionan correctamente.
Solo la versión de tienda de la Terminal no lo hace. ¿Podría el AzureConnector tener la culpa aquí, ya que lo excluí? (Quiero decir que dudo que sea el caso, pero solo para estar seguro ...)

@ DHowett-MSFT @miniksa ¿Puede usted (o alguien) volver a verificar la versión Store de v0.3.2142.0 y compararla con las construidas localmente?

Tengo el mismo problema. El terminal no se puede usar con ese problema ya que AltGr es imprescindible. ¿Y por qué este hilo está cerrado? Debería ser un tema de máxima prioridad.

¿Y por qué este hilo está cerrado?

@MasMedIm Es posible que, tras una inspección más

@lhecker eso es muy inusual. El conector de Azure no debería tener nada que ver con esto, ya que está en una capa diferente (conexión, no control) ... pero eso es interesante independientemente.

¿Puede usted (o alguien) volver a verificar la versión Store de v0.3.2142.0 y compararla con las construidas localmente?

La versión que tengo donde funciona el carácter especial AltGr es la versión de la tienda

AltGr ( ~#{[|`\^@]}¤€ ) funciona bien aquí con un teclado francés, Windows 10 versión 1903 compilación 18362.267 y Windows Terminal Preview 0.3.2142.0

@ sba923 También tengo un teclado francés y la misma versión de Windows. Las combinaciones AltGr que no funcionan son: & ~ # {[| `\ ^ € ù \
Mi terminal también se descarga de la tienda. Intentaré construirlo en local para verlo.

Solo para explicar mi situación, algunas combinaciones AltGr + Key realmente funcionan, mientras que otras no.

No funciona:

| Clave | AltGr + Tecla, esperado: |
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

Trabajos:

| Clave | AltGr + Tecla, esperado: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Nota: '´', '¨' son tipos de clave inactiva.

Sistema: Windows 10 64bit Home 1903 Build 10.0.18362.267
Terminal de Windows: Vista previa v0.3.2142.0 - Versión de la tienda
Distribución del teclado: danés.

@MasMedIm , @ sba923 , @lhecker - ¿Son sus versiones de Windows Home como la mía?
Editar: Olvida mi pregunta. Estaba a punto de comenzar una búsqueda inútil allí ;-), ¡pero

@ DHowett-MSFT @ henrik-jensen et. al .: Encontré la causa de la regresión. ¯ \ _ (ツ) _ / ¯
... y nos convierte a todos aquí en un montón de idiotas por habernos dado cuenta antes. 😂

El nuevo profiles.json contiene atajos del tipo Ctrl+Alt+[0-9] para saltar rápidamente a la pestaña 1-10.
Si elimina estos accesos directos de su archivo de configuración ( Ctrl ) , la regresión se corrige.
Ciertas combinaciones como AltGr E por € lamentablemente nunca han funcionado todavía y alguien tiene que tomarse el tiempo necesario para solucionar este problema.

Debido a la forma en que funcionan las antiguas API de Windows, será difícil diferenciar de manera confiable entre los atajos de Ctrl Alt y las pulsaciones de teclas AltGr reales, pero voy a comprobar si la situación se puede mejorar de alguna manera.

@lhecker 🥇 👍
Confirmado. Jubii

Ciertas combinaciones como AltGr E por € lamentablemente nunca han funcionado y alguien tiene que tomarse el tiempo necesario para solucionarlo.

AltGr E -> '€' funciona en mi distribución de teclado danés. Intentaré agregar un diseño alemán en el mío para ver si es reproducible en mi configuración.

¿Qué tal simplemente morder la bala? ¿Conservar el antiguo CMD.EXE para aplicaciones heredadas (DOS) y diseñar la nueva Terminal solo para el futuro? No es que la compatibilidad con versiones anteriores no sea buena, pero a veces solo tienes que cortar lazos ...

@lhecker 🥇 👍
Confirmado. Jubii

Ciertas combinaciones como AltGr E por € lamentablemente nunca han funcionado y alguien tiene que tomarse el tiempo necesario para solucionarlo.

AltGr E -> '€' funciona en mi distribución de teclado danés. Intentaré agregar un diseño alemán en el mío para ver si es reproducible en mi configuración.

En esta configuración, funciona el ~ Kezboard ~ ups, el teclado :-) * y AltGr E -> '€' instalados en alemán.

Editar: * 'z' / 'y' se intercambian en los teclados alemán / danés.

El nuevo profiles.json contiene atajos del tipo Ctrl+Alt+[0-9] para saltar rápidamente a la pestaña 1-10.

Por alguna razón, estos accesos directos son alt + [0-9] en mi archivo de configuración, por lo que no tuve el problema.

Ahora se me ocurren algunas preguntas:

• @lhecker ¿ Quizás deberíamos hacer un nuevo problema para la regresión para la detección / historial y puede agregar su solución de parche a eso? Editar: Genial - @lhecker hizo una solicitud de extracción # 2235
• Me pregunto dónde se genera el ~ settings.json ~ profiles.json predeterminado. No es un recurso, así que supongo que está codificado en algún lugar. Editar: lo encontré CascadiaSettings.cpp L369
• ¿Qué atajos alternativos deberían elegirse en su lugar? Tal vez los que @saadanerdetbare tiene en su ~ settings.json ~ profiles.json (¿Eran los predeterminados en pre 0.3.2142.0? Editar: Parece que sí - # 2014)

@lhecker @ henrik-jensen eso tendría sentido. Lo instalé desde la tienda justo después de su lanzamiento allí y realicé algunos cambios en profiles.json Entonces, si la actualización no sobrescribió el archivo porque era personalizado y no predeterminado, no obtuve los accesos directos Ctrl + Alt

@ DHowett-MSFT @ henrik-jensen et. al .: Encontré la causa de la regresión. ¯_ (ツ) _ / ¯
... y nos convierte a todos aquí en un montón de idiotas por habernos dado cuenta antes. 😂

El nuevo profiles.json contiene atajos del tipo Ctrl+Alt+[0-9] para saltar rápidamente a la pestaña 1-10.
Si elimina estos accesos directos de su archivo de configuración (Ctrl), la regresión se corrige.
Ciertas combinaciones como AltGrE por € lamentablemente nunca han funcionado y alguien tiene que tomarse el tiempo necesario para solucionarlo.

Debido a la forma en que funcionan las antiguas API de Windows, será difícil diferenciar de manera confiable entre los atajos de CtrlAlt y las pulsaciones de teclas AltGr reales, pero voy a comprobar si la situación se puede mejorar de alguna manera.

Ty para la respuesta, de hecho fueron las configuraciones Ctrl + Alt + [0-9]

@saadanerdetbare , sí, se cambió de su configuración a la nueva aquí # 2014 por @ zadjii-msft

Confirmo que los nuevos atajos rompen AltGr ( ~#{[|`\^@]} ) en mi teclado francés.

La razón por la que algunos de nosotros no vimos la regresión está relacionada con la actualización 0.3 que no anula un profiles.json , que está documentado en la versión de

Nota: Si ha instalado la Terminal antes de esta versión, estas combinaciones de teclas solo aparecerán de forma predeterminada una vez que elimine su profiles.json y permita que se regenere. Puede guardar su profiles.json original en otro lugar y copiar sus personalizaciones o simplemente agregar estas combinaciones de teclas manualmente. Somos conscientes de que esta no es una experiencia ideal y estamos trabajando para mejorarla.

Se puede usar ctrl + alt + shift + _digit_, aunque no es muy fácil de teclear ...

@ henrik-jensen Abrí el # 2235.

@thorsig Ya le han dicho cuál es la situación en el panorama de la API de Windows.
Especialmente dado que, por ejemplo, bash en Linux (como la mayoría de los shells que podría querer usar en Windows en el futuro) _no_ recibe códigos clave sin procesar, sino texto regular infundido con secuencias de escape. Secuencias de escape que su terminal necesita generar a partir de eventos de teclado. Su shell de Linux _no_ maneja códigos clave sin formato. Su terminal lo hace.
Antes de continuar con esto, primero debe comprender cómo funcionan xterm y vt100 (y posteriores).
Y por cierto: los códigos de tecla en Linux también son solo una abstracción virtual (! = Sin procesar) sobre los códigos de escaneo de su teclado - vea keymaps.5 . La única diferencia es que en Windows se decidió hace mucho tiempo que Ctrl + Alt es lo mismo que AltGr, porque algunos teclados carecían de las teclas AltGr, pero todavía se quería poder presionar AltGr de alguna manera. Las personas que decidieron esto podrían tener más de 60 años en la actualidad. Cambiar esto no es trivial y solo tiene un beneficio insignificante (ya que de todos modos ya puede detectar pulsaciones de teclas AltGr en la práctica).

Confirmo que los nuevos atajos rompen AltGr ( ~#{[|`\^@]} ) en mi teclado francés.

La razón por la que algunos de nosotros no vimos la regresión está relacionada con la actualización 0.3 que no anula un profiles.json , que está documentado en la versión de

Nota: Si ha instalado la Terminal antes de esta versión, estas combinaciones de teclas solo aparecerán de forma predeterminada una vez que elimine su profiles.json y permita que se regenere. Puede guardar su profiles.json original en otro lugar y copiar sus personalizaciones o simplemente agregar estas combinaciones de teclas manualmente. Somos conscientes de que esta no es una experiencia ideal y estamos trabajando para mejorarla.

Se puede usar ctrl + alt + shift + _digit_, aunque no es muy fácil de teclear ...

Es más fácil usar alt + _digit_ y es similar a los atajos en gnome-terminal.
Funciona en mi teclado francés.

Si usa Alt + dígito , tenga en cuenta que no podrá enviar esas teclas a una aplicación de consola.

: tada: este problema se abordó en # 2235, que ahora se ha publicado con éxito como Windows Terminal Preview v0.3.2171.0 .: tada:

Enlaces útiles:

• Notas de lanzamiento
• Descargar tienda

AltGr ( ~#{[|`\^@]}¤€ ) funciona bien aquí con un teclado francés, Windows 10 versión 1903 compilación 18362.267, Windows Terminal Preview 0.3. 2171 .0, y los atajos de cambio de tabulación establecidos en Ctrl+Alt+digit .

¡Buen trabajo!

¡Gracias por la confirmación!

¡Eres muy bienvenido!

Corrección 0.3.2171.0 confirmada para mi sistema: teclado danés Win10 Home 1903 build 10.0.18362.267.
Eliminé mi profiles.json para obtener la configuración predeterminada y ahora AltGr también funciona para una nueva instalación (supongo).
Buen trabajo

Hola, creo que tengo este problema en la versión 0.7.

No puedo ingresar la tecla de barra en mi teclado usando el teclado numérico o AltGr + Q (teclado brasileño ABTN2 de una computadora portátil Samsung que no tiene el signo de interrogación / tecla de barra).

Editar: no puedo ingresar ninguna tecla AltGr.

Después de eliminar una versión anterior de PSReadline, todo funciona ahora.

FWIW, he escrito los scripts de PowerShell adjuntos para verificar qué versiones de PSReadline están en mi sistema / cuál está activa.

CheckPSReadLineStatus.zip

HTH

Para solucionar el mismo problema que informó beppler, haga lo siguiente:

Después de eliminar una versión anterior de PSReadline, todo funciona ahora.

Desde una sesión de powershell elevada, haz lo siguiente:

Install-Module -Name PowerShellGet -Force
Exit

Desde una sesión de cmd elevada, haga:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

¿Cuál es el estado de este problema?
Porque al mirar los problemas vinculados, parece arreglado, pero todavía no me funciona. Para imprimir el carácter ~ en una distribución de teclado italiana, estoy acostumbrado a hacer Alt + 126, pero esto tiene un comportamiento diferente según el tipo de terminal, pero en ninguno de ellos puedo obtener el carácter ~ impreso, mientras se hace directamente en el shell subyacente (git / cmd / powershell / wsl no integrado en la terminal de Windows) funciona como se esperaba

Esto me está pasando con la última versión de la terminal de windows, al momento de escribir es:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax Rompí la entrada Alt + Numpad en # 3117. Ahora que # 3117 se había fusionado y el problema asociado se había solucionado, podríamos trabajar para reintroducir la entrada del teclado numérico en la base del código.
Sin embargo, haría de esto un comportamiento opcional y configurable, porque estoy bastante seguro de que la mayoría de los usuarios potenciales de la aplicación Terminal ya no se beneficiarán de ella. Por lo tanto, la aplicación debería enviar de forma predeterminada todas las entradas de teclado posibles al shell para que pueda configurar combinaciones de teclas vim, etc. más avanzadas.
Implementar esto debería ser un poco más fácil tan pronto como se fusione # 4192. Tendría que agregar la lógica adicional aquí mismo y verificar si la tecla Alt (y solo la tecla Alt) se mantiene en states , mientras que la tecla v proviene del teclado numérico en lugar de las teclas numéricas normales . ¡No dude en enviar un PR en cualquier momento! 🙂

@lhecker gracias por la respuesta rápida, solo quería saber el estado de esto porque cada problema que encontré estaba cerrado pero el problema sigue ahí.
No estoy seguro de que se me ocurra un PR sobre esto, nunca miré el código antes, así que realmente no sé por dónde empezar, a pesar de tu sugerencia.

Solo quería saber cómo arreglar mi flujo de trabajo para git rebase -i porque ahora tengo que abrir algo como notepad ++, escribir el carácter ~, copiarlo y pegarlo en la terminal.

Solo para que lo entienda: ¿estás en un hilo sobre AltGr con una pregunta sobre _alt + secuencias de teclado numérico_? Esta puede ser la razón por la que todos los hilos que está encontrando están cerrados: el problema de AltGr está solucionado.

Creo que tenemos un problema separado para rastrear los problemas de entrada de alt + teclado numérico.

Sí, tienes razón, perdón por la confusión. Creo que el # 657 puede ser el correcto