Почему Vim требует, чтобы каждое сопоставление клавиш имело уникальный код ascii?


2

Насколько я понимаю, Vim не может различить <c-s-[key]>и <c-[key]>потому что они отображаются на один и тот же код ASCII. А также та же самая причина, почему <c-i>эквивалентна <tab>. Кроме того , вы не можете отобразить <c-1>, <c-;>и т.д. , потому что нет ASCII представление.

Я читал, что некоторые люди говорят, что это ограничение хорошо, так как оно более эргономично, чтобы избежать аккордов / модификаторов в пользу слов в любом случае (например, с ключом лидера). Но некоторые операции больше подходят для аккордов / модификаторов (например, вещи, которые вы, вероятно, будете повторять)

Я спрашиваю, почему Vim был спроектирован таким образом? Или почему, поскольку Vim является открытым исходным кодом, нет сборки Vim или GVim, в которую добавлена ​​поддержка этого? Кажется позором для редактора, который настолько нелепо настраивается, чтобы так себя ограничивать. Кто-нибудь может мне это объяснить?


Для тех, кто интересуется обходными путями, я смог использовать для этого autohotkey. Vim распознает от <c-f1> до <c-f12> и от <s-f1> до <s-f12>, поэтому вы можете использовать autohotkey для сопоставления любой комбинации cs- [key] с одной из них (только для vim), затем сопоставьте один из них с тем, что вы хотите в vim
Стив Вермейлен

Ответы:


3

Из-за того, что ввод с клавиатуры обрабатывается внутри, это, к сожалению, сегодня вообще невозможно, даже в GVIM. Некоторые сочетания клавиш, такие как Ctrl+ не алфавитный, не могут быть сопоставлены, и Ctrl+ буква против Ctrl+ Shift+ буква не может быть различена. (Если ваш терминал не отправляет для него отдельный код termcap , чего большинство не делает.) В режиме вставки или командной строки попробуйте ввести комбинацию клавиш. Если ничего не происходит / вставлено, вы не можете использовать эту комбинацию клавиш. Это также относится к <Tab>/ <C-I>, <CR>/ <C-M>/ <Esc>/ <C-[>и т. Д. (Единственное исключение - <BS>/ <C-H>.) Это известная проблема и предмет различных дискуссий по vim_dev и IRC-каналу #vim.

Некоторые люди (прежде всего Пол ЛеоНерд Эванс) хотят это исправить (даже для консоли Vim в терминалах, которые поддерживают это), и выдвинули различные предложения, ср. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8

По сути, Vim должен был бы использовать более современные библиотеки, которые поддерживают современные возможности эмулятора терминала, для получения необработанных кодов ключей. Проблема состоит в том, что эти коды клавиш (неправильно) используются во многих местах исходного кода Vim, и обновление такой центральной структуры затруднено.

Но на сегодняшний день никаких патчей или добровольцев еще не появилось, хотя многие выразили желание иметь это в будущем выпуске Vim 8. Если вы считаете, что это трудная задача и можете внести свой вклад, список рассылки vim_dev - это место для добровольчества.


3

Vim разрешает модификаторы <C- и <CS- на клавишах со стрелками, потому что эти комбинации обрабатываются некоторыми эмуляторами терминала, но я думаю, что это все. Обычно он ограничивается кодами ключей, которые могут генерироваться эмуляторами терминала.

Vim был спроектирован таким образом, во-первых, потому что это Vi-IMproved, а vi был спроектирован для использования с терминалами CRT того времени, которые отправляли и получали символы ASCII. С тех пор Vim развивался в соответствии с принципами, обсуждаемыми в

:help design-goals

Особенно актуальны эти предметы:

  • Сведите к минимуму использование CTRL и других модификаторов, их сложнее набирать.
  • Люди переключаются с одной платформы на другую и с графического интерфейса пользователя на терминальную версию. Функции должны присутствовать во всех версиях или, по крайней мере, в максимально возможном количестве при разумных усилиях. Старайтесь избегать того, что пользователи должны переключаться между платформами, чтобы эффективно выполнять свою работу.
  • Vim не является необычным редактором графического интерфейса, который пытается выглядеть красиво за счет того, что он менее согласован на всех платформах. Но функциональные возможности графического интерфейса приветствуются.

Таким образом, любые коды клавиш, доступные только из графического интерфейса, а не эмулятора терминала, как правило, избегаются, поэтому все, что можно сделать в gvim, можно сделать в vim. Это считается большинством пользователей Vim функцией.


1

Список рассылки vim-dev , вероятно, является лучшим местом для этого вопроса.

Не могли бы вы уточнить эту часть: «как вещи, которые вы, вероятно, будете повторять»?

В любом случае, vim, который делает то, что вы хотите, не существует, потому что об этом мало заботятся пользователи. Аккорды являются одновременно и эргономическим кошмаром, и результатом ограничений немодального редактирования. Когда вы удаляете все ярлыки на уровне ОС, для ваших отображений просто не хватает доступных ключей, что заставляет вас создавать сложные и непрактичные аккорды. <C-S-w>ничуть не лучше, чем ,wлюбая фантазия.

Подход Vim с такими ключевыми последовательностями, как ,bcи все, что вы хотите, намного более масштабируем и намного мягче с вашим телом.


1
Некоторые вещи, например отображение для: tabnext /: tabprev, часто выполняются несколько раз подряд (а также не работают с оператором повтора). Или поменять текущее окно другим. Или двигаться вперед по слову верблюда. Я бы сказал, что в этих случаях csw лучше, чем w, если вы начнете делать их несколько раз подряд.
Стив Вермейлен,

.повторяет изменения, не удивительно, что он не работает с :tabnext/ :tabprev. Учитывая, что использование множества вкладок во многом является ошибкой в ​​Vim, gt/ gTболее чем достаточно, IMO. Возможно, менее «знакомый», чем сложные и не интуитивно понятные ярлыки, используемые большинством других редакторов, но в значительной степени настолько эффективный, если не больше. Но мы не согласны с этим, по-видимому. Во всяком случае, если вы хотите разветвиться Vim ... во что бы то ни стало, вперед!
Ромен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.