Привычное разочарование новичка: скопировал кусок кода в редакторе vim, переключился в браузер, нажал вставку - а там пусто или что-то постороннее. Текст будто исчез. На самом деле он никуда не делся, просто лёг не туда, куда ожидалось. Редактор хранит скопированное в собственных ячейках памяти - регистрах, - которые по умолчанию никак не связаны с системным буфером обмена. То, что копируется внутри редактора, и то, что лежит в общем буфере операционной системы, - две разные вещи, пока их не соединить.

Чтобы копирование в редакторе попадало в системный буфер и наоборот, нужна настройка и поддержка со стороны внешнего инструмента-посредника. А в сеансах по защищённому соединению, где нет графического окружения, всё усложняется ещё сильнее - привычные посредники там не работают вовсе, и на помощь приходит совсем иной механизм. Разберём, как устроена связь с буфером обмена, какие инструменты её обеспечивают, и почему она ломается на удалённой машине.

Системный буфер живёт в особых регистрах редактора

Редактор хранит скопированное в регистрах - именованных ячейках памяти. Обычное копирование кладёт текст в безымянный регистр, никак не связанный с операционной системой. Но есть особые регистры, которые и представляют системный буфер обмена. Обращаясь к ним явно, можно копировать прямо в общий буфер и вставлять из него.

"+y     скопировать в системный буфер обмена
"+p     вставить из системного буфера обмена

Запись перед командой - это указание регистра. Знак плюса обозначает основной системный буфер, тот самый, что используется при обычном копировании и вставке между приложениями. Есть и второй особый регистр со знаком звёздочки - он соответствует так называемому первичному выделению в графических средах, куда текст попадает просто при выделении мышью.

Постоянно набирать указание регистра перед каждым копированием утомительно. Лекарство - настройка, связывающая обычное копирование напрямую с системным буфером. С ней простое копирование без указания регистра сразу кладёт текст в общий буфер.

set clipboard=unnamedplus    " обычный yank сразу в системный буфер

Эта настройка делает безымянный регистр и системный буфер одним целым. Теперь привычное копирование и вставка работают с общим буфером без всяких указаний регистра - текст, скопированный в редакторе, доступен в браузере, и наоборот. Есть и родственное значение настройки, связывающее копирование с первичным выделением вместо основного буфера, - выбор между ними зависит от привычек и среды.

Поддержка буфера должна быть вкомпилирована в редактор

Прежде чем настройка заработает, нужно убедиться, что сам редактор вообще умеет общаться с буфером обмена. Эта способность вкомпилирована не во все сборки. Проверить наличие можно, заглянув в список возможностей сборки, где поддержка буфера помечена особым флагом.

vim --version | grep clipboard
# +clipboard означает поддержку, -clipboard - её отсутствие

Плюс перед названием возможности означает, что поддержка есть, минус - что её нет. Если поддержки нет, привычное решение - установить сборку редактора с графической поддержкой, в которую эта возможность включена, даже если графический интерфейс не используется. В форке редактора есть удобная команда проверки здоровья, которая прямо сообщит, найден ли инструмент для работы с буфером, и предупредит, если регистры буфера работать не будут.

:checkhealth     форк сообщит о состоянии поддержки буфера обмена

Внешний инструмент-посредник связывает редактор с буфером системы

Сама по себе вкомпилированная поддержка - половина дела. Редактору нужен внешний инструмент-посредник, через который он кладёт текст в буфер операционной системы и забирает оттуда. Какой именно инструмент нужен, зависит от графической системы.

В классическом графическом окружении посредниками служат небольшие утилиты, умеющие писать в буфер и читать из него. Их ставят отдельно, если они ещё не установлены.

sudo apt install xclip     # один из посредников для классического окружения
sudo apt install xsel      # альтернативный посредник

Здесь притаилась важная перемена, о которой стоит знать. В современных графических средах нового поколения старые посредники перестали работать - буфер обмена там устроен иначе. На смену пришёл другой инструмент, специально написанный под новую графическую систему. Если редактор не вставляет из буфера, а среда новая, дело часто именно в этом - нужен новый посредник вместо старого.

sudo apt install wl-clipboard    # посредник для графики нового поколения

Редактор сам выбирает доступный посредник из тех, что найдёт в системе. Поэтому достаточно установить подходящий под свою среду, и связь с буфером заработает. Если ни один посредник не установлен, регистры буфера останутся пустыми, сколько ни настраивай - редактору попросту нечем дотянуться до буфера системы.

Сеанс по защищённому соединению ломает всю схему

Вот где начинается самое болезненное. На удалённой машине, куда подключаются по защищённому соединению, привычная схема разваливается. Причина проста: посредники вроде упомянутых утилит требуют графического окружения, а на сервере его обычно нет. Редактор на удалённой машине физически не может дотянуться до буфера обмена локальной машины, перед которой сидит человек, - между ними сеть и отсутствие общего графического окружения.

Попытки прокинуть графику через защищённое соединение и заставить посредник работать через неё известны, но капризны: они часто упираются в ошибки доступа к ресурсам или зависают в ожидании. Это тот случай, когда вроде бы правильная настройка не работает по причине, лежащей вне редактора, - в самой природе удалённого сеанса без графики.

Надёжное решение - совсем иной механизм, не зависящий от графического окружения вовсе. Это особая управляющая последовательность терминала, через которую редактор просит сам терминал положить текст в буфер обмена. Текст кодируется и отправляется терминалу как специальная команда, а терминал, работающий на локальной машине, кладёт его в местный буфер. Поскольку всё идёт через терминал, а не через графику удалённой машины, сеть и отсутствие графического окружения перестают быть препятствием.

Этот механизм работает, если его поддерживает терминал, и в современных терминалах поддержка обычно есть. Многие настраивают его именно ради удалённой работы: тогда копирование в редакторе на сервере прозрачно ложится в буфер локальной машины, и вставить в браузер можно как обычно. Существуют и схемы с пробросом текста обратно на локальную машину через само защищённое соединение, но управляющая последовательность терминала - самый прямой путь, не требующий дополнительных служб.

Что складывается в практику

Картина выстраивается ясно. Скопированное в редакторе по умолчанию лежит в его регистрах, отдельных от системного буфера. Связать их можно явным обращением к особому регистру со знаком плюса либо настройкой, делающей обычное копирование общим с буфером системы. Но прежде нужно убедиться, что поддержка буфера вкомпилирована в сборку, иначе ничего не выйдет.

Связь обеспечивает внешний посредник, и его выбор зависит от среды: для классического окружения - одни утилиты, для графики нового поколения - другая, потому что старые там не работают. Редактор сам подхватит установленный посредник.

А на удалённой машине вся схема ломается из-за отсутствия графического окружения, и привычные посредники бессильны. Спасает управляющая последовательность терминала, идущая в обход графики прямо через терминал на локальную машину.

Главная мысль: текст в редакторе и системный буфер - разные вещи, пока их не соединили настройкой и посредником. Пустая вставка в браузер почти всегда означает либо отсутствие поддержки в сборке, либо неустановленный или неподходящий посредник, либо удалённый сеанс без графики. Стоит проверить флаг поддержки, поставить посредник под свою среду, а для удалённой работы освоить механизм терминала, и копирование между редактором и остальной системой перестаёт теряться по дороге.