Pembaruan: Hal yang sama terjadi dengan semua digit jika digabungkan dengan Alt Gr .

Anda tahu, ini mungkin pada saya. Kami mungkin tidak mendapatkan vkey dengan benar untuk kombo AltGR di suatu tempat di TermControl.cpp, ketika kami mendapatkan acara KeyDown.

Agak tidak ada hubungannya, tetapi perangkat lunak apa yang Anda gunakan untuk merekam dengan tombol yang Anda tekan di gif @patriksvensson ?

@watermelonpizza Saya menggunakan Carnac untuk menampilkan penekanan tombol dan ScreenToGif untuk menangkap jendela.

Oh carnac, terima kasih luar biasa! Saya akan menambahkannya ke daftar barang saya :)

Saya rasa ini adalah duplikat dari # 487.

Ups, sepertinya tangan kiri tidak tahu apa yang dilakukan tangan kanan, dan saya baru saja membuat tautan duplikat melingkar.

Dapat mengonfirmasi masalah ini di Windows versi 10.0.18362.30 dengan tata letak keyboard Hungaria. Perilakunya berbeda, bergantung pada konsol yang saya gunakan:

• cmd: itu hanya menulis karakter tetapi dalam huruf besar
• PowerShell: tidak melakukan apa pun
• git bash: tidak menulis apa pun, tetapi memutar bip default

@ zadjii-msft Saya menemukan komentar Anda yang terkait (?) AltGr di terminalInput.cpp .
Pada keyboard Jerman saya, status tombol kontrol adalah LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED alih-alih LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED tampaknya diharapkan.
Selain itu, tombol virtual yang ditekan adalah misalnya "Q", bukan beberapa karakter unicode yang sudah diubah.

Jadi saya mengganti ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
dengan...

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

... dan berhasil! Untuk sekarang. 😅 Ini akan mendelegasikan penanganan ke WM_CHAR / _CharacterHandler yang menurut Google lebih kuat untuk penanganan AltGr. (?) (Saya belum begitu paham dengan pemrograman Windows.)
Apa pendapatmu tentang ini? Haruskah saya mengirimkan PR?

@lhecker Luar biasa! Sekarang ini sebenarnya bisa digunakan 🎉

@lhecker Ya, kirimkan PR. Pada keyboard jerman saya tidak dapat memasukkan pipa sekarang yang membuat terminal agak sulit digunakan.

Saya merasa perubahan saya tidak benar. Pasti ada alasan kenapa tidak semua karakter ditangani oleh WM_CHAR kan?
Oleh karena itu saya ingin menunggu masukan dari @ zadjii-msft atau @ DHowett-MSFT terlebih dahulu. Kupikir? 😅

Penyebab sebenarnya ada di Terminal.cpp

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

Anda dapat melihat bahwa RIGHT_ALT_PRESSED tidak pernah terdeteksi dengan benar di sini, yang menyebabkan keyEvent.IsAltGrPressed di TerminalInput :: HandleKey mengembalikan false.

Btw, status pengubah diperoleh oleh _GetPressedModifierKeys () di TermControl :: _ KeyDownHandler (). alih-alih nilai boolean, Anda dapat meneruskan status pengubah langsung ke SendKeyEvent, dan menentukan apakah ctrl kiri / kanan, kiri / kanan alt, pergeseran kiri / kanan ditekan nanti.

Dan sudah ada yang didefinisikan sebagai berikut di VirtualKey, yang bisa digunakan di TermControl :: _ GetPressedModifierKeys ()

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

Ah, tangkapan yang bagus @sagood!
Sayangnya, memperbaiki masalah ini sejauh yang saya tahu tidak akan cukup ...
TerminalInput::HandleKey tampaknya mengasumsikan bahwa ketika AltGr ditekan, OS telah "menerjemahkan UnicodeChar ke nilai alternatif yang tepat", yang tidak berlaku untuk misalnya AltGr + Q (= @) pada keyboard Jerman.
Artinya logika saat ini sekitar IsAltGrPressed() sudah agak cacat.

@lhecker Saya mencoba menggunakan RIGHT_ALT_PRESSED sebagai gantinya untuk menginisialisasi pengubah DWORD. Saya menguji AltGr + '+' (= ~), itu akan ditampilkan dengan benar di konsol.
AltGr + <(= |) juga berfungsi.

Tapi AltGr + Q sepertinya tidak bekerja. aneh.
AltGr + E (= €) juga tidak berfungsi.

Dengan menyiapkan c # UWP baru, saya mengamati bahwa urutan kunci saat menggunakan AltGr adalah sebagai berikut,

Menu
Control
Q

(ambil AltGr + Q sebagai contoh)

Proses debug lebih lanjut menunjukkan bahwa jika Anda memaksa program untuk menjalankan cabang kondisi pertama TerminalInput :: HandleKey dari terminalInput.cpp seperti yang ditunjukkan di bawah ini,

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 akan berfungsi.

Bagaimana dengan AltGr + ß for \ pada keyboard Jerman, yang memiliki masalah yang sama

Semua kombinasi keyboard AltGr dipengaruhi oleh masalah yang sama.

Ada kemajuan dalam hal ini? Saya bisa meniru perilaku, tapi saya tidak yakin, bagaimana kasus AltGr harus benar-benar ditangani. Jika itu membantu, berikut beberapa hal yang saya lihat:

• Saya memverifikasi bahwa, pada keyboard Jerman, AltGr memang diterjemahkan ke dalam Left_CTRL && LEFT_ALT , diuji untuk CMD, PS dan WSL
• Tampaknya bug tersebut terkait dengan tes yang tidak lulus. Tes berikut gagal untuk saya saat beralih ke keyboard jerman tetapi lulus pada keyboard bahasa inggris:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 hingga dan termasuk set10
  
  

@lhecker Karena penasaran, saya menerapkan ide pertama Anda untuk mengganti isAltGrPressed() dengan isAltPressed() && isCtrlPressed() , dan memverifikasi bahwa:

• bekerja untuk CMD termasuk @ dan €, tetapi tidak di PS atau WSL
• sebenarnya tidak memperbaiki tes yang tidak lulus
• tetapi malah merusak MouseInputTest::SgrModeTests#metadataSet20 untuk keyboard bahasa Inggris.

Meskipun saya tidak terlalu jauh mempersempit masalah lebih lanjut, saya pikir informasinya mungkin berguna.

Itu @MattKuhr yang sangat menarik. @ dan € benar-benar berfungsi untuk saya baik di dalam PowerShell dan WSL. 🤔
(Hanya untuk memastikan 100% - Ini adalah perbedaan saya pada master 67f68eb saat ini.)

Memang, saya memperbarui ke master saat ini dan mengujinya lagi. Sekarang karakter khusus berfungsi, kecuali € di PS.

Saya tidak yakin apa yang menyebabkan perilaku yang saya amati sebelumnya, perubahan kode yang sama persis digunakan. Saya mulai berpikir bahwa saya mungkin telah mengacaukan sesuatu dengan penerapan saat menguji, meskipun saya menguji beberapa kali, atau beberapa pembaruan windows yang diinstal dalam waktu yang berarti berpengaruh.

Ini adalah tangkapan layar dengan set keyboard Jerman saat menguji master saat ini:

Saya mengujinya di Debug dan Rilis (x64), Win 10.0.18362.116. Saya juga mencoba mengubah bahasa sistem, yang tidak berpengaruh. Tampaknya agak aneh, bahwa hanya dalam kasus khusus ini € tidak diterjemahkan dengan benar ..

Katakanlah, apakah itu mulai berfungsi di PowerShell jika Anda pertama kali Remove-Module PSReadline ? (Jangan khawatir: ini hanya akan memengaruhi sesi Anda saat ini.) Jika demikian, kami punya beberapa ide!

@ DHowett-MSFT Saya mengujinya dengan build master checkout kemarin tanpa perubahan pada tata letak keyboard Jerman pada tahun 18362.113 (pengaturan bahasa adalah bahasa Inggris)

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

Untuk karakter biasa Alt Gr bekerja seperti shift. Karakter lain apa pun dibiarkan pada nilai tanpa pengubah.

@ DHowett-MSFT Sebenarnya 😃

Kunci lainnya tetap berfungsi. Juga, sebelumnya 3 kecil akan ditulis seperti biasa 3, sekarang muncul dengan benar, seperti yang Anda lihat pada gambar di bawah.

Hai,

Hanya di sini untuk memberi tahu hal ini juga memengaruhi tata letak QWERTY Finlandia, membuat semua kombinasi AltGr seperti @, |, {}, [], ~, \ dll. Tidak dapat digunakan.

Semua itu tampaknya bekerja dengan baik dengan tambalan dari @lhecker di WSL, cmd dan PowerShell. Terima kasih @lhecker !

Halo, ini juga berfungsi untuk tata letak keyboard Azerty Prancis. Terima kasih @lhecker

Mengalami masalah dengan kombinasi Alt Gr misalnya “Alt Gr + <” (Garis miring terbalik, tetapi menghasilkan “<”) pada keyboard jerman swiss.

Saya telah memperbarui judul masalah ini agar lebih jelas bagi orang yang lewat tentang apa yang dilacaknya.

@ zadjii-msft Saya menemukan komentar Anda (?) AltGr terkait di terminalInput.cpp.
Jadi saya mengganti ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
dengan...
jika (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
return false;
}
... dan berhasil! Untuk sekarang. 😅

Perubahan ini juga memberi saya AltGr yang dapat digunakan di keyboard Prancis saya. Diuji sejauh ini dengan CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (keduanya dengan PSReadline 2.0.0beta4 tidak resmi yang perlu digunakan di VScode)

Perubahan ini juga memberi saya AltGr yang dapat digunakan di keyboard Prancis saya. Diuji sejauh ini dengan CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (keduanya dengan PSReadline 2.0.0beta4 tidak resmi yang perlu digunakan di VScode)

Saya memeriksa versi PSReadline saya dan memutakhirkan dari 2.0.0 ke 2.0.0-beta4 dan itu berhasil, sekarang € dan ³ juga berfungsi dengan benar di PS, baik 5.1 dan 6.2.1. 😄

Meskipun saya menemukan bug lain yang juga tampaknya terkait dengan PSReadline, tetapi tidak dengan AltGr atau tata letak keyboard secara langsung. Seperti yang Anda lihat di bawah, di Terminal CTRL 2 diterjemahkan menjadi " dan CTRL 7 (pada tata letak GER, di AS CTRL / ) menjadi ^_

Untuk kasus pertama, Menghapus PSReadline melakukan triknya, untuk kasus kedua tidak. Saya mencoba nomor lain dan kunci karakter khusus, tetapi hanya dua contoh ini yang dapat saya temukan sejauh ini. Perilaku tersebut identik untuk 5.1 dan 6.2.1. PSReadline adalah 2.0.0beta4.

Haruskah kita membuka masalah terpisah untuk ini?

Saya juga melihat masalah terkait pada papan ketik Portugis (Portugal).
Diharapkan: Alt Gr + 2/3/4/7/8/9/0 harus menghasilkan @ £ § {[]}, Alt Gr + e harus mendapatkan €

Terminal Windows:
-PS Core: Alt Gr + digit memicu PSReadline DigitFunction, kecuali 7 output ^ _
-PS Core: Alt Gr + € tidak melakukan apa pun
-Windows Powershell: Sama seperti PS Core
-CMD: Alt Gr + digit mengeluarkan digit, kecuali 7 keluaran ^ _
-CMD: Alt Gr + e mengeluarkan E

Konsol bawaan:
PS Core: Alt Gr + 2/3/4/7/8/9/0 output @ £ § {[]}, Alt Gr + E tidak melakukan apa pun
Windows PowerShell: Sama seperti PS Core
CMD - Semua bekerja

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

Solusi yang telah dicoba dan benar ketika kombinasi tombol "Alt Gr" tidak berfungsi adalah dengan menggunakan Alt + Kode Papan Angka .

Tapi, ini juga tidak berhasil!

657 "Alt + Numpad tidak berfungsi"

Saya akan menyarankan bahwa siapa pun yang membahas yang satu ini juga membahas yang terkait erat ini.

Saya juga dapat memverifikasi ini untuk keyboard Islandia. Kami menggunakan AltGr untuk menulis ini:
@ | € {[]} \ µ ~ `^

Sekadar catatan: masalah ini muncul di hampir semua teknologi baris perintah Microsoft. Itu sudah muncul di OpenSSH , masalah serupa muncul di PSReadline , dan di sini lagi, di mana tidak ada kombinasi AltGr yang tidak berfungsi.

Setiap kali saya mencoba sesuatu di baris perintah, masalah masukan selalu muncul. Saya masih tidak dapat menggunakan PowerShell dalam sesi jarak jauh, karena Home-End tidak berfungsi, dan masih tidak berfungsi melalui SSH.

Entah bagaimana, segitiga terminal-SSH-PSReadline ini dikutuk.

Di sini saya menggunakan layout keyboard PT-BR.

Untuk mendapatkan / saya menggunakan Alt Gr + Q

Saat menggunakan di Terminal, ini berfungsi seperti perintah undo. Itu hanya mengetik ulang perintah / huruf / kata terakhir saya

@Bayu_joo

di mana tidak ada kombinasi AltGr yang tidak berfungsi.

Anda bermaksud mengatakan bahwa tidak ada kombinasi AltGr yang berfungsi?

Katakanlah, apakah itu mulai berfungsi di PowerShell jika Anda pertama kali Remove-Module PSReadline ? (Jangan khawatir: ini hanya akan memengaruhi sesi Anda saat ini.) Jika demikian, kami punya beberapa ide!

Tidak berfungsi untuk saya (tata letak AZERTY Prancis)

jadi ..... ada ide baru? karena perbaikannya ...

`` c ++
jika (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
return false;
}
...

tidak berhasil untuk saya <. <

Edit:

Bukankah lebih pintar, mendeteksi bahasa keyboard utama, yang didefinisikan di mesin, dan kemudian melakukan rebind-stuff @microsoft ?

@Hedrauta aneh bahwa perubahan kode tidak bekerja untuk Anda. Tata letak keyboard apa yang Anda gunakan? Apa yang dilakukan Ctrl+Alt+xxx untuk Anda dalam CMD normal untuk nilai xxx yang digunakan dalam kombinasi dengan AltGr? Sejauh yang saya ingat, Ctrl+Alt harus selalu setara dengan AltGr ...

Jadi, untuk mengumpulkan beberapa data pengujian: Bagi saya, patch oleh @lhecker tampaknya berfungsi dengan baik. Ini ada di tata letak keyboard Jerman:

Terminal | Alt Gr + ß? \ | Strg + Alt + ß? \
- | - | -
Legacy cmd.exe | \ | \
Warisan pwsh.exe | \ | \
Terminal Windows, master , cmd.exe | ß | ß
Terminal Windows, master , pwsh.exe | _ (tidak ada) _ | _(tidak ada)_
Terminal Windows, master + Patch oleh @lhecker , cmd.exe | \ | \
Terminal Windows, master + Patch oleh @lhecker , pwsh.exe | \ | \

hasil yang sama seperti di https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
dengan Patch oleh @lhecker

Tapi di pwsh € - tanda masih tidak berfungsi pada tata letak jerman.

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 aneh bahwa perubahan kode tidak bekerja untuk Anda. Tata letak keyboard apa yang Anda gunakan? Apa yang dilakukan Ctrl+Alt+xxx untuk Anda dalam CMD normal untuk nilai xxx yang digunakan dalam kombinasi dengan AltGr? Sejauh yang saya ingat, Ctrl+Alt harus selalu setara dengan AltGr ...

Itu juga tidak membantu saya ...
Saya bahkan mencoba membuat solusi sendiri berdasarkan kode itu tetapi sejauh ini tidak berhasil ...

Saya menggunakan tata letak keyboard PT-BR, mencoba kombinasi berikut:

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

Saat menggunakan Terminal Windows
WSL: AltGr + Q = berfungsi seperti perintah urungkan, ini menulis ulang karakter terakhir saya yang diketik.
Powershell, CMD: AltGr + Q = menghasilkan karakter aneh ini cetakan seperti ^_

Edit:
Untuk membantu memvisualisasikan:

Masukan yang benar seharusnya
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 apa yang Anda dapatkan dengan CtrlAlt, bukan AltGr?

@ renatop7 apa yang Anda dapatkan dengan CtrlAlt, bukan AltGr?

Hasil yang sama

Dan di luar Terminal yaitu di CMD standar atau Windows Powershell atau Powershell Core? Apakah CtrlAlt selalu berperilaku seperti AltGr?

Dan di luar Terminal yaitu di CMD standar atau Windows Powershell atau Powershell Core? Apakah CtrlAlt selalu berperilaku seperti AltGr?

Ya, di luar Terminal berfungsi dengan sempurna.
Menggunakan dengan AltGr atau Ctrl + Alt Saya mendapatkan hasil yang diharapkan.

diambil 15 menit yang lalu: tidak berfungsi sama sekali
nah, apakah microsoft bahkan mengerjakan solusi yang terkait dengan masalah ini?

@Hedrauta aneh bahwa perubahan kode tidak bekerja untuk Anda. Tata letak keyboard apa yang Anda gunakan? Apa yang dilakukan Ctrl+Alt+xxx untuk Anda dalam CMD normal untuk nilai xxx yang digunakan dalam kombinasi dengan AltGr? Sejauh yang saya ingat, Ctrl+Alt harus selalu setara dengan AltGr ...

Uhm, bahasa Jerman Standar ?. di sini layar dari tampilannya: https://i.imgur.com/mvgHkxi.png
saya akan mencoba mengetikkan kunci melalui makro .... pengujian

itu seperti, alt kiri saya adalah Shift, bukan Alt ...
mencoba Hasil
Ctrl + Q ^ Q
CTRL + Alt + QQ
hanya Q q
Alt + QQ

Akan mencoba gif, memperbarui komentar kemudian
Sunting: ketika mencoba untuk gif itu, saya menyadari, bahwa Alt-Key saya dikenali salah .... ada yang tahu, di mana tombol virtual didefinisikan? akan memeriksanya juga;) tetapi saya tidak begitu berpengalaman di c ++ atau .... pengkodean apa pun;)

Hanya untuk saya sebagai noob cpp, saya memeriksa beberapa file, dan saya menemukan file
C: \ Program Files (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Jadi .... untuk tata letak bahasa Jerman, VK_Menu tidak ada, bukan? kami baru saja memiliki VK_LMENU, bukan?
saya akan mencoba beberapa perubahan dan melakukan beberapa pengujian ... akan mengedit hasilnya nanti
Sunting 1: Membangun memakan waktu lama, seperti saya membangun kembali seluruh sistem saya oO
Edit 2: setelah membangun semuanya, itu tidak berfungsi ... tetapi saya menyadari, bahwa VK_RMENU adalah AltGr, sementara VK_LMENU adalah kunci yang ingin kita lihat ditekan untuk mendapatkan @ atau \
tetapi VK_MENU tampaknya juga berfungsi, tetapi mungkin salah ditetapkan
Ini agak membingungkan saya, akan memeriksa yang ini setelah pengambilan bersih, membangun kembali, dan tidur siang

Untuk tata letak keyboard Jerman bahkan lebih buruk, karena Alt Gr + Q yang seharusnya hanya menghasilkan @ , menghapus input baris saat ini.
Itu tidak terjadi dengan wsl, saya juga tidak melihatnya dikonfigurasi untuk WT - jadi bagaimana ini terjadi?

Masih masalah:
Keyboard: Belgia (titik) AZERTY, bekerja di shell normal
Pemenang: 18362.175
Versi terminal: 0.2.1715.0

_Saya ingin meminta semua orang untuk menahan diri dari berkomentar bahwa mereka juga berurusan dengan masalah ini._

Sekarang harus jelas bagi semua orang bahwa masalah ini memengaruhi sejumlah besar kombinasi tombol dan dapat mengakibatkan efek samping yang tidak terduga dalam jumlah yang sama luasnya, untuk bahasa, versi windows, keyboard, dll. Yang sama luasnya.
Lebih dari setengah komentar bergaya #metoo, yang sama sekali tidak membantu memperbaiki masalah ini dan
hanya membuat komentar yang berguna menjadi kurang terlihat .
Apa yang sebenarnya hilang dan akan sangat membantu adalah bagi pengembang Windows yang berpengetahuan luas untuk mengatasi masalah ini dan mengirimkan PR.

Sementara itu, setiap orang yang mampu menyusun proyek ini dapat merasa bebas untuk mengganti bagian kode ini: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L396

dengan perbaikan eksperimental saya ini:

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

Ini akan memperbaiki sebagian besar kombinasi tombol untuk sebagian besar bahasa keyboard, termasuk misalnya karakter seperti @{}[] pada keyboard Jerman (atau yang serupa).

NB: Saya tidak berafiliasi dengan Microsoft dengan cara atau bentuk apa pun dan saya menulis ini karena saya pribadi menganggap komentar "#metoo" ini terlalu berisik / tidak produktif. 🙂
PPS: Saya yakin beberapa orang bertanya-tanya mengapa saya sendiri tidak mengirimkan PR. Mengutip diri saya sendiri : "Saya merasa perubahan saya tidak benar. Pasti ada alasan mengapa tidak semua karakter ditangani oleh WM_CHAR kan?" Artinya saya tidak benar-benar tahu apa kerugian dari perbaikan di atas dan bagaimana melakukannya dengan benar.

PPS: Saya yakin beberapa orang bertanya-tanya mengapa saya sendiri tidak mengirimkan PR. Mengutip diri saya sendiri: "Saya merasa perubahan saya tidak benar. Pasti ada alasan mengapa tidak semua karakter ditangani oleh WM_CHAR kan?" Artinya saya tidak benar-benar tahu apa kerugian dari perbaikan di atas dan bagaimana melakukannya dengan benar.

Salah satu cara untuk mengetahuinya adalah dengan mengirimkan PR dan dikoreksi oleh tim. Ini agak berlebihan, tapi saya pikir itu akan membuat segalanya bergerak lebih cepat.

@Nato_cinta_ # 1436

Perhatikan bahwa saat menggunakan aplikasi contoh misalnya VtPipeTerm, tombol alt-gr berfungsi di sana.

@HBelusca VtPipeTerm tidak didasarkan pada Terminal UWP baru dan karenanya tidak akan mengalami masalah ini.
Anda dapat membaca # 1436 untuk satu kemungkinan penjelasan tentang masalah yang mendasarinya.

@lhecker tidak didasarkan pada Cascadia, tetapi menggunakan implementasi pseudoconsole yang sama ... jadi sangat berguna untuk mengetahui bahwa ini tidak berlaku untuk semua konsumen pseudoconsole!

Terima kasih @HBelusca

Tombol khusus telah bekerja selama bertahun-tahun di terminal dan aplikasi windows. Mengapa kita mengalami masalah ini sekarang di tahun 2019? Apakah Anda sudah sepenuhnya mengimplementasikan kembali sistem input untuk program terminal? Saya berharap hal itu perlu dilakukan dan memperkenalkan kembali bug yang telah diperbaiki beberapa tahun yang lalu: s. Masalah ini tipikal di linux karena codepages, pemetaan keyboard bahasa dan tombol khusus windows, tetapi bug kritis ini ada dalam versi pratinjau aplikasi, yang tersedia di toko dan dipublikasikan di mana-mana

@ifilgud Ini adalah versi pratinjau yang tersedia di toko untuk alasan pratinjau . Masalah ini telah diprioritaskan dan ada juga PR yang diajukan untuk itu, jadi tidak perlu mengomentari masalah ini hanya untuk mengeluh.

@patriksvensson Saya tahu saya terutama mengeluh dan itu tidak "sopan", tetapi juga menanyakan alasan teknis untuk menjelaskan alasan bug seperti ini. Saya berharap memiliki beberapa kesalahan kecil untuk diperbaiki dalam versi yang hampir selesai (pratinjau), tetapi bukan salah satu yang seharusnya tidak ada dalam evolusi terminal, kecuali ditulis dari awal dan hanya diuji dalam bahasa Inggris (saya rasa itulah alasannya tidak mendeteksi ini di versi alfa pertama). Saya membuka terminal dan mencoba menulis "cd \" sebagai perintah kedua (yang pertama adalah "dir"), dan tidak berhasil. Sebagai pengembang perangkat lunak, hal ini sangat memengaruhi saya.

@lhecker sejauh ini, sangat bagus, setelah menerapkan perbaikan eksperimental Anda. Terimakasih banyak!!

Terima kasih banyak untuk semua orang yang menunjukkan ini dan telah memperbaikinya. 🌷

Seberapa sering Aplikasi MS Store diperbarui?
Jadi kapan kita bisa berharap untuk memperbaiki barang di aplikasi toko?

Ingin bekerja dengan terminal tetapi dengan keyboard Jerman, Anda bahkan tidak dapat menulis { } tanpa altgr. 😅

Punya masalah yang sama untuk tata letak keyboard Bokmål Norwegia (nb-NO) juga. Tidak dapat membuat [] atau {} atau $. PowerShell pada dasarnya rusak tanpa itu.
Menggunakan UWP / Microsoft Store versi 0.2.1715.0 di Windows 10 1903 18362.175.

hu_HU layout melalui AltGr: \ | & @ $ ; # <> {} [] Maksud saya, seberapa sering saya membuka tanda kurung kurawal, siku-siku, garis miring terbalik, pipa, tanda dolar, tanda pagar, "at", "dan", titik koma ... oh tunggu, setiap baris ?? :)

_Saya ingin meminta semua orang untuk menahan diri dari berkomentar bahwa mereka juga berurusan dengan masalah ini._

Sekarang harus jelas bagi semua orang bahwa masalah ini memengaruhi sejumlah besar kombinasi tombol dan dapat mengakibatkan efek samping yang tidak terduga dalam jumlah yang sama luasnya, untuk bahasa, versi windows, keyboard, dll. Yang sama luasnya.
Lebih dari setengah komentar bergaya #metoo, yang sama sekali tidak membantu memperbaiki masalah ini dan
_hanya membuat komentar yang berguna menjadi kurang terlihat_.

Pembaruan: Hal yang sama terjadi dengan semua digit jika digabungkan dengan Alt Gr .

bagaimana Anda melakukan rekaman gif ini?

@ Karl-WE Lihat lebih jauh di utas.

@ DHowett-MSFT Mungkin ada baiknya untuk mengunci utas ini dengan pesan di bagian bawah

Sementara terminal sangat tidak dapat digunakan untuk Powershell saat masalah ini masih hidup
Saya ingin memberikan solusi untuk Windows 10 1903 bagi mereka yang tidak dapat menahan diri hingga diperbaiki ..

Solusi:
gunakan tombol Windows +.
pergi ke tab karakter khusus pilih karakter Anda
beralih ke Terminal dan masukkan karakter

Membiarkannya tidak terkunci memberi orang ruang untuk melaporkan setiap kunci yang tidak berfungsi sehingga mereka berhenti mengajukan _issues_ individual tentang setiap kunci yang tidak berfungsi. Saya robek.

Mungkin ada lebih banyak kasus di mana karakter khusus tidak berfungsi seperti yang diharapkan. Jika saya ingin membuat karakter @ pada keyboard danish ada 3 cara untuk melakukannya: Alt Gr + 2, Ctrl Kiri + Alt + 2 Kiri, atau Alt Kiri + Numpad 64
2 opsi pertama memberikan hasil OP yang dilaporkan.
Opsi terakhir dilakukan di PowerShell:
Alt Kiri Onpres + Numpad 64 digit-argument: 64
Alt Kiri Onrelease: 64 @ karakter
Dalam cmd
Alt Kiri Onpres + Numpad 64: 64
Alt Kiri Onrelease: @ menghasilkan 64@
Dalam wsl
Alt Kiri Onpres + Numpad 64: (arg: 64)
Alt Kiri Onrelease: 64 @ karakter

Poin bagus @saadanerdetbare!

Masalah Alt + Numpad Anda tampaknya berasal dari fakta bahwa Terminal baru (Cascadia) mengirimkan kode pelolosan yang sesuai ke shell saat Anda memasukkan kode ini. Tetapi secara bersamaan bagian lain dari aplikasi _also_ menangani kasus ini, menerjemahkan kode Alt + Numpad ke dalam karakter yang sesuai dan memasukkannya ke dalam shell. Hal ini menyebabkan efek samping lucu dari karakter @ Anda diulang 64 kali (karena telah mengirimkan byte berikut ke shell: \x1b6\x1b4@ ).

Anda dapat mencobanya dengan menambahkan kode tambahan berikut di antara dua baris ini :

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

Ini akan menghentikan Cascadia mengirimkan kode pelolosan ini ke dalam shell. Setelah itu karakter Anda (mis. @) Akan muncul secara normal.
Atau Anda dapat menghapus blok kode ini untuk efek yang sama.

~ @saadanerdetbare Akan sangat luar biasa jika Anda dapat membuat masalah terpisah yang merinci masalah Anda, karena ini adalah bug yang tidak terkait dengan fungsionalitas AltGr. 🙂 ~
👉 # 1401
Seharusnya mencari masalah lain dulu. 🤦‍♂️

PS: Saya harus mengatakan bahwa melihat peningkatan kesiapan komunitas untuk men-debug sendiri hal-hal ini daripada mengandalkan orang lain yang tidak dikenal akan membuat saya secara pribadi sangat bangga. 🙈🙂

@saadanerdetbare menunda mengajukan masalah baru, yang itu # 1401: smile:

Saya masih mengalami ini di aplikasi pratinjau, saya memiliki keyboard Belgia, tidak mungkin untuk menulis @

@solispauwels Anda harus menunggu hingga rilis berikutnya (atau buat sendiri cabang master saat ini).

Hai, Saya baru saja menguji komit ini pada keyboard Jerman dan semuanya berfungsi selain altgr-E yang seharusnya mencetak simbol €. Sejujurnya saya tidak terlalu membutuhkan ini di terminal yang sering tetapi saya pikir saya mungkin akan menyebutkannya. Yang lain menyukai altgr-m untuk µ bekerja.

Pembaruan: Saya pikir Anda dapat mengabaikannya, simbol € juga tidak berfungsi di PowerShell standar sehingga tampaknya bukan kesalahan terminal, seharusnya memeriksa ini sebelumnya.

Semuanya tampaknya berfungsi di sini pada keyboard Prancis: AltGr+é"'(-è_çà)=$e menghasilkan ~#{[|`\^@]}¤€

Saya juga menggunakan keyboard Prancis (tapi saya di Belgia), dan saya mengalami masalah dengan AltGr +karakter. | # {} @ misalnya tidak berfungsi. Saya menggunakan rilis terbaru dari windows store 0.2.1715.0 di Windows 10 v1903.

@meuter Anda harus menunggu hingga rilis berikutnya (atau buat sendiri cabang master saat ini).

Perbaikan dari # 1436 belum termasuk dalam versi pratinjau yang tersedia di Microsoft Store

@antoineco @ sba923 terima kasih, itulah yang saya pikirkan. Saya baru saja mengkloning repo. Segera setelah vs2017 saya selesai dengan pembaruan, saya akan membangunnya kembali dari sumber :-)

Terima kasih semuanya telah bekerja keras dalam hal ini dan mengisi kotak masuk kami dengan laporan. Terima kasih secara khusus kepada @lhecker karena telah mengirimkan perbaikan! Kami baru saja mengirimkannya ke toko dengan rilis servis v0.2.1831.0. Mungkin perlu beberapa saat bagi toko untuk memprosesnya.

Kami baru saja mengirimkannya ke toko

Jadi, dari pengalaman saya dengan mempublikasikan aplikasi ke Windows Store, itu harus memakan waktu dari 3 hari hingga 3 minggu 😉

Kami baru saja mengirimkannya ke toko

Jadi, dari pengalaman saya dengan mempublikasikan aplikasi ke Windows Store, itu harus memakan waktu dari 3 hari hingga 3 minggu 😉

Tampaknya kurang dari 6 jam. 😋

Bagaimanapun, pada keyboard Swedia saya semuanya tampak baik-baik saja sekarang. 👍

Bekerja dengan keyboard Jerman sekarang 👍

Ia bekerja dengan keyboard Prancis dengan versi 0.2.1831.0! Terima kasih

Ia bekerja dengan keyboard Prancis dengan versi 0.2.1831.0! Terima kasih

Dikonfirmasi!

Kerja bagus!

@ DHowett-MSFT v0.2.1831.0 tampaknya menyertakan perbaikan ini tetapi, bukan perbaikan bug lain sebagai font powerline atau salin / tempel keybings, apakah ini normal?

Saya mengonfirmasi bahwa Alt-Gr berfungsi, tetapi menggunakan Ctrl-Alt untuk mengakses tombol keyboard yang sama tidak berfungsi dengan andal (jika sama sekali).

Dalam versi 0.2.1831.0 kombinasi AltGr sekarang bekerja dengan keyboard Finlandia.

@solispauwels satu-satunya perbaikan dalam versi 0.2.1831.0 adalah yang disebutkan dalam catatan rilis.

Perlu diketahui bahwa banyak OS 1803 atau yang lebih baru mungkin menghadapi bug dengan Windows Store versi 11905.1001.4.0
Toko akan "menumpuk" aplikasi untuk diunduh (lihat gambar) tetapi tidak akan mengunduh aplikasi, bahkan dengan pengunduhan otomatis diaktifkan dan jaringan bukan koneksi terukur.

Pengguna yang terpengaruh harus menekan "Periksa pembaruan" di Microsoft Store untuk mendapatkan Aplikasi Toko tetap dan memulai semua unduhan aplikasi yang tertunda.

Saya mengonfirmasi masalah ini telah diperbaiki dengan versi baru Terminal. Terimakasih banyak.

Saya dapat mengonfirmasi juga ini sudah diperbaiki sekarang. Anda mungkin ingin melepas pin dari masalah tersebut.

Ia bekerja kecuali kunci Euro, yaitu AltGr + e, setidaknya di keyboard Spanyol. Kombinasi lainnya bekerja dengan baik

Dari @ifilgud

Ia bekerja kecuali kunci Euro, yaitu AltGr + e, setidaknya di keyboard Spanyol. Kombinasi lainnya bekerja dengan baik

Diuji pada Windows 10 1903 (18362.175) menggunakan versi terbaru pada 08-07-2019 menggunakan keyboard AZERTY "Belgia (Periode)".

Hasil tes:

• semua kombinasi yang saya miliki tersedia di keyboard saya, termasuk simbol mata uang Euro (€), berfungsi di 2 dari 3 Konsol yang dikonfigurasi sebagai default di Terminal Windows: PowerShell Core dan 'cmd' (Prompt Perintah Windows)
• Hanya di "Windows PowerShell" simbol Euro (€) tidak berfungsi
  
  
  
  • Namun itu tidak berfungsi di Konsol Klasik PowerShell yang diluncurkan langsung dari Windows Start juga
  
  

Imo ini adalah masalah baru yang terkait dengan Windows PowerShell, tidak khusus untuk Terminal Windows yang menghosting Konsol itu.

Saya mengonfirmasi observasi @DeChrist . Di sisi lain, menekan Ctrl-Alt + (Key) tidak bekerja seperti yang diharapkan (jika seseorang ingin menggunakan kombinasi ini daripada AltGr).

Berikut pada Windows 10 build 18.362,175 menjalankan Windows Terminal Preview versi 0.2.1831.0, dengan keyboard Perancis, AltGr+E tidak menghasilkan € di semua kerang berikut:

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

Adakah yang bisa masalah dengan sisa AltGr _ di PowerShell_ memeriksa versi PSReadLine mereka jalankan?

$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 bisakah Anda mencoba:

1. menonaktifkan PSReadLine
2. meningkatkan ke beta4 , lihat https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Terminal Windows 0.2.1831.0
• PowerShell v7 (yang mencakup PSReadline 2.0.0-beta4)
• Tata letak keyboard QWERTZ Jerman

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

Ini sangat membuat frustasi karena ada bug lain yang terkait dengan mstsc yang telah diabaikan oleh Microsoft setidaknya selama satu dekade di mana AltGr + Q berhenti berfungsi jika sesi RDP terbuka. Dalam situasi ini, Ctrl + Alt + Q masih berfungsi, sehingga banyak orang menggunakannya sebagai solusi.

Apa yang HARUS dilakukan Microsoft TIDAK MENYENTUH KEYBOARD STREAM.

Shell (explorer.exe) harus menangkap penekanan tombol apa pun yang dibutuhkannya dan meneruskan semua yang lain ke hilir.
Terminal.exe pada akhirnya HANYA harus menangkap Alt-F4 - dan mungkin bahkan tidak - explorer.exe benar-benar harus menangkapnya dan berlaku untuk proses aktif.

Yang berarti Terminal.exe seharusnya hanya mengambil aliran keyboard dan meneruskannya ke proses anak yang aktif. Tidak ada lagi.

CMD.exe [command.com] harus tahu bagaimana menangkap apa yang dibutuhkannya dan kemudian meneruskan sisanya ke anaknya sendiri.

WSL harus mendapatkan input mentah sebanyak mungkin. JANGAN menggunakan AltGr. Ctrl-Alt dan AltGr BUKAN merupakan urutan keyboard yang sama. Di Linux terdapat jalan pintas yang menggunakan ctrl-alt -... yang menghasilkan hasil yang berbeda dari AltGr -...

Anda hanya memiliki SATU kesempatan untuk melakukannya dengan benar. Kesempatan pertama dalam hampir 40 tahun. Tolong, jangan sia-siakan kesempatan itu - Microsoft, saya melihat Anda :)

@thorsig ah, andai saja kami memiliki Anda saat tumpukan input Win32 dirancang empat puluh tahun yang lalu. Sayangnya, kami tidak melakukannya, jadi ada dua cara utama untuk menerima masukan keyboard:

• sebagai karakter, tanpa pengubah (jadi kami tidak dapat mendeteksi ALT untuk mengirimkannya melalui pipa terminal) atau arah penekanan tombol
• sebagai kode pindai, yang memiliki pengubah dan arah, tetapi sebenarnya hanya representasi dari lokasi kunci fisik_

Saat Anda mulai mencari di bawah level sistem operasi, pindai kode _are_ mode "input mentah mungkin". Namun, mereka membutuhkan sedikit memasak sebelum dapat diteruskan ke aplikasi yang membutuhkan input teks. (Sunting untuk menambahkan :) Aplikasi terminal sangat menyukai masukan mereka sebagai teks. Kami tidak dapat mengirim kode pindai melalui koneksi SSH! Meskipun kami bisa, penerima kemudian _itself_ perlu memahami tata letak keyboard untuk melakukan terjemahan. Mungkin mesin tanpa kepala tidak memiliki tata letak keyboard. (/ edit)

Jika semudah "dapatkan karakter literal yang mereka tekan dan kirimkan," Anda harus percaya bahwa kami akan melakukan hal itu. Kami tidak merekayasa solusi gila karena kami orang gila! :tersenyum:

Yah, saya ada di sekitar meskipun saya mungkin tidak memiliki banyak petunjuk bagaimana menangani aliran input pada saat itu.

Namun, Linux bekerja dengan kode kunci mentah secara default, jadi itu tidak masalah. Namun, contoh koneksi ssh Anda cacat, karena ssh tidak pernah dieksekusi secara langsung oleh aplikasi terminal - ada shell di dalamnya (atau abstraksi OS secara keseluruhan seperti WSL) yang bertanggung jawab atas apa yang mencapai shell.

Jika apa yang Anda nyatakan benar, setiap aplikasi yang pernah ditulis untuk Windows (berjalan di atas explorer) harus menerapkan penanganan keyboard intrinsiknya sendiri. Mereka tidak. Karena diurus hulu dan hilir.

Saya telah melihat kode dan bagian saya dari "SMH". Bisakah saya melakukannya dengan lebih baik? Mungkin diberi waktu. Bisakah saya mengomel tentang itu? Mengingat bahwa saya tidak punya waktu untuk melakukannya sendiri - mungkin tidak.

Saya masih merasa perlu untuk disebutkan, itu terlalu direkayasa sebagaimana adanya, dan itu akan menyebabkan masalah hilir di beberapa titik (mungkin lebih cepat daripada nanti).

Yah, saya ada di sekitar meskipun saya mungkin tidak memiliki banyak petunjuk bagaimana menangani aliran input pada saat itu.

Namun, Linux bekerja dengan kode kunci mentah secara default, jadi itu tidak masalah. Namun, contoh koneksi ssh Anda cacat, karena ssh tidak pernah dieksekusi secara langsung oleh aplikasi terminal - ada shell di dalamnya (atau abstraksi OS secara keseluruhan seperti WSL) yang bertanggung jawab atas apa yang mencapai shell.

WSL tidak melakukan terjemahan apa pun. conhost.exe atau terminal Windows (atau Gnome-terminal jika Anda menjalankan aplikasi grafis melalui, katakanlah, XMing) melakukan terjemahan yang tepat untuk dikirim ke pty. Dan bahkan cangkangnya ... bukan cangkang itu sendiri yang melakukan sebagian besar pekerjaan. Ini adalah driver terminal dan aplikasi di ujung master (yang, sekali lagi, adalah conhost.exe, Terminal Windows, mungkin Terminal Cygwin jika Anda mau, dan aplikasi terminal Linux).

Jika apa yang Anda nyatakan benar, setiap aplikasi yang pernah ditulis untuk Windows (berjalan di atas explorer) harus menerapkan penanganan keyboard intrinsiknya sendiri. Mereka tidak. Karena diurus hulu dan hilir.

Sebagian besar aplikasi sebenarnya tidak peduli dengan input keyboard mentah. Itu ditangani melalui beberapa pustaka Win32 dengan cara yang secara inheren bersifat lossy. Mereka tidak menggunakan input keyboard mentah secara langsung. Sebagian besar aplikasi hanya peduli dengan karakter, selain game yang mungkin peduli dengan input tata letak fisik dengan tepat. Either way bekerja dengan baik.

Saya telah melihat kode dan bagian saya dari "SMH". Bisakah saya melakukannya dengan lebih baik? Mungkin diberi waktu. Bisakah saya mengomel tentang itu? Mengingat bahwa saya tidak punya waktu untuk melakukannya sendiri - mungkin tidak.

Saya masih merasa perlu untuk disebutkan, itu terlalu direkayasa sebagaimana adanya, dan itu akan menyebabkan masalah hilir di beberapa titik (mungkin lebih cepat daripada nanti).

Saya sarankan Anda melihat Gnome-Terminal, analog Linux, dan memeriksa apakah itu lebih sederhana atau lebih kompleks. Saya menduga lebih kompleks karena X sebenarnya lebih aneh daripada GDI32 atau API windowing mana pun yang digunakan.

Apakah ada regresi dari 0.2.1831.0 ?
Pada keyboard Denmark, Windows Terminal Preview v0.3.2142.0 tidak merespons AltGr.

Terminal Windows (Pratinjau)
Versi: 0.3.2142.0.0
Microsoft Windows 1903 [Versi 10.0.18362.267]

Saya memiliki keyboard Denmark dan v0.3.2142.0 Windows build 10.0.18362.239 Ini adalah sistem operasi bahasa Inggris tanpa paket bahasa. Karakter khusus Alt Gr bekerja di sini, urutan Ctrl + Alt tidak

Saya memiliki keyboard Denmark dan v0.3.2142.0 Windows build 10.0.18362.239 Ini adalah sistem operasi bahasa Inggris tanpa paket bahasa apa pun. Karakter khusus Alt Gr bekerja di sini, urutan Ctrl + Alt tidak

Os Saya: Win10 Home 1903 Build 10.0.18362.267
Sistem Operasi Denmark dengan paket bahasa AS tambahan diinstal meskipun paket bahasa Denmark adalah default.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - apakah ada petunjuknya? !!!

Os Saya: Win10 Home 1903 Build 10.0.18362.267
Sistem Operasi Denmark dengan paket bahasa AS tambahan diinstal meskipun paket bahasa Denmark adalah default.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - apakah ada petunjuknya? !!!

Untuk mendapatkan semua detailnya:
aku berada
Menangkan 10 Enterprise en-US 1903 build 18362.239
Keyboard Denmark, tanpa paket bahasa

Baru saja mencoba masuk ke akun dengan paket bahasa AS sebagai default, - memasang terminal di sana dan beralih ke keyboard danish untuk melihat apakah paket bahasa yang dipilih memiliki pengaruh, tetapi tidak beruntung di sana.

Tidak tahu apakah ini mungkin petunjuk bagi seseorang yang tahu tetapi sebelum meningkatkan ke 1903 dari 1809 Keyboard Layar ( c:\windows\system32\osk.exe ) menunjukkan perilaku yang sama di semua aplikasi conhost, cmd.exe, ubuntu / wsl dan powershell.exe (mengabaikan AltGr) tetapi pada tahun 1903 tampaknya sudah diperbaiki.

Saya dapat mengonfirmasi bahwa urutan AltGr _some_ tidak akan berfungsi.
AltGr Q (= @ ) bekerja untuk saya, sedangkan misalnya AltGr 8 (= [ ) tidak.

Saya telah membuat versi toko v0.3.2142.0 secara lokal untuk men-debug masalah ini. Karena saya tidak dapat menemukan cara membuat AzureConnector, saya harus mengecualikannya: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Ternyata v0.3.2142.0 yang saya buat secara lokal berfungsi dengan baik. Semua urutan AltGr bekerja dengan benar.
Hanya versi toko Terminal yang tidak. Mungkinkah AzureConnector salah di sini, karena saya mengecualikannya? (Maksud saya, saya ragu itu masalahnya, tetapi hanya untuk memastikan ...)

@ DHowett-MSFT @miniksa Dapatkah Anda (atau seseorang) memeriksa ulang versi Store v0.3.2142.0 dan membandingkannya dengan versi yang dibuat secara lokal?

Saya memiliki masalah yang sama. Terminal tidak dapat digunakan dengan masalah itu karena AltGr adalah suatu keharusan. Dan mengapa utas ini ditutup? Ini harus menjadi masalah prioritas utama.

Dan mengapa utas ini ditutup?

@MasMedIm Anda mungkin memperhatikan setelah pemeriksaan lebih dekat bahwa kami yakin bug ini telah diperbaiki, dan bahkan merilis versi dengan perbaikan.

@lhecker itu sangat tidak biasa. Konektor Azure seharusnya tidak ada hubungannya dengan ini karena berada di lapisan yang berbeda (koneksi, bukan kontrol) ... tetapi itu menarik.

Dapatkah Anda (atau seseorang) memeriksa ulang versi Store v0.3.2142.0 dan membandingkannya dengan yang dibuat secara lokal?

Versi yang saya miliki di mana karakter khusus AltGr berfungsi adalah versi toko

AltGr ( ~#{[|`\^@]}¤€ ) berfungsi dengan baik di sini dengan keyboard Prancis, Windows 10 versi 1903 build 18362.267, dan Windows Terminal Preview 0.3.2142.0

@ sba923 Saya juga memiliki keyboard Prancis dan versi windows yang sama. Kombinasi AltGr yang tidak berfungsi adalah: & ~ # {[| `\ ^ € ù \
Terminal saya juga diunduh dari toko. Saya akan mencoba membangunnya di lokal untuk dilihat.

Hanya untuk menguraikan situasi saya, - beberapa kombinasi AltGr + Key benar-benar berfungsi sementara beberapa tidak.

Tidak bekerja:

| Kunci | AltGr + Key, diharapkan: |
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

Pekerjaan:

| Kunci | AltGr + Key, diharapkan: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Catatan: '´', '¨' adalah tipe kunci mati.

Sistem: Windows 10 64bit Home 1903 Build 10.0.18362.267
Terminal Windows: Pratinjau v0.3.2142.0 - Versi toko
Tata letak keyboard: Denmark.

@MasMedIm , @ sba923 , @lhecker - Apakah Beranda Versi Windows Anda seperti milik saya?
Edit: Lupakan pertanyaan saya. Saya baru saja akan memulai pengejaran angsa liar di sana ;-), tetapi @lhecker tampaknya telah menyelesaikan regresi!

@ DHett-MSFT @ henrik-jensen et. al .: Saya menemukan penyebab regresi. ¯ \ _ (ツ) _ / ¯
... dan itu membuat kita semua di sini menjadi orang bodoh karena memperhatikan sebelumnya. 😂

profiles.json berisi pintasan jenis Ctrl+Alt+[0-9] untuk dengan cepat melompat ke Tab 1-10.
Jika Anda menghapus pintasan ini dari file Pengaturan ( Ctrl , ) regresi telah diperbaiki.
Kombinasi tertentu seperti AltGr E seharga € sayangnya belum pernah berhasil dan seseorang harus meluangkan waktu yang diperlukan untuk memperbaikinya.

Karena cara kerja Windows API lama, akan sulit untuk membedakan secara andal antara pintasan Ctrl Alt dan penekanan tombol AltGr yang sebenarnya, tetapi saya akan memeriksa apakah situasinya dapat diperbaiki entah bagaimana.

@ler 🥇 👍
Dikonfirmasi. Jubii

Kombinasi tertentu seperti AltGr E seharga € sayangnya belum pernah berhasil dan seseorang harus meluangkan waktu yang diperlukan untuk memperbaikinya.

AltGr E -> '€' berfungsi pada tata letak keyboard Denmark saya. Saya akan mencoba menambahkan tata letak Jerman pada saya untuk melihat apakah itu dapat direproduksi pada pengaturan saya.

Bagaimana kalau hanya menggigit peluru? Simpan CMD.EXE lama untuk aplikasi lama (DOS) dan desain Terminal baru hanya untuk masa depan? Bukan berarti kompatibilitas ke belakang tidak bagus - tetapi terkadang Anda hanya _have_ memutuskan hubungan ...

@ler 🥇 👍
Dikonfirmasi. Jubii

Kombinasi tertentu seperti AltGr E seharga € sayangnya belum pernah berhasil dan seseorang harus meluangkan waktu yang diperlukan untuk memperbaikinya.

AltGr E -> '€' berfungsi pada tata letak keyboard Denmark saya. Saya akan mencoba menambahkan tata letak Jerman pada saya untuk melihat apakah itu dapat direproduksi pada pengaturan saya.

Bahasa Jerman ~ Kezboard ~ up yang diinstal, Keyboard :-) *, dan AltGr E -> '€' berfungsi dalam pengaturan ini.

Sunting: * 'z' / 'y' ditukar dengan keyboard jerman / danish.

profiles.json berisi pintasan jenis Ctrl+Alt+[0-9] untuk dengan cepat melompat ke Tab 1-10.

Untuk beberapa alasan pintasan ini adalah alt + [0-9] di file pengaturan saya sehingga saya tidak mengalami masalah

Beberapa pertanyaan sekarang muncul pada saya:

• @lhecker Mungkin kita harus membuat masalah baru untuk regresi untuk dapat ditemukan / riwayat dan Anda dapat menambahkan solusi tambalan Anda untuk itu? Edit: Bagus - @lhecker membuat permintaan tarik # 2235
• Saya ingin tahu di mana default ~ settings.json ~ profiles.json dibuat. Ini bukan sumber daya jadi saya berasumsi itu sulit dikodekan di suatu tempat? Edit: menemukannya CascadiaSettings.cpp L369
• Pintasan alternatif apa yang harus dipilih sebagai gantinya. Mungkin yang @saadanerdetbare miliki di ~ settings.json ~ profiles.json (Apakah mereka default di sebelum 0.3.2142.0? Edit: Sepertinya begitu - # 2014)

@lhecker @ henrik-jensen yang masuk akal. Saya menginstal dari toko tepat setelah dirilis di sana dan saya telah membuat beberapa perubahan pada profiles.json Jadi jika pembaruan tidak menimpa file karena itu kustom dan bukan default saya tidak mendapatkan pintasan Ctrl + Alt

@ DHett-MSFT @ henrik-jensen et. al .: Saya menemukan penyebab regresi. ¯_ (ツ) _ / ¯
... dan itu membuat kita semua di sini menjadi orang bodoh karena memperhatikan sebelumnya. 😂

profiles.json berisi pintasan jenis Ctrl+Alt+[0-9] untuk dengan cepat melompat ke Tab 1-10.
Jika Anda menghapus pintasan ini dari file Pengaturan (Ctrl,) regresi telah diperbaiki.
Kombinasi tertentu seperti AltGrE untuk € sayangnya belum pernah bekerja dan seseorang harus mengambil waktu yang diperlukan untuk memperbaikinya.

Karena cara kerja Windows API lama, akan sulit untuk membedakan secara andal antara pintasan CtrlAlt dan penekanan tombol AltGr yang sebenarnya, tetapi saya akan memeriksa apakah situasinya dapat diperbaiki entah bagaimana caranya.

Ty untuk responnya, memang pengaturan Ctrl + Alt + [0-9]

@saadanerdetbare , Ya, itu diubah dari pengaturan Anda ke yang baru di sini # 2014 oleh @ zadjii-msft

Saya mengonfirmasi bahwa pintasan baru memang merusak AltGr ( ~#{[|`\^@]} ) pada keyboard Prancis saya.

Alasan sebagian dari kita tidak melihat regresi terkait dengan pemutakhiran 0.3 yang tidak menimpa profiles.json , yang didokumentasikan di Windows Terminal Preview v0.3 Release :

Catatan: Jika Anda sebelumnya telah menginstal Terminal sebelum rilis ini, pengikatan kunci ini hanya akan muncul secara default setelah Anda menghapus profiles.json dan mengizinkannya untuk dibuat ulang. Anda dapat menyimpan profiles.json asli Anda di tempat lain dan menyalin penyesuaian Anda atau cukup tambahkan pengikatan kunci ini secara manual. Kami sadar ini bukan pengalaman yang ideal dan sedang berupaya untuk meningkatkannya.

Seseorang dapat menggunakan ctrl + alt + shift + _digit_, meskipun itu tidak mudah untuk memasukkan ...

@ henrik-jensen Saya membuka # 2235.

@thorsig Anda telah diberi tahu tentang keadaan dalam lanskap Windows API.
Terutama mengingat bahwa misalnya bash di Linux (seperti kebanyakan shell yang mungkin ingin Anda gunakan di Windows di masa mendatang) _tidak_ menerima kode kunci mentah, melainkan teks biasa yang diisi dengan urutan escape. Urutan pelolosan yang perlu dihasilkan terminal Anda dari peristiwa keyboard. Shell Linux Anda _tidak_ menangani kode kunci mentah. Terminal Anda melakukannya.
Sebelum Anda melanjutkan ini, Anda harus terlebih dahulu memahami cara kerja xterm dan vt100 (dan yang lebih baru).
Dan btw: kode kunci di Linux juga hanya abstraksi virtual (! = Raw) di atas kode pindaian dari keyboard Anda - lihat keymaps.5 . Satu-satunya perbedaan adalah bahwa pada Windows telah diputuskan berabad-abad yang lalu bahwa Ctrl + Alt sama dengan AltGr, karena beberapa keyboard di mana tidak memiliki tombol AltGr, tetapi seseorang masih ingin dapat menekan AltGr. Orang-orang yang memutuskan ini mungkin berusia 60+ saat ini. Mengubah ini tidak sepele dan hanya memiliki manfaat yang tidak signifikan (karena Anda sudah dapat mendeteksi penekanan tombol AltGr dalam praktiknya).

Saya mengonfirmasi bahwa pintasan baru memang merusak AltGr ( ~#{[|`\^@]} ) pada keyboard Prancis saya.

Alasan sebagian dari kita tidak melihat regresi terkait dengan pemutakhiran 0.3 yang tidak menimpa profiles.json , yang didokumentasikan di Windows Terminal Preview v0.3 Release :

Catatan: Jika Anda sebelumnya telah menginstal Terminal sebelum rilis ini, pengikatan kunci ini hanya akan muncul secara default setelah Anda menghapus profiles.json dan mengizinkannya untuk dibuat ulang. Anda dapat menyimpan profiles.json asli Anda di tempat lain dan menyalin penyesuaian Anda atau cukup tambahkan pengikatan kunci ini secara manual. Kami sadar ini bukan pengalaman yang ideal dan sedang berupaya untuk meningkatkannya.

Seseorang dapat menggunakan ctrl + alt + shift + _digit_, meskipun itu tidak mudah untuk memasukkan ...

Lebih mudah menggunakan alt + _digit_ dan ini mirip dengan pintasan di gnome-terminal.
Ini berfungsi di keyboard Prancis saya.

Jika Anda menggunakan Alt + digit , ketahuilah bahwa Anda tidak akan dapat mengirim kunci tersebut ke aplikasi konsol.

: tada: Masalah Windows Terminal Preview v0.3.2171.0 .: tada:

Tautan yang berguna:

• Catatan Rilis
• Download Toko

AltGr ( ~#{[|`\^@]}¤€ ) berfungsi dengan baik di sini dengan keyboard Prancis, Windows 10 versi 1903 build 18362.267, Windows Terminal Preview 0.3. 2171 .0, dan pintasan pengalihan tab disetel ke Ctrl+Alt+digit .

Kerja bagus!

Terima kasih atas konfirmasinya!

Terima kasih kembali!

Perbaikan 0.3.2171.0 dikonfirmasi untuk sistem saya - Keyboard Denmark Win10 Home 1903 build 10.0.18362.267.
Menghapus profiles.json untuk mendapatkan pengaturan default dan sekarang AltGr juga berfungsi untuk penginstalan baru (saya asumsikan).
Kerja bagus @lhecker dan semua orang yang terlibat.

Hai, saya rasa saya memiliki masalah ini di versi 0.7.

Saya tidak dapat memasukkan tombol garis miring pada keyboard saya baik menggunakan keypad numerik atau AltGr + Q (keyboard ABTN2 Brasil dari laptop Samsung yang tidak memiliki tanda tanya / tombol garis miring).

Edit: Saya tidak dapat memasukkan tombol AltGr apa pun.

Setelah menghapus versi PSReadline yang lebih lama, semuanya berfungsi sekarang.

FWIW, saya telah menulis skrip PowerShell terlampir untuk memverifikasi versi PSReadline apa yang ada di sistem saya / mana yang aktif.

CheckPSReadLineStatus.zip

HTH

Untuk memperbaiki masalah yang sama seperti yang dilaporkan beppler, lakukan:

Setelah menghapus versi PSReadline yang lebih lama, semuanya berfungsi sekarang.

Dari Sesi PowerShell yang Ditinggikan lakukan:

Install-Module -Name PowerShellGet -Force
Exit

Dari sesi cmd yang ditinggikan lakukan:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

Apa status masalah ini?
Karena melihat masalah terkait tampaknya sudah diperbaiki, tetapi masih tidak berfungsi untuk saya. Untuk mencetak karakter ~ pada tata letak keyboard Italia, saya biasa melakukan Alt + 126 tetapi ini memiliki perilaku yang berbeda tergantung pada jenis terminal, tetapi tidak satupun dari mereka saya bisa mendapatkan karakter ~ dicetak, saat melakukan langsung di shell yang mendasarinya (git / cmd / powershell / wsl tidak tertanam di terminal windows) berfungsi seperti yang diharapkan

Ini terjadi pada saya dengan versi terbaru dari terminal windows, pada saat penulisan adalah:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax Saya memutuskan input Alt + Numpad di # 3117. Sekarang # 3117 telah digabungkan dan masalah terkait telah diperbaiki, kami dapat bekerja untuk memperkenalkan kembali input numpad ke dalam basis kode.
Saya akan menjadikan ini sebagai perilaku opsional dan dapat dikonfigurasi, karena saya cukup yakin bahwa sebagian besar pengguna potensial aplikasi Terminal tidak akan mendapat manfaat darinya lagi. Oleh karena itu, aplikasi harus secara default mengirimkan semua masukan keyboard yang mungkin ke shell sehingga Anda dapat mengonfigurasi keybindings vim, dll. Yang lebih canggih.
Menerapkan ini seharusnya menjadi sedikit lebih mudah segera setelah # 4192 digabungkan. Anda harus menambahkan logika tambahan di sini dan memeriksa apakah tombol Alt (dan hanya tombol Alt) ditahan di states , sedangkan vkey berasal dari numpad bukan dari tombol numerik biasa . Jangan ragu untuk mengirimkan PR kapan saja! 🙂

@lhecker terima kasih atas tanggapan yang cepat, saya hanya ingin mengetahui keadaan ini karena setiap masalah yang saya temukan ditutup tetapi masalahnya masih ada.
Tidak yakin saya akan menemukan PR tentang ini, saya tidak pernah melihat kode sebelumnya 😄 jadi saya benar-benar tidak tahu harus mulai dari mana, terlepas dari saran Anda.

Saya hanya ingin tahu cara memperbaiki alur kerja saya untuk git rebase -i karena sekarang saya harus membuka sesuatu seperti notepad ++, ketik karakter ~, salin dan tempel di terminal.

Supaya saya mengerti: Anda berada di utas tentang AltGr dengan pertanyaan tentang _alt + numpad sequences_? Ini mungkin alasan mengapa semua utas yang Anda temukan ditutup: masalah AltGr sudah diperbaiki.

Saya yakin kami memiliki masalah terpisah yang melacak masalah input alt + numpad.

Ya, Anda benar, maaf atas kebingungannya. Saya pikir # 657 mungkin yang benar