Чому експерти Vim віддають перевагу буферам над вкладками?

Я не розумію буферів. Коли я відкриваю 3 файли на одній вкладці і закриваю своє вікно, я, як правило, роздратований, щоб дізнатися наступного разу, коли відкрию один із тих файлів, що існують дивні файли обміну, які затримуються, і дають мені сумні повідомлення. Але я знову і знову читаю, що ці речі - це продуктивність нірвани, яку я не вистачаю, і що плебеї використовували вкладки.

Тому я запитую вас, експерт Vim: які переваги використання буферів над вкладками? Я не бачу, як різниця може бути глибоко різною, але я вважав би себе лише на початково-проміжному рівні в операційній Vim. Є чи на :ls :b#самому ділі набагато швидше , ніж gtІНГ навколо? Я відчуваю, що він повинен заглибитись, ніж це.

Як ZyX сказав на #vim, це питання звучить як "Чому фахівці Vim воліють смачніше, ніж тепле?" .

"Vim експерти" не віддають перевагу буферам над вкладками: вони використовують буфери як проксі-файли, на яких вони є, а сторінки вкладки як робочі простори. Буфери та сторінки вкладок мають різні цілі, тому віддавати перевагу одній іншій немає сенсу.

Проблема з буферами та вкладками викликає сумбур , викликаний поєднанням незалежних фактів.

1. Більшість "сучасних" текстових редакторів та IDE використовують метафору вкладки для представлення завантажених файлів. Ця метафора виступає як інформаційна система - вона показує користувачеві, які файли відкриваються та їх стан - і як інтерактивний пристрій - дозволяє користувачеві маніпулювати (упорядкувати, виділити, закрити ...) відкриті файли. Незважаючи на численні обмеження, вкладки є скрізь, і люди звикли до них і очікують їх скрізь.

2. Vim представив сторінки вкладок у 7.0 як спосіб для своїх користувачів створювати спеціальні "робочі простори". Ніщо в їхніх функціях, їх конкретних параметрах, конкретних командах або їх :helpрозділах не говорить про те, що сторінки вкладок можуть або повинні використовуватися як проксі-файли.

   Ніщо, крім назви та появи "сторінок вкладок", звичайно, що призводить до великої плутанини.

3. Без :set hiddenцього вимкнути за замовчуванням і не дуже легко знайти, Vim унеможливлює перехід на інший буфер, не записуючи поточний або не відмовляючись від його змін. Нові користувачі, не знаючи про цю опцію, не мають іншого вибору, крім того, щоб звернутися до використання важких вікон або до найближчої "вкладки" функції, яку вони можуть знайти: сторінки вкладок.

"Сторінка вкладки" - це невдалий вибір імені для цієї функції, особливо в епоху, де панує думка, що читання документації - це марна трата часу.

У Vim сторінки вкладок - це абстракція, побудована над вікнами, сама абстракція, побудована поверх буферів. Кожен новий рівень додає корисні функції, але обмежує ваш робочий процес.

"Буферний шлях"

З робочим процесом на основі буфера файли, з якими ви працюєте, розподіляються по одному виміру. Ви можете переходити через свої буфери, ви можете отримати доступ до певного буфера, ввівши частину його імені (із завершенням) або його номер, ви можете чергувати між буферами, ви можете легко націлити їх на них. В основному тертя немає.

1. Відкрито вісім буферів, видно лише один:

   

2. Перемикання за номером:

   

3. Перемикання по імені:

   

Буфери - це довірені файли Віма. Якщо ви думаєте з точки зору файлів, ви думаєте з точки зору буферів.

"Віконний шлях"

З робочим процесом на основі вікна ваші "файли" розподіляються вздовж одного і того ж "віртуального" виміру, як це було б, якби ви використовували лише буфери та уздовж двох інших "фізичних" розмірів. Але декартові простори, в яких знайдені ці розміри, майже повністю розділені: перехід до іншого буфера все ще означає "перехід до іншого файлу", а перехід до іншого вікна не означає. Буфер, який відповідає бажаному файлу, може відображатися у цьому вікні, але він також може бути відображений в іншому, можливо, на іншій сторінці вкладки, або зовсім не бути.

З вікнами навігація між відкритими файлами стає занадто складною або занадто спрощеною, навіть із 'switchbuf'та :sb. Переважно тому, що ви змушені використовувати два набори команд для того, що по суті одне і те ж: доступ до буфера.

У Windows використовується їх використання, як описано нижче, але вони не мають необхідного для заміни буферів у чиємусь робочому процесі.

Тут я працюю над кольоровою схемою Vim. Два вікна - це різні погляди одного і того ж буфера: верхнє служить орієнтиром із таблицею кольорових кодів, що використовуються у схемі кольорів, а нижнє - там, де я працюю:

Windows не розроблені як проксі-файли і не можуть бути перетворені в такі: вони є "контейнерами" або "вікнами перегляду", призначеними запропонувати вам переглянути в буфер. Ні більше, ні менше.

"Шлях вкладки"

За допомогою робочого процесу, заснованого на вкладках, ви по суті намагаєтесь імітувати користувацький досвід, до якого ви звикли з попереднього редактора, повністю ігноруючи саму природу сторінок вкладок Vim. Якщо ми на мить забудемо, що ця стратегія, як правило, дуже непродуктивна, також неможливо, як і у Windows, змусити Vim дотримуватися тієї парадигми "один файл = одна вкладка", не втрачаючи великої гнучкості.

Ще працюючи з тими ж файлами, що і вище, таблична лінія займає значне місце практично без користі. Всі мої файли та всі мої вкладки називаються, javascript*.vimтому я не можу робити 3gtі буду впевнений, що я опишусь у потрібному місці, і неможливо дістатись певної вкладки по імені. Додайте до цього той факт, що його мітка може бути дуже корисною, але цілком логічною [Quickfix List]... Оскільки немає практичного способу прив’язати файл / буфер до сторінки вкладки, вам в основному залишається лише один практичний спосіб переходу між сторінками вкладок / буфери / файли: їзда на велосипеді.

І так, мій таблайн укладений лише з 8 вкладок, уявіть, якби у мене було 20!

1. Вісім буферів відкриті на восьми сторінках вкладок (неправильно)

   

2. Дві вкладки для двох конкретних завдань (праворуч)

   

Сторінки вкладок - це "контейнери" або "вікна перегляду", розроблені, щоб містити одне або більше вікон, самі ж "контейнери", призначені для розміщення буферів.

На закінчення

"Експерти Vim" (припустимо, я можу говорити так, ніби я був) не віддають перевагу буферам над вкладками: вони просто використовують Vim так, як він був розроблений, і цілком зручні з цим дизайном:

• "Експерти Vim" завантажують 2, 30 або 97 буферів і дуже раді, що їм не доведеться мати справу з просторовим розподілом;

• коли їм потрібно порівняти два файли або працювати в одній частині поточного буфера, зберігаючи інший як орієнтир, "Vim експерти" використовують вікна, тому що саме так вони призначені для використання;

• коли їм потрібно деякий час працювати над окремою частиною проекту, не псуючи їх сучасний погляд, "Vim експерти" завантажують абсолютно нову сторінку вкладки.

Раніше я тримав кожен буфер на окремій вкладці, але мені постійно набридло постійно gtі gTнавколо.

Я також відчував, що буферами занадто важко керувати.

Ось деякі методи, які повністю змінили мою попередню думку:

• Управління Buffer: :b. Ви отримуєте напрочуд швидкий результат. Дивіться vim, швидко перемикаючись між файлами за допомогою ванільного Vim (без плагінів)
• Перейти / зміни списків ( ctrl o/ iі g;)
• Альтернативний файл ( ^)
• tpope «s Неушкоджена плагін . Зручні карти для польоту через ваші буфери (серед інших).

Ось мій типовий робочий процес:

• Відкрийте Vim та використовуйте :e(як правило, з регулярним виразом :e src/**/F*Bar.js), щоб відкрити буфер
• Зрозумійте, мені потрібно відкрити ще один файл. Використовуйте і :eдля цього. Якщо я хочу переключитися між цим буфером і поточно відкритим буфером, я використовуватиму :spабо :vspвідкривати його в окремому вікні.
• Повторюйте, доки я не отримаю 3-5 файлів, які я переключатимусь за допомогою методів у наведеному вище списку, щоб переходити між вашими буферами.
• Якщо я хочу "почати спочатку" зі своїми буферами, просто закрийте Vim та знову відкрийте.

Я відчував, що через тиждень або близько того, як форсувати ці нові шаблони, стало набагато простіше уявити, які буфери я відкрив, і як дістатися до будь-якого з них лише декількома автоматичними обведеннями.

Недоліком вкладок є те, що ви можете бачити вміст лише одного. Тож якщо ви користуєтесь ними, як у веб-переглядачі, ви втрачаєте перегляд декількох буферів поруч або навіть перегляд окремих частин одного файлу в розбиттях. Тому багато хто рекомендує використовувати вкладки лише для відокремлення різних робочих просторів (наприклад, один для проекту Java, інший для списку todo, третій для злому сценарію збоку).

Описані вами проблеми показують, що ви неправильно використовуєте Vim. Будь-яка мати (в основному) один, виділений екземпляр. Тоді буфери, які стануть прихованими, просто “з’являться”, якщо ви їх повторно відредагуєте (і тепер ви можете використовувати список буферів, щоб відкликати їх), і не буде файлів підкачки файлів. Або використовуйте окремі екземпляри Vim на сеанс проекту / файлу / редагування, але тоді створіть звичку повністю використовувати :quitкожен екземпляр, коли закінчите з файлом.

Ще одна порада, коли ви використовуєте ім'я буфера як аргумент: буфер, вам не потрібно вказувати цілі імена. Однак якщо заданому аргументу відповідає більше одного буфера, буфери не будуть перемикатися.

Будь-який фрагмент імені буфера може використовуватися для узгодження. Наприклад, якщо у вас є буфери, request_manager.javaа queue_manager.javaпотім, :buffer queабо вони :b queвідповідають обом, але вони перейдуть на queue_manager.java, як це відповідає на початку.

Я використовую вкладки, Ctrl- Pта Vim сесії у своєму робочому процесі, і вже більше року:

• У мене є )і (відображено відповідно "перехід до наступної вкладки" та "перехід до попередньої вкладки". tnвідкриває нову вкладку. Я також використовую tabm, щоб допомогти організувати речі.

• Я використовую Vim-сеанси для груп файлів, що стосуються поточної історії / помилки, над якою я працюю, зазвичай це робиться за категоріями. Ці сеанси перезаписуються в ході процесу.

• Я ще не міг знайти нічого кращого ніж Ctrl- P, але для обробки всіх файлів для пошуку знадобиться трохи.

Кидає 2с в купу.

TLDR; :b *part-of-filename*це найкращий спосіб знайти потрібний вам файл у списку буферів, тобто він Швидше і має менший когнітивний навантаження, ніж номери буферів, вкладки чи вікна для відстеження файлів.

Для мене немає нічого, щоб було відкрито 30 буферів (тобто я не займався веденням господарства), і краса буферів, що використовуються, - це те, що мене це зовсім не сповільнює. Насправді це прискорює справи, коли через чотири дні після відкриття файлу мені потрібен, зателефонуйте, :b *part-of-filename*і він магічно з’являється, вражаючи одночасно колег та завзятих колективістів.

Буфери призначені для файлів.

Для ефективності:

• Відкрийте важливий перший файл із чортово добре вибраного кореневого каталогу
• Відкрийте наступні файли за допомогою :e
• Використовуйте lsВСІ часи, коли ви вперше починаєте отримувати хорошу розумову модель (ви не можете рисувати те, чого не можете бачити, ні розумово, ні буквально)
• Ніколи :q, це дме
• Увійдіть :bу свою м’язову пам’ять
• :b1 добре для першого файлу, який ви знаєте, що ви відкрили, інакше цифри та букви швидко незграбні
• :b# добре для переходу на ваш останній файл, що є загальною потребою
• :bd#добре, коли ви перейшли на тимчасовий файл, зробили те, що вам потрібно було зробити, повернулися назад :b#і тепер хочете закрити цей темп-файл.
• :b *part-of-filename* в іншому випадку найкращий спосіб знайти потрібний вам файл у списку, тобто він Швидше і має менший когнітивний навантаження, ніж буферні номери, вкладки чи вікна для відстеження файлів.

Єдине роздратування в :b *part-of-filename*тому, що іноді ви ще не відкрили файл, і вам потрібно повернутися назад і :e path/to/full-filenameспочатку.

Вкладки призначені для розмежування справді непов'язаних файлів.

Або зберігати певний макет вікна під рукою (відмова від відповідальності: я сам ніколи для цього не користувався).

Або для файлів, які рідко використовуються, але передбачувано потрібні. Для мене, як правило, це commitMessageфайл, який я коментую під час роботи, тому мені не потрібно занадто багато думати, коли настає час взяти на себе зобов’язання. gtшвидше, ніж :b com<enter>(якщо вам пощастило, інакше :b com<tab><enter>)

• :tabe commitMessage
• gtабо gTтакож улюбленець м’язової пам’яті

Вікна розбиття призначені для візуального порівняння інформації

Або маючи негайний доступ до важливої ​​інформації (правдиво, якщо тільки ця інформація якимось чином не потрібна для оновлення, :eтобто файлу журналу, я зазвичай просто перетягую вміст у поточний файл і займаюся ним).

• :vspабо C-w vвідкриває вертикальний розкол, тобто зліва | правильно, а потім скористайтеся :bабо, :eщоб отримати потрібний файл
• :spабо C-w sвідкрити горизонтальний розріз, тобто верх / низ
• C-w C-w тобто подвійний Ctrl-w, обертає вас навколо наявних вікон
• C-w c закрити поточне вікно
• C-w o закрийте всі інші вікна, тримайте ТОЛЬКІ поточні

Додайте їх до своїх .vimrcі починайте любити буфери:

:nnoremap <Tab> :n<cr>
:nnoremap <S-Tab> :N<cr>

Таким чином ви можете проїхатись вперед / назад по них у звичайному режимі через Tab/ ShiftTab.

Я хотів би запропонувати блискучу реалізацію від хорошої кількості років тому: kien / tabman.vim . Він уточнює наступне:

• Можна мати стільки буферів, які ретельно ховаються десь;
• За задумом вкладки призначені для відображення помилок у творчих формах.
  • З допомогою належного плагіна табло, можна відобразити всі приховані буфери у верхньому рядку (табло);
  • Згідно з моїм досвідом роботи з vim-airline , під час створення нової вкладки на вкладці буде показано дуже мало відповідної інформації.
  • Два теги будуть займати слот табло, поруч, витрачаючи решту горизонтальних пробілів
  • Найгірше, що я більше не маю уявлення про те, які буфери приховані.

Це чудове повторне відкриття цього чарівного плагіна, який повинен був залишатися у моїй конфігурації Vim ще довгу кількість років. Хоча я б продовжував шукати якусь річ, яка також відображає всі приховані буфери, TabMan є моїм суперменом, коли справа стосується того, як буфери розташовуються на різних вкладках.

Вкладки та буфери - це два різні стандарти у Vi. Прочитайте ці три визначення:

A buffer is the in-memory text of a file
A window is a viewport on a buffer.
A tab page is a collection of windows.

Читайте цю статтю для більше https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/

Я завантажую "вибрані" буфери як вкладки, щоб швидко (TAB / S-TAB) перемикатися між ними. Рамка робочих просторів підходить тут, оскільки для мене буфери VS-вкладки - це головним чином предмет видимості. Я можу розміщувати важливі / робочі файли у вікнах та вкладках і ховати ті, які мені зараз не потрібно використовувати у фоновому режимі на льоту, не запам’ятовуючи шляхи або займати час для пошуку та завантаження їх знову, коли виникає потреба. Це дозволяє обробляти кілька завдань або проектів за один сеанс VIM, я думаю, що це було важливо в машинах з низькою пам'яттю, але також добре для концентрації всіх завдань редагування в одному кадрі програми. У мене також є ярлики перемикання буфера, встановлені на Ctrl-Right / Left, щоб я також міг швидко переходити через різні буфери.

Підсумок: можна використовувати лише деякі вікна для його використання стільки, скільки йде екран власності, але можна утримувати кілька налаштувань вікна на декількох вкладках, таким чином розширюючи робочу область і покращуючи робочий процес, що дозволяє зручно ділити складні завдання, що обертаються більше ніж один файл .

Для файлів підкачки можна сказати VIM зберігати їх у одній папці вашого призначення. Для цього використовують :set directory.