Да, это возможно. Макрос для запущения скрипта должен быть сделан как:
macro index X "<enter-command>source /path/to/your/command|<enter>"
Замена index
и X
с названием меню и ключом, который Вы хотите использовать. Отметьте |
после названия команды.
Для взаимодействия с терминалом сценарий должен будет вновь открыться /dev/tty
. Сценарий может затем передать обратно STDOUT muttrc команды для порождения других действий. Для выполнения макроса, можно передать обратно push Y
где Y
ключ, с которым связывается макрос.
Иногда у Vim возникают проблемы с файлами, которые имеют необычно длинные строки. Это текстовый редактор, поэтому он предназначен для текстовых файлов с длиной строк, которая обычно не превышает нескольких сотен символов в ширину.
Файл базы данных может содержать не так уж много новых символов строки, поэтому это может быть одна единственная строка длиной 100 Мб. Вим будет недоволен этим, и хотя это, вероятно, сработает, загрузка файла может занять довольно много времени.
Я, конечно, открыл текстовые файлы намного больше 100 Мб с Vim. Файл даже не нужно помещать в память сразу (т.к. Vim может подкачать изменения на диск по мере необходимости).
"загрузить VIM без .vimrc и плагинов (чистый VIM), например. для HUGE-файлов
gvim -u NONE -U NONE -N largefile.sql
По моему опыту Вим давит не на большие файлы , а на длинные строки . Используйте эту команду, чтобы mysqldump
использовал короткие строки за счет большого файла:
$ mysqldump --complete-insert -u -p
Кроме того, вы можете открыть Vim и попросить его не разбирать ваш .vimrc
файл или загрузить любые плагины с помощью этой команды:
$ vim -u NONE output.sql
Загрузка Vim таким образом использует меньше памяти и не требует от Vim разбирать весь файл так, как это делают многие плагины.
.Vim не просто загружает файл as-is в память. Он преобразует его во внутренние структуры (строки, слова и т.д.), выполняет подсветку синтаксиса с помощью внутреннего скриптового языка и т.д.; все это потребляет память (намного больше байта на символ) и процессорное время.
.Я иногда открываю большие резервные копии баз данных в текстовом формате .sql. Очень большие файлы или файлы с очень длинными строками часто кажутся открытыми в vim. Это может быть связано с обработкой синтаксиса и подсветкой цвета, как упоминалось в ответах @zzapper и @demonkoryu.
Быстрым решением может быть нажатие кнопки "control-G" во время загрузки файла для отмены предварительной обработки подсветки синтаксиса.
Надеюсь, ваша проблема больше связана с потребностью VIM-ов во временных файлах (таких как подкачка), чем в оперативной памяти.
Во многих случаях временные файлы, созданные VIM, находятся в том же каталоге файла, который Вы открываете. Если это так, то вы можете проверить это, проверив доступное дисковое пространство в текущей директории.
К счастью, есть хорошая документация о том, как можно указать другое место для индексирования/замены файлов VIM:
Вы также можете отключить файл подкачки
Попробуйте использовать меньше
вместо vim
, если вы хотите просмотреть большой файл напрямую. Vim пытается сделать много разных вещей при первой загрузке - сканирование файла (потенциально за несколько проходов), чтобы попытаться определить, какой синтаксис использовать, и выполнение подсветки синтаксиса, и поиск модных линий в верхней и нижней части файла. Затем, когда вы редактируете файл, vim сохраняет swap-файлы и сохраняет деревья отмены (история отмены в vim разветвленная, а не линейная, как в каждом (?) другом редакторе), и постоянно пересматривает подсветку синтаксиса по мере изменения текста, и т.д.
Ничто из этого не является обязательным объяснением того, почему это должно быть так непригодно для гигантских файлов, но это скорее объяснение некоторых из причин, почему это так.
Вы можете попробовать загрузить его как двоичный файл. Мне повезло с этим для действительно больших нетекстовых файлов
vim -b HUGEFILE
. Также IIRC может использовать vim в качестве шестнадцатеричного редактора, см .: http://usevim.com/2012/06/20/vim- binary-files /