Как сказал ZyX на #vim, этот вопрос звучит так: «Почему эксперты Vim предпочитают вкусное теплому?»,
«Эксперты Vim» не предпочитают буферы вкладкам: они используют буферы в качестве прокси-серверов, а вкладки - в качестве рабочих областей. Буферы и вкладки имеют разные цели, поэтому предпочтение одного другому не имеет смысла.
Проблема с буферами и вкладками связана с путаницей , вызванной сочетанием независимых фактов.
Большинство «современных» текстовых редакторов и IDE используют метафору табуляции для представления загруженных файлов. Эта метафора действует как информационная система - она показывает пользователю, какие файлы открыты и их состояние - и как интерактивное устройство - она позволяет пользователю манипулировать (переупорядочивать, выбирать, закрывать ...) этими открытыми файлами. Несмотря на их многочисленные ограничения, вкладки есть везде, и люди привыкли к ним и ожидают их везде.
Vim представил вкладки в 7.0 как способ для своих пользователей создавать специальные «рабочие пространства». Ничего в их особенностях, их определенных опциях, их определенных командах или их:help
разделах не предполагает, что вкладки могут или должны использоваться в качестве файловых прокси.
Ничего, кроме названия и появления «вкладок», конечно, что приводит к большой путанице.
Без :set hidden
, который по умолчанию отключен и не очень легко найти, Vim делает невозможным переключение на другой буфер без записи текущего или отмены его изменений. У новых пользователей, не подозревающих об этой опции, нет другого выбора, кроме как переключиться на использование тяжелых окон или ближайшую «похожую на вкладку» функцию, которую они могут найти: вкладки.
«Закладка» - неудачный выбор имени для этой функции, особенно в эпоху, когда доминирует идея, что чтение документации - пустая трата времени.
В Vim вкладки - это абстракция, построенная поверх окон, а сама абстракция построена поверх буферов. Каждый новый уровень добавляет полезные функции, но ограничивает ваш рабочий процесс.
«Буферный путь»
При работе на основе буфера файлы, с которыми вы работаете, распределяются по одному измерению. Вы можете циклически перебирать свои буферы, вы можете получить доступ к определенному буферу, набрав часть его имени (с завершением) или его номера, вы можете чередовать буферы, вы можете довольно легко на них ориентироваться. Там в основном нет трения.
Открыты восемь буферов, виден только один:
Переключение по номеру:
Переключение по имени:
Буферы - это прокси-файлы Vim. Если вы думаете с точки зрения файлов, вы думаете с точки зрения буферов.
«Оконный путь»
В оконном рабочем процессе ваши «файлы» распределены по одному и тому же «виртуальному» измерению, как если бы вы использовали только буферы и по двум другим «физическим» измерениям. Но декартовы пространства, в которых находятся эти измерения, почти полностью разделены: перемещение в другой буфер по-прежнему означает «перемещение в другой файл», а перемещение в другое окно - нет. Буфер, который соответствует желаемому файлу, может отображаться в этом окне, но он также может отображаться в другом, может быть, на другой вкладке или не отображаться вообще.
В Windows навигация между открытыми файлами либо становится слишком сложной, либо слишком простой, даже если 'switchbuf'
и :sb
. Главным образом потому, что вы вынуждены использовать два набора команд для того, что по сути одно и то же: доступ к буферу.
Окна имеют свое использование, как описано ниже, но у них нет того, что нужно для замены буферов в чьем-либо рабочем процессе.
Здесь я работаю над Vim Colourscheme. Два окна - это разные виды одного и того же буфера: верхнее служит справочной, с таблицей цветовых кодов, используемых в схеме цветов, а нижнее - там, где я работаю:
Windows не спроектированы как файловые прокси и не могут быть превращены в них: они являются «контейнерами» или «областями просмотра», предназначенными для того, чтобы предложить вам просмотр в буфер. Ни больше ни меньше.
«Способ вкладки»
В рабочем процессе на основе вкладок вы, по сути, пытаетесь имитировать пользовательский опыт, к которому вы привыкли в предыдущем редакторе, при этом полностью игнорируя саму природу вкладок Vim. Если мы на мгновение забудем, что эта стратегия, как правило, очень непродуктивна, также невозможно, как и в случае с окнами, заставить Vim придерживаться этой парадигмы «один файл - одна вкладка», не теряя при этом большой гибкости.
Продолжая работать с теми же файлами, что и выше, таблица занимает значительное место практически без пользы. Все мои файлы и все мои вкладки называются, javascript*.vim
поэтому я не могу этого сделать 3gt
и быть уверенным, что окажусь в нужном месте, и невозможно получить доступ к определенной вкладке по имени. Добавьте к этому тот факт, что его метка вполне может быть очень бесполезной, но совершенно логичной [Quickfix List]
… Поскольку практического способа привязать файл / буфер к вкладке не существует, у вас остается только один практичный способ навигации между вкладками. / buffers / files: cycling.
И да, моя вкладка изобилует только 8 вкладками, представьте, если бы у меня было 20!
Восемь буферов открываются на восьми вкладках (неправильно)
Две вкладки для двух конкретных задач (справа)
Страницы вкладок - это «контейнеры» или «окна просмотра», предназначенные для размещения одного или нескольких окон, сами по себе также «контейнеры», предназначенные для хранения буферов.
В заключение
«Эксперты Vim» (допустим, я могу говорить так, как если бы я был одним из них) не предпочитают буферы над вкладками: они просто используют Vim в том виде, как он был спроектирован, и им совершенно комфортно с таким дизайном:
«Эксперты Vim» загружают 2, 30 или 97 буферов и очень рады, что им не приходится иметь дело с пространственным распределением;
когда им нужно сравнить два файла или работать в одной части текущего буфера, сохраняя другой в качестве ссылки, «эксперты Vim» используют окна, потому что именно так они и должны использоваться;
когда им нужно какое-то время работать над отдельной частью проекта, не вмешиваясь в их текущее представление, «эксперты Vim» загружают новую вкладку.