LINUX.ORG.RU

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

 , , , ,


1

1

В Linux мы до сих пор работаем с текстовыми терминалами. Многим это представляется удобным. Но к текущему моменту накопился ворох проблем, которые никак не решается.

Например, тексты, с которыми происходит работа в терминале (в редакторе) зачастую шире и длиннее, чем экран терминала. И до сих пор не существует возможности скопировать текст, уползающий в редакторе «за экран», в буфер обмена.

Так же, в терминал не передаются нажатия клавиш-модификаторов, таких как Shift, Alt, Ctrl. Их коды передаются только с кодами символов основной клавиатуры. И существующие релизации плохо работают с не-символьными клавишами.

Из-за этих (и других) проблем до сих пор в *NIX не существует человеческого текстового редактора для терминала. Есть vi/vim/emacs с марсианскими интерфейсами, в которых стандартные действия в корне отличаются от тех, которые предусмотрены в DE. Человеку трудно работать в таких редакторах и DE-окружении, так как постоянно приходится для одних и тех же стандартных действий использовать разные клавиши и их сочетания. Это как минимум неэргономично.

Последняя сильная попытка сделать человеческий текстовый редактор для терминала - редактор micro. В нем искаропки сделано выделение шифтами+стрелками, работают стандартные сочетания Ctrl+C/V, и происходит копирование в/из буфера обмена средствами редактора (через xclip/xsel) а не терминала. Наконец-то это сделали, ведь XXI век на дворе.

И все, казалось бы, замечательно, за одним исключением: эти долгожданые возможности толком не работают при удаленном редактировании файлов. И если работу шифтов+стрелок и работу Ctrl+C/V еще можно настроить, то с буфером обмена полный облом. Он просто не может работать.

И сами авторы micro говорят: да, все эти проблемы есть, но ничего сделать не можем. При запуске micro локально пользуйтесь встроенным методом выделения и копирования текста. При запуске по SSH для копипаста используйте мышку+модификатор и клавиши копирования, которые предоставляет терминал. Да, это неудобно, неэргономично и выносит мозг. Но вот так. Да, и не забывайте, что сможете скопировать только символы на экране. Если текст шире/длинне экрана, тогда упс. Это же терминал. XXI век.

В связи с вышеперечисленным можно сформулировать несколько путей решения данной проблемы для редактора micro:


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

Реализуемость: нереально.


2. Забить на стандарты и сделать специальный терминал, который будет понимать самодельный расширенный протокол. Допилить под него micro.

Недостаток: все возможности micro все так же не будут работать в стандарных терминалах. Поэтому удобства нет.

Реализуемость: вполне возможно.


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

Достоинства: возможность работать в любом эмуляторе терминала без его доработки. Для пользователя все будет выглядеть так, как будто он работает с локальным редактором.

Недостатки: слишком замороченное подключение - запустить micro в SSH сессии, и запустить клиента. При последовательном редактрировании нескольких файлов соединение клиента будет переустанавливаться, ведь редактор запускают/останавливают. Для клиента надо будет выделять отдельный порт, что приведет к дополнительным настройкам фаивола, если таковой используется.

Реализуемость: вполне возможно.


Вопрос: если начать заниматься решением данной проблемы, то какой путь надо выбрать? Я пока склоняюсь к третьему пути, потому что в центре внимания должен быть пользователь, ибо компьютеры создаются для людей а не наоборот.

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

В общем, прошу высказаться по данному вопросу.

★★★★★

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

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

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

anonymous ()

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

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

anonymous ()

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

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

h578b1bde ★☆ ()

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

h578b1bde ★☆ ()
Ответ на: комментарий от anonymous

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

novoxudonoser ()

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

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

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

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

Deleted ()
Ответ на: комментарий от h578b1bde

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

4.2.

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

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

Разве нет?

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

Проверь.

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

Deleted ()

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

ananas ★★★★★ ()

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

Elyas ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Xintrea ★★★★★ ()

Так.

Во-первых выбрось свой 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.

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

Kroz ★★★★★ ()
Ответ на: комментарий от Xintrea

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

Естественно, 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. С моей точки зрения, пачка библиотек - вполне оправданная цена того, чтобы не писать свои костыли подобной сложности.

anonymous ()
Ответ на: комментарий от Kroz

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

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

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

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

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

Xintrea ★★★★★ ()
Последнее исправление: Xintrea (всего исправлений: 2)
Ответ на: комментарий от Kroz

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

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

Xintrea ★★★★★ ()
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от Kroz

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

Xintrea ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от Xintrea

Да, забыл сказать, что я и консоль настраиваю так, что в ней для копипаста работают стандартные 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, который улез за экран. Если ты до этого вопроса еще не дошел - проехали.

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

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

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Kroz

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

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

Deleted ()
Ответ на: комментарий от Xintrea

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

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

Deleted ()
Ответ на: комментарий от Xintrea

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

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

Deleted ()
Ответ на: комментарий от Deleted

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


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.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

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

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


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

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

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


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

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


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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Kroz

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

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

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

Deleted ()
Ответ на: комментарий от Xintrea

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

Deleted ()
Ответ на: комментарий от Xintrea

Ctrl+Q

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

Ага.

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от Xintrea

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

Никогда. :-D

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

Deleted ()
Ответ на: комментарий от Xintrea

> Кстати, куда ты перебро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) ).

Kroz ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

Xintrea ★★★★★ ()

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

Deleted ()
Ответ на: комментарий от Deleted

Никогда. :-D

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


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

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


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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

Вот потому и.

Deleted ()
Ответ на: комментарий от Xintrea

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

i-rinat ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

ORLY?

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

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

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

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

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

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

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.