Анализатор производительности для vim

Фон

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

Не смейтесь, но идея пришла от Clippy: http://en.wikipedia.org/wiki/Office_Assistant Конечно, я не хочу создавать еще один забавный материал, такой как энергия. Я имею в виду серьезный анализ эффективности, который может быть особенно полезен для новичков vim.

Вопрос

Имеет ли смысл и есть ли какая-либо теория, покрывающая такой анализ?

Ответ 1

Сверху моей головы:

Это потребует значительного количества AI/нечеткой классификации. Трудно проанализировать, что пользователь "пытается сделать" (часто пользователь не ясен и будет отвлекаться: "О, исправьте эту опечатку, пока я здесь, выровняйте этот комментарий... хорошо, теперь с другим задача)
уже оптимален!)
Также TIMTOWTDI; вы не можете просто пойти и сказать "здесь лучший способ". Это зависит от вкуса, раскладок, раскладки клавиатуры, доступности плагина, что не так.
Я думаю, что лучший способ научиться чему-то подобному - это
- документация для чтения
- следующее переполнение стека [vim]

Скептицизм остался позади, я вижу хороший рынок для плагина с намеками:

Я бы подумал о "всегда-на" намеках, как вы видите в дрянных шахматных машинах (показывая доступные поля, атакуемые поля, риски, шампуры, вилки и визуализацию результата обмена):

Вы можете показать положение маркеров на краю (чтобы люди стали более осведомленными о них, особенно <, > и тому подобное). Плагин, который делает это сейчас, ShowMarks: на скриншоте обратите внимание на метки для a и b, но также (nifty! ) местоположения для { и ( и подобных текстовых движений (я видел >, . и другие только сейчас). ¹
:set relativenumber уже помогает пользователям думать о 13j вместо jjjjjjjjjjjjj - но см. мои предпочтения здесь Перемещение точки между символами путем быстрого поиска
Я мог видеть, что плагин подсветки синтаксиса случается, когда в текстовые объекты (word, WORD, предложение, абзац или идентификатор, parenblock, braceblock) будут выделены растущие оттенки цвета фона. Если мы подумаем о способе наложения полезного намека (какой ключ использовать для движения текстового объекта), вы получите очень хороший намек, IMO.
Я мог видеть подсказку для нажатия "o", чтобы переместить курсор на другой конец визуального выделения.
стандартный matchit уже довольно полезен в подсказке о совпадающих скобках (хотя он не намекает на фактический стиль клипа, который вы могли бы использовать %, чтобы попасть туда)
Другими вдохновляющими видами использования +signs являются: errormarker.vim (который использует подсказки шара в дополнение к размещению графический знак); Я вижу, что это хорошо используется (хотя бы для указания определенных тем документации)

Что касается подсветки текстового объекта, я подозреваю, что он может уже существовать. Я сейчас посмотрю

_{¹ Я думаю, чтобы получить больше оценок, мне нужно было сделать (?)}

 :let g:showmarks_include+="<>[]"
 :ShowMarksOn

Я также рекомендую установить updatime на что-то быстрое (скажем, 500 мс) Суб >

Ответ 2

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

Но я вижу множество трудностей:

Вы показали бы "правильный путь" для выполнения предыдущей задачи или более короткого пути без учета ее правильности? Например, новый пользователь Vim мог бы сделать Vjjjd для удаления 4 строк, предлагаете ли вы V3jd или 4dd или, может быть, dip, если это подходит или что-то еще другое?
Как бы вы определили "правильный путь"? На основе консенсуса здесь о SO или о каком-то списке рассылки или о том, чтобы попросить группу авторитетных экспертов Vim?
Как бы вы определили задачу, которую вы анализируете? Каковы границы задачи?

Что бы это ни было, это чистая идея.

Ответ 3

Мое личное мнение по этому поводу заключается в том, что инструмент для создания клипов очень трудно обрабатывать. Как упоминалось выше, я думаю, что самая сложная часть этого - понять намерения пользователей при написании текста. Если вы отложите это и получите четкий способ добавления семантики к вашим намерениям, ваша жизнь может стать намного проще!

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

Я думал о программировании обобщенного интерфейса vi, чтобы применить его ко всем типам редакторов/текстовых полей (то есть: pidgin).

Одним из результатов этого процесса мыслей является то, что входной язык должен быть несколько регулярным (или не более контекстным). поэтому вход экземпляра vi может быть представлен конечным автоматом. Это не полностью доказано, а скорее смутное предположение! Очевидно, что необходимо приложить больше усилий, чтобы команды повторения (например, 13j) не могли получить язык в контекстно-свободные грамматики.

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

Я хотел бы услышать ваше мнение по этому поводу, поэтому, пожалуйста, прокомментируйте, и если есть что-то более активное, мы можем попытаться поговорить об этом.

изменить

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

однако не то, что особенно макросы q[a-z] @[a-z] могут быть трудно найти и заменить. Я бы предположил, что это NP полный.