| 1 |
Hi! |
| 2 |
|
| 3 |
Походу, с горячими кнопками в линухе творится какая-то фигня. В принципе, |
| 4 |
это не новость, все давно в курсе. Но я тут на днях снова погулял по этим |
| 5 |
граблям, поэтому решил описать всё на что наткнулся - может всё не так |
| 6 |
плохо и кто-нить знает как решить/обойти хоть некоторые из этих проблем. |
| 7 |
|
| 8 |
- Многие комбинации кнопок передаются через Esc-последовательности. |
| 9 |
Из-за этого в терминале не работает одиночное нажатие Esc - он ждёт, не |
| 10 |
пойдёт ли следом Esc-последовательность. Решается в некоторых |
| 11 |
приложениях (пока видел только в mc) заданием таймаута на ожидание |
| 12 |
Esc-последовательности после одиночного Esc. Что криво уже хотя бы |
| 13 |
потому, что это требуется поддерживать индивидуально в приложениях - |
| 14 |
если бы этот таймаут настраивался в xterm, было бы немного адекватнее. |
| 15 |
|
| 16 |
- Из-за Esc-последовательностей возникают некоторые проблемы. Например, |
| 17 |
комбинация Alt+1 в Vim видна как "<Esc>1". Соответственно, возникает |
| 18 |
конфликт с отдельными нажатиями Esc и 1. Типичный пример: для выхода из |
| 19 |
режима вставки и перехода в начало файла требуется нажать Esc и 1G. |
| 20 |
Но при наличии обработчика Alt+1 нажатие Esc и 1 вызывает этот |
| 21 |
обработчик. Решение - после нажатия Esc подождать секунду, а уже потом |
| 22 |
нажимать 1G - дико раздражает. |
| 23 |
|
| 24 |
- Если Esc-последовательности отключить (включить XTerm*eightBitInput и |
| 25 |
выключить XTerm*metaSendsEscape), то в Vim всё становится хорошо: |
| 26 |
Alt+1 посылает "<A-1>", и больше не конфликтует с "<Esc>1". |
| 27 |
Но на самом деле Alt+что-то теперь посылает разные юникодные символы, |
| 28 |
поэтому ввод этих символов (даже через compose key) обрабатывается в Vim |
| 29 |
как нажатие Alt+что-то. И приходится конкретно эти символы вводить через |
| 30 |
Ctrl-V. Но всё это терпимо, и больше чем на пол беды не тянет. |
| 31 |
Настоящая беда в том, что в mc напрочь отрубаются все Alt-комбинации, |
| 32 |
и я не смог через mc.keymap вообще никак уговорить его реагировать на |
| 33 |
юникодные символы, посылаемые xterm-ом. Пришлось возвращать настройки |
| 34 |
xterm обратно и отказываться от использования Alt+1 в Vim. |
| 35 |
|
| 36 |
- У меня не работают никакие комбинации начинающиеся на Ctrl+Shift, нигде - |
| 37 |
даже xkbwatch не видит Ctrl+Shift. Насколько я понимаю, это связано с |
| 38 |
тем, что у меня по Ctrl+Shift переключается язык ru/en, и Xkb просто |
| 39 |
"съедает" Ctrl+Shift лишая другие приложения возможности увидеть любые |
| 40 |
комбинации содержащие Ctrl+Shift. |
| 41 |
|
| 42 |
- Более того, схожая проблема "съедания" кнопок наблюдается и в других |
| 43 |
случаях. Например, у меня в fluxbox настроено переключение на предыдущий |
| 44 |
рабочий стол по кнопке Win (a.k.a. Super_L a.k.a. Mod4). В результате, |
| 45 |
никакие комбинации Win+что-то ни в одном приложении больше не работают. |
| 46 |
Точнее, они работают, но уже после того, как сменится рабочий стол. :( |
| 47 |
Как я догадываюсь, это вызвано тем, что комбинация кнопок обрабатывается |
| 48 |
не в момент отпускания кнопки (как, вероятно, в винде), а в момент её |
| 49 |
нажатия. Если бы был способ переключить Xorg в режим обработки кнопок в |
| 50 |
момент отпускания, возможно удалось бы более точно определять нажатую |
| 51 |
комбинацию и исключить эти ложные срабатывания по первым кнопкам |
| 52 |
комбинации вроде Ctrl+Shift или Win. |
| 53 |
|
| 54 |
Одним словом, всё это полная лажа. :( Линух 21 год назад родился как |
| 55 |
эмулятор терминала, но до сих пор делает это паршиво. |
| 56 |
|
| 57 |
-- |
| 58 |
WBR, Alex. |
Archives