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 ввів два рядки в helptag
doc :
: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
. Концепція пакету як колекції плагінів є продуманою та потенційно корисною, але я боюся, що ніхто не використає його, оскільки сучасні менеджери плагінів не підтримують його. І менеджери плагінів не підтримуватимуть його, тому що ніхто не використовує його. Це трохи проблема з куркою і яйцями.