Фон
Я создаю приложение, в котором он обнаруживает, какие документы вы используете из файловой системы. Для этого он должен получить доступ к атрибуту AXDocument активного окна. MacVim предоставляет это. Запуск Vim в терминале не обеспечил бы этого.
Я только что опубликовал опрос, чтобы спросить, какие редакторы, которые интересуются моим приложением. Значительное количество людей, использующих Vim, использовало его непосредственно из командной строки.
Почему бы не использовать графический интерфейс Vim?
Почему некоторые люди предпочитают запускать Vim таким образом против реализации GUI, как MacVim?
Какие преимущества дает это предложение? Насколько я понимаю, вы можете отправлять файлы в MacVim из командной строки так же легко, как в командной строке Vim.
Эти причины могут быть разными для каждого конкретного разработчика, но я предполагал следующее:
Возможно, у вас нет доступа к gui (think ssh) или просто к привычке.
Хотя я не использую какую-либо особенность, исключительную для версии GUI (никогда не прикасайтесь к мыши при редактировании), я нахожу GVIM более приятным для глаз для визуализации шрифтов и управления цветом. Поэтому единственной причиной использования версии cli является отсутствие доступа к графической среде (например, при доступе к удаленной машине через ssh). Использование GVIM также позволяет повторно использовать терминал, из которого он был вызван, без использования screen.
возможность запуска vim в разделе screen обеспечивает
screen и перемещать ветки их вокруг. screen супер потрясающий. Это также обеспечивает дополнительный слой текстовой буферизации, в котором вы можете выполнять поиск по регулярному выражению - это полезно, если вы создаете команду оболочки, которая является длительностью страниц, и вы ищете там определенное слово.в дополнение к использованию screen консоль vim обеспечивает лучшую интеграцию с оболочкой. Хотя можно запускать команды оболочки изнутри gvim (опять же, я не уверен, как это относится к Mac, я парень linux), есть ограничения. Я редко использую gui vim, поэтому я не уверен в точном ограничении. Например, цветовые коды ANSI удаляются. Я нахожу это раздражающим, потому что я, как правило, взаимодействую с SCM, например, запустив :!git diff --cached, чтобы проверить изменения индекса перед фиксацией. Это делает несколько быстрее и более удовлетворительным (mmm, diffy!) Читать, если оно цветет.
Раньше я чувствовал, что gvim было большим улучшением для просмотра различий, но я изменил цвет фона моего терминала на темный нечерный оттенок и установил
:highlight DiffAdd ctermbg=Black
:highlight DiffChange ctermbg=Black
:highlight DiffDelete ctermbg=Black
:highlight DiffText cterm=Bold ctermbg=None
Результатом этого является то, что в режиме diff различный текст отображается с черным фоном, а неизменный текст окрашен цветом фона терминала. Для параллельных различий это работает чудесно, так как вы можете сразу сказать, с другой стороны, является ли данная строка изменением или добавлением; для не-бок о бок вы сможете увидеть неизмененную часть в измененной строке.
Это означает, что вы можете оставить синтаксическую раскраску и по-прежнему иметь возможность видеть diff. Опять же, вам нужно установить цвет фона терминала на уникальный, темный, не черный оттенок. Это средство доступно в эмуляторах терминалов, которые я использую (yakuake/konsole и roxterm) и многих других. ^[?Mac^M"mya)^O^Op
Это также предполагает, что вы используете цветовую схему, предназначенную для использования с темным цветом фона; Я использую модифицированный delek.
Хотя я этого не пробовал, есть также возможность запускать консоль vim в 256-цветном режиме на терминалах, поддерживающих этот режим, который, как я считаю, включает большинство или все современные. Это может помочь сделать большую часть тонкости графических символов GUI доступной для консоли vim. ^["mp
Мне также нравится, что он живет там, где он был запущен, и быстро запускается. Поэтому, если я перемещаюсь в оболочке, по своему усмотрению, я могу редактировать файл, не прерывая этот поток, или не должен обрабатывать эту операцию в другой части концептуальной недвижимости. Имея меньше вещей, чтобы отслеживать это большой плюс. Возможно, это полезно и для фона, например, если мне нужно захватить содержимое необработанной переменной оболочки через xclip. Если бы я создал окно графического интерфейса, я мог бы немного вспомнить, где эта оболочка была или, возможно, уже закрыла ее.
Моя основная причина использования gui vim вообще заключается в том, что он имеет несколько больше смысла, поскольку что-то порождено из приложения gui, например браузера. На практике я никогда не делаю этого, и я подозреваю, что он достаточно эквивалентен тому, что в нем появилось новое окно терминала с новой консолью vim. Хотя, вероятно, есть некоторые функции управления окнами (оконный менеджер), которые являются эксклюзивными для реализаций gui. Это очень похоже на вариант использования, который вы обсуждаете.
gvim на самом деле просто базовый эмулятор терминала, в котором работает vim, а некоторые меню и кнопки панели инструментов вверху.
Итак, если у вас уже есть полноценный полнофункциональный эмулятор терминала, вы можете использовать его вместо этого, так как вы будете использовать окно терминала того же типа, которое вам знакомо во всех сеансах вашего терминала.
Другим преимуществом является то, что он позволяет легко переключаться на оболочку внутри vim, а затем легко переключаться.
В Windows я предпочитаю gvim. В Linux это vim внутри gnome-терминала, что приятно и настраивается, спасибо.
Чтобы избежать (или, по крайней мере, минимизировать) использование мыши.
Некоторые варианты gvim не могут обрабатывать некоторые из моих горячих клавиш
какое-то другое окно, когда я пытаюсь для компиляции программы
иногда они просто не могут использовать шрифты как фиксированный или конечный (подумайте о "конечной смелости" - некоторые gvim вариации просто растягиваются "terminus normal" вместо рендеринг с отдельным шрифтом)
cli обычно работает быстрее, чем gui, особенно если работать в реальном текстовая консоль (невозможно на mac хотя)
почти нет преимуществ при использовании GUI, и я потерял бы способность запустить на экране, ssh, приостановить процесс с помощью ctrl + z и многое другое.
vim более эффективен с огромными файлами (100-500 МБ .csv или .xml файлы в моем случае).
gvim бьет vim hands-down при использовании для сравнения файлов (gvimdiff): установка шрифта (требуется больше содержимого на экране?), перетаскивание строки разделения окна (хотите увидеть больше одного файла, а не другого) и т.д..
Кроме этого, я не видел других различий мэра и использовал gvim, кроме как при работе с большими файлами, потому что я считаю его более удобным в графической среде (gnome).
Основная причина, по которой я использую командную строку, - это то, что большую часть моего времени я провел в терминале, и мое использование vim отражает это. Я не открываю vim долгое время, просто редактируя разные файлы, а затем открываю другие, не закрывая его; Обычно я открываю файл или два делаю несколько изменений, затем выполняю некоторые задачи в командной строке, возможно, меняю каталог и открываю vim где-то в другом месте. При использовании gui происходит существенное отставание при открытии редактора. Это не беспокоило бы меня, если бы я однажды открыла его и оставила его открытой, но я не работаю так. Таким образом, командная строка работает лучше для моего рабочего процесса. Кроме того, поскольку нет никакой полезной функции GUI в командной строке и наоборот, я всегда просто придерживался командной строки, так как она мне подходит лучше.
Кодирование пары через экран vim + gnu является точкой продажи для меня. Я работаю в screen/vim весь день, это позволяет людям удаленно работать в моем сеансе экрана, и мы можем редактировать файлы плавно. Сейчас так жарко.
Как сам большой пользователь vim, хотя я знаю о GUI vims, я не использую их только по привычке.
Я использую vi с 1990 года, перешел на vim несколько лет назад, но все еще называю его псевдонимом (alias vi = vim).
Для меня это просто привычка. vim работает хорошо, как есть. Возможно, gui предлагает больше, и я должен исследовать его, но vim работает так, как я ожидаю, и хочу этого.
К иногда упоминаемому "недостатку":
:se mouse +=a; это позволяет выбирать, перемещать границу окна с помощью мыши, даже над экраном GNU поверх ssh