Vim 8 був випущений сьогодні, а в коментарях до випуску згадується нова "пакетна" функція. Що це таке і як я повинен його використовувати?
Найголовніше, чи замінює він хороших старих менеджерів плагінів ?
Vim 8 був випущений сьогодні, а в коментарях до випуску згадується нова "пакетна" функція. Що це таке і як я повинен його використовувати?
Найголовніше, чи замінює він хороших старих менеджерів плагінів ?
Відповіді:
Перш за все, відповідну документацію можна знайти :h packagesу нещодавно складеній версії Vim8 та тут, на Github .
Перша важлива примітка стосується лексики: У Vim8 пакет визначається так:
Пакет Vim - це каталог, який містить один або кілька плагінів.
Це означає, що новий менеджер пакунків був створений, щоб допомогти користувачам керувати всіма їх плагінами в одному архіві. Документ перераховує такі переваги:
Пакет можна завантажити як архів і розпакувати у власному каталозі. Таким чином, файли не змішуються з файлами інших плагінів. Це полегшує оновлення та видалення.
Пакет може бути сховищем git, mercurial тощо. Це робить його дуже просто оновити.
Пакет може містити кілька плагінів, які залежать один від одного.
Пакет може містити плагіни, які автоматично завантажуються під час запуску, та ті, які завантажуються лише за потреби
:packadd.
Тому ідея полягає у створенні папки, що містить усі плагіни із такою структурою:
$HOME/.vim/pack/my-plugins/
start/
foo/
plugin/
foo.vim
syntax/
some.vim
bar/
plugin/
bar.vim
opt/
buzz/
plugin/
buzz.vim
Зміщення папки визначається параметром packpath(Див. :h 'packpath').
Зверніть увагу на важливість структури вашої папки:
startПапка містить плагіни , які будуть завантажуватися автоматично при запуску.optПапка містить «додаткові» плагіни, завантажені з packaddкомандою.plugin, autoload, doc, ...) є ті , що ви використовували в плагінах.Ось резюме папок:
start/foobar/plugin/foo.vim " always loaded, defines commands
start/foobar/plugin/bar.vim " always loaded, defines commands
start/foobar/autoload/foo.vim " loaded when foo command used
start/foobar/doc/foo.txt " help for foo.vim
start/foobar/doc/tags " help tags
opt/fooextra/plugin/extra.vim " optional plugin, defines commands
opt/fooextra/autoload/extra.vim " loaded when extra command used
opt/fooextra/doc/extra.txt " help for extra.vim
opt/fooextra/doc/tags " help tags
Після того, як ці файли знаходяться в потрібному місці, відкриваючи Vim, він завантажить плагіни startта зробить optдоступними файли :packadd.
Тепер, чи може ця функція замінити існуючі менеджери плагінів?
Відмова від відповідальності: Ця частина може бути трохи переконана.
Я думаю, що підхід цього нового менеджера пакунків насправді інший, ніж той, який ми використовували, оскільки він створений для управління одним (або декількома) архівами, що містять деякі додатки.
У вікні менеджер пакунків не надає функцій для оновлення плагінів один за одним, автоматичного отримання їх з адреси Github або вибору плагінів, які ви хочете включити / відключити.
Я не впевнений, що буде дійсно зручно використовувати його поза коробкою (тим більше, що обробка вкладених сховищ управління версіями може бути болючим завданням), але, можливо, це привід зробити менеджерів плагінів більш ефективними?
Тепер також можна уявити переміщення існуючих плагінів для прийняття структури, необхідної менеджеру пакунків, та керування ними безпосередньо з файлової системи. Можливо, буде створено якусь обгортку для використання цієї нової функції.
EDIT Як запропонував @Sato Katsura, ось примітка про helptagsкоманду. Коміт Vim8 ввів два рядки в helptagdoc :
:helpt[ags] [++t] {dir} Generate the help tags file(s) for directory {dir}. When {dir} is ALL then all "doc" directories in 'runtimepath' will be used.
Що означає, що новий менеджер пакунків полегшує генерацію довідкових тегів, поміщених в архів користувача. За допомогою єдиної команди :helptags ALLгенеруються всі довідкові теги.
:helptags ALL.
:helptag ALLя перегляну і додам, дякую за пропозицію!
updateвашим плагінам або cleanїх (видаляючи невикористані плагіни). Для бонусних очок він також використовує нову функцію управління роботою, щоб паралельно проводити кілька оновлень. Я думаю, що це справді перспективно, тому що він покращує вбудовані пакети з кращим UX.
Щоб розширити функцію "чи можна замінити менеджерів плагінів",
Раніше я використовував Vundle, який був фантастичним, але тепер замінив його на 18 або більше ліній баш.
Мені здається корисним використання папок у каталозі pack для групування пов’язаних плагінів. Наприклад, "Синтаксис" або "Рубін".
Відповідний приклад башти нижче. Помістіть у файл і запустіть його.
Додаткова дискусія навколо теми: https://stories.abletech.nz/get-rid-of-your-vim-plugin-manager-7c8ff742f643#.abnjauzgk
#!/usr/bin/env bash
# This file lives in ~/.vim/pack/install.sh
# Remember to add executable: chmod +x ~/.vim/pack/install.sh
#
# Create new folder in ~/.vim/pack that contains a start folder and cd into it.
#
# Arguments:
# package_group, a string folder name to create and change into.
#
# Examples:
# set_group syntax-highlighting
#
function set_group () {
package_group=$1
path="$HOME/.vim/pack/$package_group/start"
mkdir -p "$path"
cd "$path" || exit
}
# Clone or update a git repo in the current directory.
#
# Arguments:
# repo_url, a URL to the git repo.
#
# Examples:
# package https://github.com/tpope/vim-endwise.git
#
function package () {
repo_url=$1
expected_repo=$(basename "$repo_url" .git)
if [ -d "$expected_repo" ]; then
cd "$expected_repo" || exit
result=$(git pull --force)
echo "$expected_repo: $result"
else
echo "$expected_repo: Installing..."
git clone -q "$repo_url"
fi
}
(
set_group ruby
package https://github.com/tpope/vim-rails.git &
package https://github.com/tpope/vim-rake.git &
package https://github.com/tpope/vim-bundler.git &
package https://github.com/tpope/vim-endwise.git &
wait
) &
(
set_group syntax
package https://github.com/kchmck/vim-coffee-script.git &
package https://github.com/tpope/vim-markdown.git &
package https://github.com/ap/vim-css-color.git &
wait
) &
(
set_group colorschemes
package https://github.com/altercation/vim-colors-solarized.git &
wait
) &
wait
Відповідь, надана @statox, є дуже описовою, але для нового користувача це може відволікати увагу, оскільки вони могли прочитати файл довідки безпосередньо. Я хочу окреслити, що вам потрібно зробити вказівниками.
Створіть pack/*/startкаталог під будь-яким із каталогів, передбачених set packpath. Я в ~/.config/nvim/pack/*/start. Зауважте, що ви можете використовувати будь-яке ім’я каталогу, яке ви хочете замість цього, *але ви не можете повністю його опустити, я не знаю чому. Наприклад, ви можете використовувати каталог ~/.config/nvim/pack/foo/startчи ~/.config/nvim/pack/bar/startні ~/.config/nvim/pack/start.
Перейдіть до pack/*/startкаталогу та клонуйте пакет там.
:scriptnamesщоб перевірити, чи все завантажено. Не хвилюйтеся, якщо не кожна частина завантажена, тому що деякі файли призначені для завантаження після якогось гака, наприклад autoload/plugin.vim.:helptags ALLдля створення тегів для всіх довідкових документів. Зробіть :helptags {dir}для створення тегів для довідкових документів під каталогом dir. Наприклад, якщо ви вставите свій плагін ~/.config/nvim/pack/foo/plugin_name, тоді зробіть :helptags ~/.config/nvim/pack/foo/plugin_name/doc. Це створить tagsфайл у док-каталог плагіну. Якщо ви вилучите плагін із каталогу, файл тегів буде відсутній, а vim не знайде файл довідки, тому не потрібно видаляти файл документа вручну.Новий формат можна розглядати як еквівалент Патогена, тому менеджеру, який може завантажувати потрібні плагіни, залишається місце. Є кілька нових менеджерів плагінів, які користуються цим новим форматом пакунків, але я все-таки створив Vire, оскільки вони залишають головний біль управління vimrcвами. Якщо у вас кілька машин і хочете однаковий конфігуратор по всьому, Vire робить це дуже просто.
packageфункція покликана остаточно покласти край вимболам та пов'язаним з цим динозаврам, а не конкурувати з сучасними менеджерами плагінів. Це придатна замінаpathogen, якщо ви не покладаєтесь наpathogenбільш незрозумілі функції. Він не робить жодних спроб замінити, скажімо,Vundle. Концепція пакету як колекції плагінів є продуманою та потенційно корисною, але я боюся, що ніхто не використає його, оскільки сучасні менеджери плагінів не підтримують його. І менеджери плагінів не підтримуватимуть його, тому що ніхто не використовує його. Це трохи проблема з куркою і яйцями.