Буфер обмена и другие нестандартные данные в удаленных терминалах

XXI век.
удаленном редактировании файлов

В 21 веке БГ дал тебе sshfs, что-то-ещё-на-выбор-fs, git, tramp. Удалённое редактирование костыльная идея. Годится, поменять пару байтиков в nano. Но не более.

Для всего остального слава аллаху, читай по слогам: не-ну-жно. Как и micro, впрочем.

эти долгожданые возможности толком не работают при удаленном редактировании файлов.
то с буфером обмена полный облом. Он просто не может работать.

А почему нельзя пробросить для общения с буфером обмена X-сервер при помощи ssh -X?

Из-за этих (и других) проблем до сих пор в *NIX не существует человеческого текстового редактора для терминала.

Это ещё фигня, во всяких nano через Ctrl+K / Ctrl+U хоть как-то можно построчно копипастить, всё равно бо́льшие портянки удобнее набирать в локальном редакторе. Гораздо хуже что до сих пор нет вменяемого способа скопировать из консоли табы так чтобы они не заменились пробелами. XXI век на дворе, самая продвинутая консоль из всех, опенсорц, свобода, все дела.

Хотя с копированием вылезающих за пределы экрана строчек тоже ещё тот цирк, да.

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

специальный терминал, который будет понимать самодельный расширенный протокол

Запили патчем в urxvt, и если будт годно, то народ подтянется.

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

Поздравляю. Ты изобрёл X11.

Гораздо хуже что до сих пор нет вменяемого способа скопировать из консоли табы так чтобы они не заменились пробелами.

4.2.

Из urxvt таб копируется табом, а не пробелами.

Нет, правда, поясните мне. Если

происходит копирование в/из буфера обмена средствами редактора (через xclip/xsel) а не терминала

всё работает через xclip/xsel, то достаточно добавить к ssh флаг -X (ну, может, ещё -Y), и на удалённом хосте будет выставлена настоящая переменная DISPLAY, указывающая на проброшенный локальный X-сервер с локальным же буфером обмена. И всё должно работать безо всяких руками сделанных костылей из (3).

Разве нет?

Ну и проблемы у вас. На что только люди не идут, лишь бы не изучить vim.

Разумно.

всё работает через xclip/xsel, то достаточно добавить к ssh флаг -X (ну, может, ещё -Y), и на удалённом хосте будет выставлена настоящая переменная DISPLAY, указывающая на проброшенный локальный X-сервер с локальным же буфером обмена. Разве нет?

Проверь.

Но в любом случае поднимать для редактирования текста еще и X-сервер на удаленном сервачке - это несколько перебор.

Но в любом случае поднимать для редактирования текста еще и X-сервер на удаленном сервачке - это несколько перебор.

Почему на удалённом-то? ssh прокидывает туннель до твоего локального X. Приложение на удалённой машине делает XOpenDisplay() и подключается к твоим иксам.

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

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

X-сервер на удаленном сервачке

Вы не поняли. ssh -X пробрасывает *локальный* X-сервер так, чтобы на удалённой машине программы могли просто пользоваться $DISPLAY, как обычно. Для этого ssh сам делает туннель сродни Вашему (3), но для всех X-команд. На удалённой машине X-сервер при этом не запускается, достаточно иметь xclip и xsel, или через что там micro общается с буфером обмена.

Проблема в том, что xclip и xsel не установишь без иксов по зависимостям. А если и установишь, то фиг его знает, будут они работать или нет, может им какие X-либы нужны. Придется все руками выгребать.

Так.

Во-первых выбрось свой micro и другие подобные поделки.

Есть терминал, есть GUI. Они разные. Так случилось исторически, и привести это под единый концепт, как ты правильно сказал, не представляется возможным.

Так вот; если ты собрался работать в терминале, будь добр, изучи терминал. Это касается в том числе редактора; это должен быть vim. Не хочу разводить холивор с любителями emacs, суть вопроса не в том, что круче, а в том, что есть везде; везде есть vi или vim. Даже на рутере, если там есть редактор, это будет vi/vim. Если у тебя цель сократить количество изучаемых сущностей, то учи vim.

Далее. Судя по твоему посту, те от редактора основное что нужно, это copy/paste. Сможешь запомнить пару комбинаций?
i - insert mode
Esc - выход из insert mode
v - начать выделение
y - copy
p - paste
:w - срхранить
:q - выйти
:q! - выйти без сохранения
Да, для тех, кто не в теме, выглядит по-марсиански, но для задачи «подредактировать конфиг» хватает. Поменять это на что-то другое - к сожалению (или к счастью) понадобтся еще больше усилий. Я так пользовался vim'ом лет 7. Жив остался. Потом решил изучить vim поплотнее - понял что это удобней, чем Ctrl+С/Ctrl+V; внезапно, да?

Буфер обмена - здесь сложность только при передаче через SSH; для этого кейса плюсую сторонников sshfs/scp - для «больших кусков текста, которые не влезают на экран», наверное, оно. В остальном - у vim есть свой очччень неплохой буфер обмена (на голову круче остальных), tmux (screen, наверное, тоже) имеет свой, есть иксовый, есть DE'шный. Насчитали четыре, да. Если очень нужно их засинхронизить, nо нужно просто немного поработать напильником. Лично мне этого никогда не нужно было, ибо для текстов более одного экрана - scp, для менее одного экрана - выделяешь мышкой <увернулся от гнилого помидора>, работает даже в PuTTY).

Итог:
- да, придется изучить две сущности: GUI'шный Ctrl+C/Ctrl+V и терминал/vim (базовые команды, что я указал выше). Если не будешь лезть во всякие nano/micro/pico, то ограничишься только двумя сущностями, а не десятью.
- нормального способа передавать буфер обмена через SSH еще не придумали. Нормальный - я имею ввиду чтобы работал как в иксах, так и без них, и не требовал кастомных патчей типа такого.
- Если нужно «копировать текст, который вылезает за экран» - tmux. Да и вообще: tmux.

Какие еще остались нерешенные вопросы?

не установишь без иксов по зависимостям

Естественно, xclip и xsel зависят от иксовых библиотек (делать X-вызовы руками через сокет - то ещё развлечение). Как минимум, в Debian, xclip и xsel не зависят от X-сервера, так что удалённой машине без иксов придётся вытерпеть пакеты libx11-6, libxmu6, libxcb1, libx11-data, libxext6, libxt6, libxau6, libxdmcp6, libice6, libsm6, libuuid1, x11-common. APT прекрасно справляется с их установкой, не подтягивая X-сервер, если попросить его дать только эти 2 пакета.

В принципе, можно было бы написать свои xsel и xclip, которые бы имитировали параметры и поведение оригинальных файлов, но передавали бы команды буфера обмена по собственному протоколу поверх собственного ssh-туннеля, не требуя X-зависимостей, и подсовывать их редактору micro. С моей точки зрения, пачка библиотек - вполне оправданная цена того, чтобы не писать свои костыли подобной сложности.

v - начать выделение
y - copy
p - paste
:w - срхранить
:q - выйти
:q! - выйти без сохранения

К сожалению, я не могу эффективно работать в программах, в которых одно и то же действие нужно выполнять разными сочетаниями. Я имею в виду vi и все остальные DE программы. Если vi такой особенный, что для традиционных действий нужно нажимать нетрадиционные кнопки, то при всех своих достоинствах он нахрен не нужен.

Тут просто моторика. Тебе дают автомобиль и говорят: чувак, а вот в этом автомобиле тормоз находится на потолке возле зеркальца. Ты не забывай об этом. Ну и плевать, что тебе нужно в день на сотне автомобилях поездить. Главное помни, что в нашем автомобиле тормоз на потолке.

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

И последнее. Я очень внимательно отношусь к эргономике. настолько внимательно, что даже запилил свой переключатель клавиатуры. Поэтому уродец vi не для меня.

Если нужно «копировать текст, который вылезает за экран» - tmux. Да и вообще: tmux.

Ты вообще не шаришь. При чем тут редактирование текстов и tmux, которым я постоянно пользуюсь, не пойму.

Да, забыл сказать, что я и консоль настраиваю так, что в ней для копипаста работают стандартные Ctrl+C/Ctrl+V.

Как «освободить» клавиши Ctrl+C, Ctrl+V, Ctrl+X в терминале

Это офигеть как удобно. Прикинь, я везде нажимаю Ctrl+C, и у меня текст копируется в буфер обмена. Даже в консоли. Я нажимаю Ctrl+V, и текст вставляется. Прикинь, вставляется даже в консоли! Я не мучаю себя сочетаниями ПCtrl+Ins/ПCtrl+Delete специально для консоли. Я просто нажимаю то, к чему привык, и оно работает.

Вы не поняли. ssh -X пробрасывает *локальный* X-сервер так, чтобы на удалённой машине программы могли просто пользоваться $DISPLAY, как обычно. Для этого ssh сам делает туннель сродни Вашему (3), но для всех X-команд. На удалённой машине X-сервер при этом не запускается, достаточно иметь xclip и xsel, или через что там micro общается с буфером обмена.

Проверил. Реально, оно работает.

Вот только есть маленькая проблема: работает медленно. Очень медленно. Пока не понял почему. Начинаешь выделять строку, и строка выделяется спустя три секунды. Выделяешь следующую - тоже столько же ждешь. Не знаю из-за чего. Толи micro пихает в буфер сразу после выделения, не дожидаясь Ctrl+C, толи иксовые данные забивают канал. Надо дальше разбираться.

сударь, вам бы английский подтянуть

Да, забыл сказать, что я и консоль настраиваю так, что в ней для копипаста работают стандартные Ctrl+C/Ctrl+V.

Поздравляю. Теперь ты можешь работать только на своем домашнем Линуксе. Если ты придешь к товарищу, который только-только накатил Убунточку и просит тебя, как опытного комрада, помочь с какой-то мелочью, что вынужден будешь ретироваться. Если тебя на работе попросят что-то делать, ты вынужден будешь ответить «да, я знаю Линукс, но только свой, настроенный Линукс; можно я вам принесу свою тонну конфигов?». Если ты зайдешь на рутер по ssh, тебе будет жутко неудобно работать. И не потому, что там нет твоих конфигов; точнее не только поэтому; а потому, что ты забыл как это делается в 99.999% систем.

Да, это та дилемма, которую я в свое время решал. И понял, что кардинально ничего менять нельзя. Ctrl+C - это кардинально, так как Ctrl+C - это на рефлексе «прервать программу». Кстати, куда ты переброcил то, что было на Ctrl+C?

Теперь ближе к практике.

Если тебя устраивают твои кастомные настройки, то заточить vim на Ctrl+C/Ctrl+V - дело нескольких биндингов. Еще одна строка конфига - копировать с «общесистемный буфер обмена»; кстати, ты не расскажешь мне что это такое? Так как когда ты работаешь в GUI в Линуксе, у тебя минимум 2 буфера обмена: иксовый и DE'шный. Я уже про это рассказывал. И еще: надеюсь, ты работаешь в GVim, так как иначе тебе придется рассказать, каким образом Ctrl+C будет пропускать терминал и обрабатывать vim.

И сразу забудь про работу по удаленке. При всех своих «марсианских» key-binding'ах, vim достаточно удобен, если немного попытаться его поучить. Например, недавно я заходил на свой терминал со смартфона, и там нужно было подредактировать файлик. Догадайся, где на экранной клавиатуре клавиша Ctrl?

Как там, при редактировании по SSH, vi может запихнуть в буфер обмена выделенный текст?

Это не vim не умеет. Это ssh не умеет. Если б это можно было сделать по ssh, то и vim это умел бы.
Покажи мне хоть что-то что умеет обмениваться буфером обмена по ssh (я имею ввиду без иксов; или тебе ssh -X подходит?).

Ты вообще не шаришь. При чем тут редактирование текстов и tmux, которым я постоянно пользуюсь, не пойму.

Я думал ты решаешь более общую задачу. Например, скопировать вывод ls, который улез за экран. Если ты до этого вопроса еще не дошел - проехали.

Тебе дают автомобиль и говорят: чувак, а вот в этом автомобиле тормоз находится на потолке возле зеркальца. Ты не забывай об этом.

Немного не так. У тебя есть велосипед, тебе дают автомобиль, и ты кричишь, что хочешь в атомобиле крутить педали, потому, что «тут просто моторика» и «это офигеть как удобно» (С).

Что, на гитхабе смотрели?

К сожалению, у меня нет способности к языкам. Я даже обучился и получил сертификат Elementary, но понимаю что у меня и бегиннера нету. Спасает только большой словарный запас на over 5000 слов, который наработался из-за постоянного чтения технической литературы. Но грамматику и структуру предложения постигнуть не могу начиная с артикля The - никто не может объяснить когда его блин применять а когда нет. Блин, да я пошел на кусы только для того чтоб мне объяснили когда и как употребляются артикли. Если бы я это понял, я бы себе галку поставил как достижение важной цели. Но нет, понимания не пришло.

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

Так как когда ты работаешь в GUI в Линуксе, у тебя минимум 2 буфера обмена: иксовый и DE'шный.

Что за чушь я только прочитал?

Толи micro пихает в буфер сразу после выделения, не дожидаясь Ctrl+C

Это наиболее вероятно. Глянь в сорцы.

Проблема в том, что xclip и xsel не установишь без иксов по зависимостям. А если и установишь, то фиг его знает, будут они работать или нет, может им какие X-либы нужны. Придется все руками выгребать.

Сударь, вы вроде разумный человек, но вам не хватает матчасти. Иксы не даром имеют сетевой протокол. Это означает, что реализация дисплея и клиентской части библиотек не зависят друг от друга. Между ними - прослойка в виде сокета. Сокет может быть локальным или TCP — для иксов это монопенисуально. Поэтому вы можете на удалённой машине запустить хоть KDE — иксы туда ставить не придётся, только приложения.

Что за чушь я только прочитал?

9. X11 selection mechanism				*x11-selection*

If using X11, in either the GUI or an xterm with an X11-aware Vim, then Vim
provides varied access to the X11 selection and clipboard.  These are accessed
by using the two selection registers «* and »+.

X11 provides two basic types of global store, selections and cut-buffers,
which differ in one important aspect: selections are «owned» by an
application, and disappear when that application (e.g., Vim) exits, thus
losing the data, whereas cut-buffers, are stored within the X-server itself
and remain until written over or the X-server exits (e.g., upon logging out).

The contents of selections are held by the originating application (e.g., upon
a copy), and only passed on to another application when that other application
asks for them (e.g., upon a paste).

The contents of cut-buffers are immediately written to, and are then
accessible directly from the X-server, without contacting the originating
application.

Кстати, куда ты переброcил то, что было на Ctrl+C?

Ctrl+Q, естественно. Если бы терминал мог работать со всеми клавишами, перебросил бы на Ctrl+Break, как и было задуманно проектировщиками клавиатуры.

Догадайся, где на экранной клавиатуре клавиша Ctrl?

То есть, где клавиша Esc у тебя вопросов не вызывает? Ты в vim без нее работаешь.

А вообще, у меня Ctrl там же, где она и должен быть. Ставишь Hacker Keyboard и у тебя есть все клавиши.

Я думал ты решаешь более общую задачу. Например, скопировать вывод ls, который улез за экран. Если ты до этого вопроса еще не дошел - проехали.

А что, есть какие-то проблемы с этим?

Немного не так. У тебя есть велосипед, тебе дают автомобиль, и ты кричишь, что хочешь в атомобиле крутить педали.

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

Да, и еще. Всю систему не перекроишь под твой любимый vi, хотя фанаты пилят биндинги для основных DE и браузеров. Но это какое-то извращение: для всех программ биндинги не сделать, да и сама постановка задачи безумна. Имея одну программу-редактор, подгонять под нее всю систему, вместо того чтобы подогнать один редактор под систему - это явный бред.

Толи micro пихает в буфер сразу после выделения, не дожидаясь Ctrl+C

Это наиболее вероятно. Глянь в сорцы.

Я потестировал, и вижу что сразу после выделения (без нажатия Ctrl+C) буфер не меняется. Так что проблема, видимо, в другом.

cut-buffers вымерли давным давно.

selections стандартизированы в ICCCM. Их три: PRIMARY, SECONDARY, и CLIPBOARD, но SECONDARY на практике не используется. Остальные два — повсеместно.

Поэтому вопрос о чуши всё еще актуален.

Может он в PRIMARY-буфер пытается писать? Это тот, который обычно по средней кнопке.

Ctrl+Q

А Ctrl+S ты предусмотрительно тоже разбиндил?

Потому что по дефолту Ctrl+S — заморозить вывод, Ctrl+Q — разморозить вывод.

Поэтому вы можете на удалённой машине запустить хоть KDE — иксы туда ставить не придётся, только приложения.

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

моно-

экви-

Ага.

В терминах иксов, дисплей-сервер — это твой экран. А приложение — это клиент. Потому что именно приложение открывает соединение к дисплею, а не наоборот.

Получается: X-клиент запущен на удаленном сервере, а на локальной (клиентской) машине запущен X-сервер.

Это ломает мозг первое время после этого «открытия», но потом привыкаешь к такой терминологии. %-)

удаленные приложения сами волшебным образом к нему цепляются, работают удаленно, и отправляют ему данные

Нет, не волшебным образом. Приложение берёт адрес коннекта из переменной окружения DISPLAY. Обычно там ":0.0" — адрес твоего локального дисплея.

Если ты используешь ssh -X, то она создаёт туннель и слушает локальный сокет на «той стороне». Переменную DISPLAY выставляет соответствующим образом.

Приложение подключается к этому сокету, а ssh-туннель обеспечивает обмен пакетами с твоим локальным дисплеем.

Логично.

Сделай уже себе свою ОС со своим редактором, ну чего ты мучаешься.

Так уж сложилось, что Линукс — сборная солянка всего. Вся суть — в вариациях, однородности тут никогда не было и не будет. Какую бы классно выглядящую и классно работающую однородную систему не сделали, линуксоиды отколупают от неё понравившиеся куски и вкорячат в своих и так уже монстров.

Ты либо принимаешь это как есть, либо всё время страдаешь.

Может он в PRIMARY-буфер пытается писать? Это тот, который обычно по средней кнопке.

Ага, так и есть. А при нажатии Ctrl+C в micro этот буфер пробрасывается в обычный буфер обмена.

Поэтому выделение мышкой еще более тормозное чем клавишами: при каждом движении мышкой меняется primary буфер.

Потому что по дефолту Ctrl+S — заморозить вывод, Ctrl+Q — разморозить вывод.

И как часто ты эти пользуешься?

Никогда. :-D

Но иногда случайно нажимаю Ctrl+S в терминале, и в этом случае нужен хоткей, чтобы снять разморозку.

> Кстати, куда ты переброcил то, что было на Ctrl+C?
Ctrl+Q, естественно.

Извини, но куда ты забиндил Ctrl+Q? Или ты не используешь Сtrl-S?
Хотя, если у тебя tmux, то, может не используешь. Оно только в голой консоли нужно...

То есть, где клавиша Esc у тебя вопросов не вызывает? Ты в vim без нее работаешь

Можно без неё.

А что, есть какие-то проблемы с этим?

А как ты копируешь текст из терминала, если это текст - больше размеров терминала?

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

Велосипед - Виндовый/GUI'шный подход в редакторах текста (Ctrl+C, Ctrl+V), да и вообще в работе.
Автомобиль - консольный.

И моя аналогия достаточно точна:
- И автомобиль, и велосипед предназначены для одной цели: передвигаться.
- Иногда они взаимозаменяемы: проехать пару километров по городу можно и на велосипеде, и на машине (аналогия - мелкая правка текстов). Иногда - нет: на велосипеде не перевезешь грузы (регулярки и макросы как правило недоразвиты или неудобны в GUI); на автомобиле не проедешь по лесу (консольный подход не очень хорош там, где есть графика, e. g. браузеры, граф. редакторы). Вцелом, автомобиль предоставляет больше возможностей.
- Автомобиль более сложен: там больше всяких ручек управления, больше параметров, которые нужно контролировать.
- Самое главное: мы все начинаем с велосипеда, но потом приходится переучиваться на автомобиль; и это требует времени и усилий по смене привычек.
- Принципе, некоторые люди живут без автомобиля. Другие живут без велосипеда. Но, по-хорошему, пользоваться нужно уметь обоими.
- Как правило люди, освоившие автомобиль, неохотно пересаживаются на велосипед, так как автомобиль в результате удобней.

Всю систему не перекроишь под твой любимый vi

Да и не нужно.
Еще раз: есть две парадигмы работы: GUI'шная и консольная. Мой key messages как раз и состоит в том, что, выучи обе. Их всего две. Это легче, и на порядок универсальней, чем перекраивать терминал под GUI (то, что ты пытаешься сделать), или GUI под терминал («vi, хотя фанаты пилят биндинги для основных DE» (C) ).

Сделай уже себе свою ОС со своим редактором, ну чего ты мучаешься.

Было бы у меня две жизни, наверное сделал бы. Но смысла в этом нет: достаточно сделать редактор и, может быть, терминал. К сожалению, в этой жизни у меня времени даже на такие задачи нет.

Кстати, зачем нужен LoLo Switcher? Чем обычное переключение раскладки не устроило?

Никогда. :-D

Так чего же тебя ребиндинг Ctrl+Q беспокоит??? :)

Но иногда случайно нажимаю Ctrl+S в терминале, и в этом случае нужен хоткей, чтобы снять разморозку.

А может быть, лучше разбиндить Ctrl+S, чтоб не мучиться?


Кстати, ты сейчас обозначил проблему, которую упорно не хочет замечать Kroz. Человеку трудно постоянно переключаться между разными методами ввода в разных программах. Поэтому и нужна унификация. Но находятся люди, которые смирились и даже находят некоторое удобство в постоянном переключении контекста ввода в зависимости от программы. И другим предлагают делать так же.

А может быть, лучше разбиндить Ctrl+S, чтоб не мучиться?

Работать приходится много где, везде не разбиндишь. Это дефолт, его в любом случае надо знать. А отсюда и следует:

Так чего же тебя ребиндинг Ctrl+Q беспокоит??? :)

Вот потому и.

А ты посчитай, сколько времени ты уже потратил на борьбу с ветряными мельницами.

и даже находят некоторое удобство в постоянном переключении контекста ввода в зависимости от программы

Он же вимер, он пользуется программой, в которой смена режима ввода положена в основу интерфейса. Для него наверняка GUI — не более, чем еще один режим ввода VIM. :-D

Инопланетяне, что с них взять...

cut-buffers вымерли давным давно.

ORLY?

Awesome.
Запускаем Firefox, и vim, так как он позволяет отдельно работать с каждым типом буфера.

Изначально:
selection: пусто
cut-buffer: пусто

Выделяем текст в firefox:
selection: текст
cut-buffer: пусто

Нажимаем Ctrl+C в firefox
selection: текст
cut-buffer: текст

Не расскажешь почему так?

Нет, у меня тоже основные KDE с запущенным Clipboard (или как там его), и я могу про это не париться. Но не едиными ж кедами...