2013-05-30 3 views
8

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

Я попытался использовать опции -w и -W vim, чтобы сбрасывать каждое нажатие клавиши на трубу. Тем не менее, Vim не сообщает о нажатиях клавиш в режиме онлайн, поэтому я не мог получить надежные временные метки.

Я также пытался перехватить входные данные из tty, записав его в трубку и перенаправив его как stdin для Vim. Но тогда Vim просто завершает работу с:

Vim: Warning: Input is not from a terminal 

Я также нашел этот трюк, чтобы захватить все ключевые: http://vim.wikia.com/wiki/Capture_all_keys. Я ничего не знаю о vimscript, но я чувствую, что это не то, что я ищу.

Итак, теперь я думаю: мне нужно перехватить входные данные из tty, обработать его, а затем записать его на какой-то поддельный tty, который Vim будет использовать в качестве входа. Согласитесь ли вы, что это лучший подход? Если да, то какие намеки на то, как я могу это сделать?

ответ

2

Порывшись немного больше и смотреть в «сценарий» исходный код, я нашел это:

man 7 pty 
man 4 pts 
man 3 openpty 

Создание нового псевдо-терминал кажется, что путь здесь, и я собираюсь дать ему выстрел.

Редактировать: Представляется, что это работает. Если кто-то сталкивается с подобной проблемой, проект можно найти по адресу https://github.com/Baranowski/habit-vim/.

0

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

+0

Я сделал еще несколько поисков, но не смог найти ничего, что могло бы подойти мне. «Экран» способен регистрировать вывод, но не вход. «script» регистрирует вход и выход, но вы не можете заставить его регистрировать только входные данные. Все клавиатурные шпионы, которые я обнаружил, либо регистрируют все входные данные клавиатуры (независимо от tty/процесса, которые его получают), либо требуют специальных драйверов на уровне ядра. Я бы предпочел использовать то, что даже не требует прав root, и IMO это должно быть выполнимо. –

+0

Прошу прощения за некропость, но я вижу пример использования для Vim. Если у вас есть несколько уровней для устранения неполадок (tmux + zsh + ssh + ... + Vim), то устранение неполадок с отображением ключей Vim также означает устранение неполадок с любым количеством родительских слоев. http://stackoverflow.com/a/10805437/1043529 - кажется, есть встроенная опция для ведения журнала, хотя я еще не тестировал ее http://vim.wikia.com/wiki/Map_Ctrl-S_to_save_current_or_new_files - пример ключевой команды, предназначенной для Vim, но обычно перехваченной терминалами –

1

Возможным подходом может быть исправление кода Vim: в цикле, где вводят клавиатурные входы, сохраняют их и записывают в файл. (Или вы могли бы somewhow добавить их к .viminfo)

https://code.google.com/p/vim/source/browse/src/gui.c

кажется, что следующая функция ждет, чтобы получить ввод от пользователя.

int gui_wait_for_chars(wtime) 

Таким образом, вы можете найти точку входа для ввода с клавиатуры.

1

Если вы работаете с mac os x, вы можете использовать this code для регистрации ваших вводов ключей в vim.

Этот код сильно зависит от старой команды unix script, которая составляет open source.

Используя это будет выглядеть примерно так (после загрузки источника):

$ make keylog   # No Makefile needed for an easy case like this. 
$ ./keylog vim myfile # ... and use vim a bit, then exit. 
$ hexdump -C outfile # `outfile` is the hard-coded keylog file name. 

Вы могли бы также cat outfile, но это, вероятно, содержит много управляющих символов, которые делают вывод трудно читать.

Кроме того, пожалуйста, не используйте этот код для гнусных целей. Это опасно.

Смежные вопросы