Re: Продвинутая работа с клипбордом
Peter Pentchev - debian-russian@lists.debian.org @ Wed, 11 Jun 2014 10:19:00 +0300: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Еще вот в тему: http://www.nongnu.org/autocutsel/ В репозитории есть. Наткнулся, но не пробовал. PP Я пользуюсь тем, работает. Добавьте в .xsession: PP autocutsel -s PRIMARY -f PP autocutsel -s CLIPBOARD -f PP ...и оно синхронизует primary selection и clipboard. ... и переводит при этом в Latin1. В смысле, попытавшись выделить русский текст на странице в Firefox (PRIMARY) и потом вставить по Ctrl-V (CLIPBOARD), я получил серию \u-эскейпов. В man xterm, кстати, сказано, что cutbuffer только Latin1 и умеет. В отличие от selections. Идея-то хорошая... Я, кстати, правильно понял из man autocutsel, что с VNC и копированием русского текста можно расслабиться, потому что оно использует как раз cutbuffer? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvj0ne8x@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
On Fri, 20 Jun 2014, Artem Chuprina wrote: Peter Pentchev - debian-russian@lists.debian.org @ Wed, 11 Jun 2014 10:19:00 +0300: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Еще вот в тему: http://www.nongnu.org/autocutsel/ В репозитории есть. Наткнулся, но не пробовал. PP Я пользуюсь тем, работает. Добавьте в .xsession: PP autocutsel -s PRIMARY -f PP autocutsel -s CLIPBOARD -f PP ...и оно синхронизует primary selection и clipboard. ... и переводит при этом в Latin1. В смысле, попытавшись выделить русский текст на странице в Firefox (PRIMARY) и потом вставить по Ctrl-V (CLIPBOARD), я получил серию \u-эскейпов. В man xterm, кстати, сказано, что cutbuffer только Latin1 и умеет. В отличие от selections. С примечанием, что это официально, но клиенты игнорируют это. Скажем из koi8rxterm в uxterm русские слова копируются через primary даже с перекодировкой. Из firefox и в uxterm и в koi8rxterm и обратно тоже без проблем... Идея-то хорошая... Мне кажется, что иметь два буфера гораздо удобнее. Скажем требуется скопировать два слова, но переставив их местами. Первое выделяем с зажатым shift и оно сохраняется в clipboard, и затем второе просто выделяем и оно попадает в primary. Вставляем в обратном порядке. Недостаток, что вставка из clipboard в разных программах сделана по разному, приходится вспоминать. Ю.
Re: Продвинутая работа с клипбордом
yuri.nefe...@gmail.com - debian-russian@lists.debian.org @ Fri, 20 Jun 2014 13:58:51 +0400 (MSK): - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Еще вот в тему: http://www.nongnu.org/autocutsel/ В репозитории есть. Наткнулся, но не пробовал. PP Я пользуюсь тем, работает. Добавьте в .xsession: PP autocutsel -s PRIMARY -f PP autocutsel -s CLIPBOARD -f PP ...и оно синхронизует primary selection и clipboard. ... и переводит при этом в Latin1. В смысле, попытавшись выделить русский текст на странице в Firefox (PRIMARY) и потом вставить по Ctrl-V (CLIPBOARD), я получил серию \u-эскейпов. В man xterm, кстати, сказано, что cutbuffer только Latin1 и умеет. В отличие от selections. y С примечанием, что это официально, но клиенты игнорируют это. y Скажем из koi8rxterm в uxterm русские слова копируются через primary y даже с перекодировкой. Из firefox и в uxterm и в koi8rxterm y и обратно тоже без проблем... Это понятно, через PRIMARY отдельно и через CLIPBOARD отдельно никаких проблем. Там, как я понимаю, информация о кодировке сохраняется. А в случае с autocutsel получается, как я понял, PRIMARY - CUTBUFFER1 - CLIPBOARD, и вот промежуточный CUTBUFFER1 и ломает малину... Идея-то хорошая... y Мне кажется, что иметь два буфера гораздо удобнее. y Скажем требуется скопировать два слова, но переставив их y местами. Первое выделяем с зажатым shift и оно сохраняется в y clipboard, и затем второе просто выделяем и оно попадает в y primary. Вставляем в обратном порядке. А если надо три слова переставить? :) Вот для этого я и хотел своевременно выскакивающий менеджер истории выделений, в более широких кругах известный как clipboard manager. y Недостаток, что вставка из clipboard в разных программах y сделана по разному, приходится вспоминать. А где Shift-Ins (Сtrl-Ins для копирования) не работает? Ctrl-V, понятно, не везде, да и не жалко. Другой недостаток, на мой взгляд более существенный - это то, что я (см. мой изначальный пост с постановкой задачи) натыкаюсь на ситуацию вот сейчас бы ЗАМЕНИТЬ текст в поле ввода тем, что УЖЕ в PRIMARY. Ага, вторая засада с autocutsel... Оно таки ломает замену из clipboard. В смысле, в ситуации надо заменить заменяемое надо выделить - и оно немедленно попадает в CLIPBOARD вместо того, что хотелось вставить. И по Shift-Ins вставляется обратно. Впрочем, насчет немедленно у autocutsel есть ключик --pause, который мог бы и спасти. Но ситуация все равно останется чреватой сюрпризами. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g4booj7@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
On Mon, Jun 09, 2014 at 10:10:21PM +0400, Evgeny Zubok wrote: Artem Chuprina r...@ran.pp.ru writes: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Еще вот в тему: http://www.nongnu.org/autocutsel/ В репозитории есть. Наткнулся, но не пробовал. Я пользуюсь тем, работает. Добавьте в .xsession: autocutsel -s PRIMARY -f autocutsel -s CLIPBOARD -f ...и оно синхронизует primary selection и clipboard. Всего лучшего, Петр -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature
Re: Продвинутая работа с клипбордом
Александр Фролов - debian-russian@lists.debian.org @ Tue, 10 Jun 2014 09:14:23 +0400: АФ Я немножко к первым сообщениям вернусь, чтобы восстановить справедливость - АФ на всех современных (2008+ для synaptics точно) тачпадах есть хотя бы АФ ограниченная функция мультитач. Я, например, не пользуюсь аппаратными АФ кнопками тачпада, они ненадёжны, неудобны и имеют свойство со временем АФ ломаться. У меня используется АФ * тап двумя пальцами, как клик средней кнопки мыши, АФ * «елозенье» двум пальцами вертикально/горизонтально - как АФ вертикальная/горизонтальная прокрутка соответственно, АФ * тап тремя пальцами, как клик правой кнопки мыши АФ * на «елозенье» тремя пальцами вверх/вниз были настроены какие-то 2 горячих АФ предложения, не пользуюсь АФ * другие стандартные тачевские штуки: зум, вращение (не пользуюсь) Фигня в том, что тап двумя и тем более тремя пальцами и в стационарной-то обстановке зачастую интерпретируется как два одинарных, и указатель прыгает, а уж в поезде при тряске даже одинарный тап (левая кнопка) зачастую успевает сместить указатель. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a99lb8nr@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Artem Chuprina r...@ran.pp.ru writes: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Еще вот в тему: http://www.nongnu.org/autocutsel/ В репозитории есть. Наткнулся, но не пробовал. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha3ukl82@tochka.ru
Re: Продвинутая работа с клипбордом
Evgeny M. Zubok - debian-russian@lists.debian.org @ Sun, 08 Jun 2014 01:50:11 +0400: Prior to Emacs 24, the kill and yank commands used the primary selection (see Primary Selection), not the clipboard. If you prefer this behavior, change x-select-enable-clipboard to nil, x-select-enable-primary to t, and mouse-drag-copy-region to t. EMZ То есть, если я правильно понимаю, в 24-м надо назад включить PRIMARY, EMZ но и не выключать CLIPBOARD, т. е.: EMZ (setq x-select-enable-clipboard t) EMZ (setq x-select-enable-primary t) EMZ И должно тогда одновременно попадать в оба буфера. Вероятно, да. Но надо проверить. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r42zc3sl@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Hi. Вот, кстати, и аргумент в пользу старого доброго xterm vs. urxvt. А то я было хотел уже на urxvt переползать. Нет, ребята, лучше xterm пока ничего не придумали. В нем ВСЁ предусмотрено... [грустно] А может, в нем таки предусмотрена возможность восстанавливать содержимое после уменьшения окна, а потом возвращения прежнего размера? Я не нашел, но может, плохо искал?
Re: Продвинутая работа с клипбордом
Alex Kicelew - debian-russian@lists.debian.org @ Sun, 8 Jun 2014 12:34:53 +0400 (MSK): Вот, кстати, и аргумент в пользу старого доброго xterm vs. urxvt. А то я было хотел уже на urxvt переползать. Нет, ребята, лучше xterm пока ничего не придумали. В нем ВСЁ предусмотрено... AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mwdnbu8d@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Hi. AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. Я имел в виду другое. Не количество строк, а их длину. Запускаем хтерм, в нем запускаем ls (или любую другую программу, которая выводит достаточно длинные строки). Уменьшаем ширину окна (в тайловом менеджере, например, запускаем еще один хтерм). В получившемся маленьком окне видим только часть оригинальной длинной строки. Увеличиваем окно до первоначального размера (или больше). И видим в нем ту же самую часть первоначальной строки. Остальное пропало безвозвратно при изменении ширины. В рокстерме обе ситуации отрабатывают более корректно. При уменьшении ширины окна строки разбиваются по текущей ширине (разумеется, при этом по-прежнему теряется часть информации, т.к. новое окно меньше оригинального, но теряется не правая, а _верхняя_ часть, и ее можно достичь через shift-pgup), а при восстановлении ширины восстанавливаются и оригинальные строки. Эта возможность для меня достаточно критична, из-за чего и приходится пользоваться рокстермом, который меня не устраивает по многим параметрам -- но менее критичным. Но допускаю, что я чего-то не разглядел в хтерме, в котором меня устраивает все кроме этого.
Re: Продвинутая работа с клипбордом
On Sun, 8 Jun 2014, Alex Kicelew wrote: Hi. AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. Я имел в виду другое. Не количество строк, а их длину. Запускаем хтерм, в нем запускаем ls (или любую другую программу, которая выводит достаточно длинные строки). Уменьшаем ширину окна (в тайловом менеджере, например, запускаем еще один хтерм). В получившемся маленьком окне видим только часть оригинальной длинной строки. Увеличиваем окно до первоначального размера (или больше). И видим в нем ту же самую часть первоначальной строки. Остальное пропало безвозвратно при изменении ширины. В рокстерме обе ситуации отрабатывают более корректно. При уменьшении ширины окна строки разбиваются по текущей ширине (разумеется, при этом по-прежнему теряется часть информации, т.к. новое окно меньше оригинального, но теряется не правая, а _верхняя_ часть, и ее можно достичь через shift-pgup), а при восстановлении ширины восстанавливаются и оригинальные строки. Эта возможность для меня достаточно критична, из-за чего и приходится пользоваться рокстермом, который меня не устраивает по многим параметрам -- но менее критичным. Но допускаю, что я чего-то не разглядел в хтерме, в котором меня устраивает все кроме этого. Немного не то, но все же: xterm+screen обрабатывает ситуацию корректно. Плюс множество других удобств, скажем возможность работы с буфером вывода практически как с текстовым файлом. Ю.
Re: Продвинутая работа с клипбордом
Hi. Немного не то, но все же: xterm+screen обрабатывает ситуацию корректно. Плюс множество других удобств, скажем возможность работы с буфером вывода практически как с текстовым файлом. Да, спасибо, скрин я использую, но все же он применим не всегда. В частности, для корректной работы именно этого момента он должен быть уже запущен.
Re: Продвинутая работа с клипбордом
Alex Kicelew - debian-russian@lists.debian.org @ Sun, 8 Jun 2014 14:19:18 +0400 (MSK): AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. AK Я имел в виду другое. Не количество строк, а их длину. Запускаем AK хтерм, в нем запускаем ls (или любую другую программу, которая AK выводит достаточно длинные строки). Уменьшаем ширину окна (в AK тайловом менеджере, например, запускаем еще один хтерм). В AK получившемся маленьком окне видим только часть оригинальной длинной AK строки. Увеличиваем окно до первоначального размера (или больше). И AK видим в нем ту же самую часть первоначальной строки. Остальное AK пропало безвозвратно при изменении ширины. AK В рокстерме обе ситуации отрабатывают более корректно. При AK уменьшении ширины окна строки разбиваются по текущей ширине AK (разумеется, при этом по-прежнему теряется часть информации, AK т.к. новое окно меньше оригинального, но теряется не правая, а AK _верхняя_ часть, и ее можно достичь через shift-pgup), а при AK восстановлении ширины восстанавливаются и оригинальные строки. AK Эта возможность для меня достаточно критична, из-за чего и AK приходится пользоваться рокстермом, который меня не устраивает по AK многим параметрам -- но менее критичным. Но допускаю, что я чего-то AK не разглядел в хтерме, в котором меня устраивает все кроме этого. А, понял. Да, есть такая проблема. Пишут, что у urxvt ее нет. Просто у меня такая конфигурация окон xmonad, что меня эта проблема практически не касается. На новой машинке, может, и коснется... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioobbg3w@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
On 06/07/2014 10:50 AM, Artem Chuprina wrote: предыдущее состояние удалять путем зажимания BackSpace и/или Del s Вместо зажимания можно нажать Ctrl-A, а потом BackSpace или Del. Произойдет ровно описанный далее эффект. У меня всё работает. -- sergio. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53949521.3040...@sergio.spb.ru
Re: Продвинутая работа с клипбордом
On 2014.06.06 at 15:38:54 +0400, Artem Chuprina wrote: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Я переполз на lxterminal, он умеет работать с клипборд по стандартной виндовой модели. В смысле с явной операцией copy. Переполз, конечно, не из-за этого. Но у меня сильное подозрение что мейнтейнеры emacs-а руководствовались именно мыслью о том, что нехорошо когда все программы идут не в ногу, один emacs в ногу. Поэтому когда терминальные программы, интегрированные во всякие de (lxterminal, gnome-terminal, konsole) cущественно потеснили старый-добрый xterm, на новую модель работы с выделениями пришлось переползать и emacs. Вдвоем универсальный обработчик текстов и эмулятор терминала - это сила. Но в одиночку каждый из них не тянет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609041133.ga18...@wagner.pp.ru
Re: Продвинутая работа с клипбордом
dm.fedorov - Russian Debian List @ Fri, 6 Jun 2014 19:11:30 +0700: Я тут некоторое время назад в jessie наткнулся на то, что emacs теперь по умолчанию при копировании работает не с primary selection, а с clipboard. (Примечание: тем, кто сходу не понял, о чем я, просьба не беспокоиться и дальше не читать, и тем более не отвечать.) d Я понял - натрахался в своё время с моим любимым редактором d (не emacs). d Там сломали механизм selection в пользу clipboard. d Как починить - до сих пор не понял. d Из редактора в xterm и обратно просто так не вставить, а ведь было! selectToClipboard (class SelectToClipboard) Tells xterm whether to use the PRIMARY or CLIPBOARD for SELECT tokens in the selection mechanism. The set-select action can change this at runtime, allowing the user to work with programs that handle only one of these mechanisms. The default is “false”, which tells it to use PRIMARY. Вот, кстати, и аргумент в пользу старого доброго xterm vs. urxvt. А то я было хотел уже на urxvt переползать. Нет, ребята, лучше xterm пока ничего не придумали. В нем ВСЁ предусмотрено... Чем удобна иксовая модель работы с выделением: выделил - и вот выделение Третье - увы, средняя кнопка встречается все реже, а эмуляция ее d То есть как это? На почти любой мышке есть колесо, нажатие на которое d вертикально d даёт клик средней кнопки. Помимо мышек, есть еще тачпады и другие не лишенные странности девайсы. Впрочем, на том ноутбуке, на котором я об этом задумался, тачпад (я описывал) лишен основного преимущества тачпада перед мышкой - возможности надежно работать при тряске, например, в поезде. Чего бы мне, по ощущениям, хотелось: d Мне бы хотелось, чтобы из наших юниксов ушли все мастдайщики d и забрали с собой все свои изменения. d Но происходит наоборот. Справедливости ради, надо заметить, что у иксов и у CUA ноги растут все из одного и того же Palo Alto. Только в иксы взяли больше тамошних разработок. Тот же clipboard и модель работы с ним были, насколько я понимаю, когда Билл Гейтс еще в гараже мучительно придумывал бизнес-модель для MS-DOS. И я вот не просто так задумался, не правы ли они, и не просто так привел аргументы... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iooef6wx@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
sergio - debian-russian@lists.debian.org @ Fri, 06 Jun 2014 17:05:20 +0400: предыдущее состояние удалять путем зажимания BackSpace и/или Del s Вместо зажимания можно нажать Ctrl-A, а потом BackSpace или Del. Произойдет ровно описанный далее эффект. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878up9ciwc@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Dmitrii Kashin - debian-russian@lists.debian.org @ Fri, 06 Jun 2014 23:47:57 +0400: Чего бы мне, по ощущениям, хотелось: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) DK Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, DK а при добавлении в kill-ring, добавляется к тому же в clipboard. Это в 24-м или в 23-м? В 23-м вроде так, но он и обратно по средней кнопке и C-y в умолчательных настройках вставляет primary. Заставило задуматься меня то, что в 24-м primary из соседнего urxvt отказалось вставляться в emacs. Я пошел читать, и задумался шире, чем просто как вернуть как было. В emacs нововведения, ломающие обратную совместимость даже на уровне умолчаний, как правило, обоснованы. Можно соглашаться с обоснованиями, можно нет, но задуматься в такой ситуации точно стоит. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mzxchu6@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Evgeny M. Zubok - debian-russian@lists.debian.org @ Sat, 07 Jun 2014 00:23:52 +0400: Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, а при добавлении в kill-ring, добавляется к тому же в clipboard. Я нахожу это очень удобным. А ты, я так понимаю, хочешь, чтобы сразу при выделении кусок в clipboard отправлялся? EMZ А вот у меня в emacs23-lucid выделение, как я уже выше сказал, попадает EMZ одновременно в primary selection и в clipboard. И после kill тоже в оба EMZ буфера. Э, а у меня - нет... Это недефолтная настройка? EMZ То есть, находясь уже в другом приложении, я могу выбрать, как мне EMZ вставлять: надо заменить выделенное - нажму Ctrl+V, просто EMZ вставить - вторую кнопку мыши (сэмулирванную). Но вообще идея интересная. EMZ Такое же поведение можно сделать и в xterm, просто дописав к CLIPBOARD EMZ еще и PRIMARY, то есть в примерах выше заменить select-end(CLIPBOARD) на EMZ select-end(CLIPBOARD, PRIMARY), переопределив Btn1Up без Shift: EMZ Btn1Up: select-end(CLIPBOARD, PRIMARY)\n\ А вот за эту мысль отдельное спасибо. До selectToClipboard я дочитал, а до возможности засунуть сразу в обе - нет. Хотя хорошая ли это мысль - тоже надо подумать... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjhpb2or@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Artem Chuprina r...@ran.pp.ru writes: Dmitrii Kashin - debian-russian@lists.debian.org @ Fri, 06 Jun 2014 23:47:57 +0400: Чего бы мне, по ощущениям, хотелось: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) DK Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, DK а при добавлении в kill-ring, добавляется к тому же в clipboard. Это в 24-м или в 23-м? В 23-м вроде так, но он и обратно по средней кнопке и C-y в умолчательных настройках вставляет primary. В 24-м. C-y теперь работает с клипбордом и из primary вставлять не будет. Мне кажется, что это разумно и удобно. А активным пользователем я стал именно с приходом 24й версии, и к тому, что было до неё естественно привыкнуть не успел. Заставило задуматься меня то, что в 24-м primary из соседнего urxvt отказалось вставляться в emacs. Вот только что сунулся в urxvt, выделил приглашение командной строки, открыл *scratch* и по mouse-2 вставил. Попробуй загрузиться без конфига, может, ты что-то намудрил в своё время? Или может быть ты плохо нажал? Колёсико там прокрутилось во время нажатия или ещё чего. В emacs нововведения, ломающие обратную совместимость даже на уровне умолчаний, как правило, обоснованы. Можно соглашаться с обоснованиями, можно нет, но задуматься в такой ситуации точно стоит. Я позволю себе не согласиться. Это же умолчания. Я удивлён, что они вообще кого-то волнуют, кроме новичков. Особенно в Emacs, где огромную часть умолчаний я лично переписал под себя, потому что мне так удобнее. pgp8knY2tBJo3.pgp Description: PGP signature
Re: Продвинутая работа с клипбордом
Artem Chuprina r...@ran.pp.ru writes: EMZ А вот у меня в emacs23-lucid выделение, как я уже выше сказал, попадает EMZ одновременно в primary selection и в clipboard. И после kill тоже в оба EMZ буфера. Э, а у меня - нет... Это недефолтная настройка? Недефолтная, да. У меня установка: (setq x-select-enable-clipboard t) Если nil, то уже выделение в clipboard не попадает. Повторю, что это в emacs 23 (lucid), но вот с Emacs 24 надо поиграться, так как, как правильно ты заметил, они что-то изменили, но документировали это дело. К сожалению, не могу проверить. https://www.gnu.org/software/emacs/manual/html_node/emacs/Clipboard.html: Prior to Emacs 24, the kill and yank commands used the primary selection (see Primary Selection), not the clipboard. If you prefer this behavior, change x-select-enable-clipboard to nil, x-select-enable-primary to t, and mouse-drag-copy-region to t. In this case, you can use the following commands to act explicitly on the clipboard: clipboard-kill-region kills the region and saves it to the clipboard; clipboard-kill-ring-save copies the region to the kill ring and saves it to the clipboard; and clipboard-yank yanks the contents of the clipboard at point. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g4tcbqq@tochka.ru
Re: Продвинутая работа с клипбордом
On Fri, 6 Jun 2014, Evgeny M. Zubok wrote: А вот это место у меня сделано так: если выделяю в xterm с зажатым Shift, то выделение попадает в CLIPBOARD, если просто выделяю, то в PRIMARY. И наоборот: если вставляю в xterm с Shift (Btn2), то вставка из CLIPBOARD, если просто Btn2, то из PRIMARY SELECTION. В ~/.Xresources: *VT100.Translations: #override\n\ ShiftBtn1Down:select-start()\n\ ShiftBtn1Motion: select-extend()\n\ ShiftBtn1Up: select-end(CLIPBOARD)\n\ ShiftBtn2Up: insert-selection(CLIPBOARD)\n\ ShiftBtn3Down:start-extend()\n\ ShiftBtn3Motion: select-extend()\n\ ShiftBtn3Up: select-end(CLIPBOARD) О, спасибо, удобно. Как я без этого жил. ) Кстати в vim под xterm это тоже работает. В gvim же можно через регистры `*` - PRIMARY и `+` - CLIPBOARD. Ю.
Re: Продвинутая работа с клипбордом
Dmitrii Kashin - debian-russian@lists.debian.org @ Sat, 07 Jun 2014 11:44:33 +0400: Чего бы мне, по ощущениям, хотелось: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) DK Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, DK а при добавлении в kill-ring, добавляется к тому же в clipboard. Это в 24-м или в 23-м? В 23-м вроде так, но он и обратно по средней кнопке и C-y в умолчательных настройках вставляет primary. DK В 24-м. C-y теперь работает с клипбордом и из primary вставлять не DK будет. Мне кажется, что это разумно и удобно. А активным пользователем я DK стал именно с приходом 24й версии, и к тому, что было до неё естественно DK привыкнуть не успел. Это разумно и удобно, когда согласованно. А когда рассогласовано - неудобно и неразумно. Заставило задуматься меня то, что в 24-м primary из соседнего urxvt отказалось вставляться в emacs. DK Вот только что сунулся в urxvt, выделил приглашение командной строки, DK открыл *scratch* и по mouse-2 вставил. Попробуй загрузиться без конфига, DK может, ты что-то намудрил в своё время? Или может быть ты плохо нажал? DK Колёсико там прокрутилось во время нажатия или ещё чего. Я, понятно, не один раз попробовал. И вообще-то у urxvt наблюдаемое мной поведение документировано, а работа с CLIPBOARD - нет. Правда, наблюдалось зимой, может, с тех пор в jessie поменялась версия urxvt, а в ней - умолчания? В emacs нововведения, ломающие обратную совместимость даже на уровне умолчаний, как правило, обоснованы. Можно соглашаться с обоснованиями, можно нет, но задуматься в такой ситуации точно стоит. DK Я позволю себе не согласиться. Это же умолчания. Я удивлён, что они DK вообще кого-то волнуют, кроме новичков. Особенно в Emacs, где огромную DK часть умолчаний я лично переписал под себя, потому что мне так удобнее. А еще больше - НЕ переписал. Видишь ли, в emacs ОЧЕНЬ МНОГО ручек, и у каждой есть умолчательное состояние. И в норме они вполне разумны вот ровно ради того, чтобы не приходилось ПЕРВЫМ ДЕЛОМ править все стопицот. У меня в конфигах всего с полсотни ручек подкручено. И разработчики это понимают, и подходят к выбору, а тем более замене умолчаний, как правило, с умом. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbscbn35@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Evgeny M. Zubok evgeny.zu...@tochka.ru writes: Prior to Emacs 24, the kill and yank commands used the primary selection (see Primary Selection), not the clipboard. If you prefer this behavior, change x-select-enable-clipboard to nil, x-select-enable-primary to t, and mouse-drag-copy-region to t. То есть, если я правильно понимаю, в 24-м надо назад включить PRIMARY, но и не выключать CLIPBOARD, т. е.: (setq x-select-enable-clipboard t) (setq x-select-enable-primary t) И должно тогда одновременно попадать в оба буфера. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738fgcru4@tochka.ru
Продвинутая работа с клипбордом
Привет. Я тут некоторое время назад в jessie наткнулся на то, что emacs теперь по умолчанию при копировании работает не с primary selection, а с clipboard. (Примечание: тем, кто сходу не понял, о чем я, просьба не беспокоиться и дальше не читать, и тем более не отвечать.) Сперва чертыхнувшись, я, во-первых, без труда нагуглил, как чинить, а во-вторых, помня о разнице между удобно и привычно, решил подумать, не правы ли они, часом. И чинить не стал. И вот у меня появилось желание изложить модель работы и послушать мнения и если есть, решения, коллег, тоже читавших Раскина :) Чем удобна иксовая модель работы с выделением: выделил - и вот выделение готово, больше ничего делать не надо. Переместил мышку в целевое окно, прицелился (а в случае с эмуляторами терминалов даже и не прицелился), ткнул среднюю кнопку - вставилось. Минимум жестов. Чем неудобна: неудобно вставлять в уже заполненное текстовое поле, если хотелось его заменить (в основном я с этим натыкаюсь либо на заполненное по историческим причинам поле ввода в браузере, либо на поисковую, реже адресную строку в том же браузере): приходится предыдущее состояние удалять путем зажимания BackSpace и/или Del, ибо при попытке double/triple-click + BackSpace уже готовое выделение, которое хотелось вставить, потеряется. В этом смысле CUA'шная модель работы с clipboard удобнее, конечно. Второе неудобство - если выйти из программы, в которой было сделано выделение, оно теряется. Кажется, я на это натыкался даже при выходе из терминальных программ, хотя сейчас не воспроизводится, и вообще было бы странно. Однако, натыкался. Третье - увы, средняя кнопка встречается все реже, а эмуляция ее одновременным нажатием на первые две требует совершенно лишней в этом месте концентрации... Впрочем, на новом ноутбуке у меня и левая с правой отсутствуют - в смысле, являются частью тачпада, что приводит к смещению курсора в момент нажатия на кнопку :( Так что я бы не рассматривал это как существенное неудобство. И тем не менее, сейчас во множестве (ну, под виндой во множестве, но у нас в дистрибутиве вроде тоже есть) в качестве дополнения к модели CUA плодятся clipboard manager'ы, которые умеют хранить историю записанного в clipboard и позволяют вставить не только последнее, что было туда засунуто. Чего бы мне, по ощущениям, хотелось: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) - соответственно, чтобы при засовывании в clipboard выделенное попадало в историю clipboard manager'а - чтобы при вставке из clipboard подскакивал clipboard manager и сразу предлагал недавнюю историю; при этом чтобы он эргономично управлялся с клавиатуры Для начала покритикуйте хотелки, я вовсе не уверен, что они хороши. Потом, может, кто чего умного подскажет в смысле реализации? Gnome- и KDE-based решения, извините, не предлагать. Я вот думаю, может, оставить работу с выделением так, как она есть, а сверху поручить window manager'у (у меня xmonad, он довольно хорошо настраивается) реагировать на один жест засовыванием primary selection в clipboard и в историю, а на другой - предложением этой истории с последующим paste выбранного в текущее окно? Правда, придется еще потанцевать на тему того, попадает ли у emacs24-gtk выделенное сразу в primary selection, или тоже еще надо попинать... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r432fesx@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
6 июня 2014 г., 18:38 пользователь Artem Chuprina r...@ran.pp.ru написал: Я тут некоторое время назад в jessie наткнулся на то, что emacs теперь по умолчанию при копировании работает не с primary selection, а с clipboard. (Примечание: тем, кто сходу не понял, о чем я, просьба не беспокоиться и дальше не читать, и тем более не отвечать.) Я понял - натрахался в своё время с моим любимым редактором (не emacs). Там сломали механизм selection в пользу clipboard. Как починить - до сих пор не понял. Из редактора в xterm и обратно просто так не вставить, а ведь было! Чем удобна иксовая модель работы с выделением: выделил - и вот выделение Третье - увы, средняя кнопка встречается все реже, а эмуляция ее То есть как это? На почти любой мышке есть колесо, нажатие на которое вертикально даёт клик средней кнопки. Чего бы мне, по ощущениям, хотелось: Мне бы хотелось, чтобы из наших юниксов ушли все мастдайщики и забрали с собой все свои изменения. Но происходит наоборот.
Re: Продвинутая работа с клипбордом
06.06.2014 16:11, dm.fedorov пишет: Третье - увы, средняя кнопка встречается все реже, а эмуляция ее То есть как это? На почти любой мышке есть колесо, нажатие на которое вертикально даёт клик средней кнопки. На тачпадах нет средней кнопки. Только две сразу жать. Но если кнопки являются частью чувствительного тачпада - это проблема. С мышкой не удобно сидеть с ноутом на коленях. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Продвинутая работа с клипбордом
6 июня 2014 г., 18:11 пользователь dm.fedorov dm.fedo...@gmail.com написал: Третье - увы, средняя кнопка встречается все реже, а эмуляция ее То есть как это? На почти любой мышке есть колесо, нажатие на которое вертикально даёт клик средней кнопки. У меня на ноуте две отдельные аппаратные кнопки и это мне еще повезло. Полоса прокрутки - край тачпада. Третью кнопку не настроить - эмулирую. На ноуте дочери вместо двух отдельных кнопок - пластмассовая деталька, которая _качается_ на оси так, что две кнопки одновременно не нажать, так что даже эмуляцию не включить. -- Stanislav
Re: Продвинутая работа с клипбордом
6 июня 2014 г., 19:22 пользователь Stanislav Vlasov написал: У меня на ноуте две отдельные аппаратные кнопки и это мне еще повезло. У меня тоже. Но мы же не про ноуты, а про мышки.
Re: Продвинутая работа с клипбордом
6 июня 2014 г., 18:36 пользователь dm.fedorov dm.fedo...@gmail.com написал: У меня на ноуте две отдельные аппаратные кнопки и это мне еще повезло. У меня тоже. Но мы же не про ноуты, а про мышки. Практически не пользуюсь за ноутом. Обычно просто негде положить. -- Stanislav
Re: Продвинутая работа с клипбордом
On 06/06/2014 02:20 PM, Mikhail A Antonov wrote: 06.06.2014 16:11, dm.fedorov пишет: Третье - увы, средняя кнопка встречается все реже, а эмуляция ее То есть как это? На почти любой мышке есть колесо, нажатие на которое вертикально даёт клик средней кнопки. На тачпадах нет средней кнопки. Только две сразу жать. Но если кнопки являются частью чувствительного тачпада - это проблема. С мышкой не удобно сидеть с ноутом на коленях. я на мак-буке переназначил среднюю кнопку мыши на кнопку eject, все равно ей не пользуюсь.. также иногда пользуюсь xsel-ом вместо того чтобы комбинацией пальцев елозить... хотелки имхо правильные. - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard помоему это абсолютно естественно, бесит когда надо еще и кликать. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5391b6b2.30...@biotec.tu-dresden.de
Re: Продвинутая работа с клипбордом
Artem Chuprina r...@ran.pp.ru writes: Сорри, сразу все не вобрал еще, да и не по всем пунктам посоветую, так как у меня сейчас emacs23, да и тот - lucid, а у него выделение попадает одновременно и в PRIMARY, и в CLIPBOARD. Также не подскажу ничего по xmonad. В общем, время надо, чтобы подумать. - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) А вот это место у меня сделано так: если выделяю в xterm с зажатым Shift, то выделение попадает в CLIPBOARD, если просто выделяю, то в PRIMARY. И наоборот: если вставляю в xterm с Shift (Btn2), то вставка из CLIPBOARD, если просто Btn2, то из PRIMARY SELECTION. В ~/.Xresources: *VT100.Translations: #override\n\ ShiftBtn1Down:select-start()\n\ ShiftBtn1Motion: select-extend()\n\ ShiftBtn1Up: select-end(CLIPBOARD)\n\ ShiftBtn2Up: insert-selection(CLIPBOARD)\n\ ShiftBtn3Down:start-extend()\n\ ShiftBtn3Motion: select-extend()\n\ ShiftBtn3Up: select-end(CLIPBOARD) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhtatcdn@tochka.ru
Re: Продвинутая работа с клипбордом
On 06/06/2014 03:38 PM, Artem Chuprina wrote: предыдущее состояние удалять путем зажимания BackSpace и/или Del Вместо зажимания можно нажать Ctrl-A, а потом BackSpace или Del. -- sergio. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5391bc90.7080...@sergio.spb.ru
Re: Продвинутая работа с клипбордом
Artem Chuprina r...@ran.pp.ru writes: Я тут некоторое время назад в jessie наткнулся на то, что emacs теперь по умолчанию при копировании работает не с primary selection, а с clipboard. (Примечание: тем, кто сходу не понял, о чем я, просьба не беспокоиться и дальше не читать, и тем более не отвечать.) Чего бы мне, по ощущениям, хотелось: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, а при добавлении в kill-ring, добавляется к тому же в clipboard. Я нахожу это очень удобным. А ты, я так понимаю, хочешь, чтобы сразу при выделении кусок в clipboard отправлялся? Есть, к слову, две приятные переменные: x-select-enable-clipboard и x-select-enable-primary. Можно порыть в этом направлении. Но я бы на твоём месте смотрел в официальную документацию: [1]. - соответственно, чтобы при засовывании в clipboard выделенное попадало в историю clipboard manager'а - чтобы при вставке из clipboard подскакивал clipboard manager и сразу предлагал недавнюю историю; при этом чтобы он эргономично управлялся с клавиатуры Кстати, а я вот до сих пор никакими clipboard manager-ами не пользуюсь. Есть что-нибудь достойное внимания, не завязанное на Gnome/KDE? А то мне всё равно ими не пользоваться, ибо i3wm. Правда, придется еще потанцевать на тему того, попадает ли у emacs24-gtk выделенное сразу в primary selection, или тоже еще надо попинать... Попадает, судя по всему. По крайней мере mouse-2 у меня только что прекрасно вставил в терминал выделенный текст. Сообщению я, пожалуй, пин поставлю; завтра утром ещё разок гляну на свежую голову. А то сейчас спать уже пора. [1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Cut-and-Paste.html#Cut-and-Paste pgpMvr4iIUIn4.pgp Description: PGP signature
Re: Продвинутая работа с клипбордом
Dmitrii Kashin free...@freehck.ru writes: Я что-то не уловил. Сейчас выделение сразу попадает в primary selection, а при добавлении в kill-ring, добавляется к тому же в clipboard. Я нахожу это очень удобным. А ты, я так понимаю, хочешь, чтобы сразу при выделении кусок в clipboard отправлялся? А вот у меня в emacs23-lucid выделение, как я уже выше сказал, попадает одновременно в primary selection и в clipboard. И после kill тоже в оба буфера. То есть, находясь уже в другом приложении, я могу выбрать, как мне вставлять: надо заменить выделенное - нажму Ctrl+V, просто вставить - вторую кнопку мыши (сэмулирванную). Такое же поведение можно сделать и в xterm, просто дописав к CLIPBOARD еще и PRIMARY, то есть в примерах выше заменить select-end(CLIPBOARD) на select-end(CLIPBOARD, PRIMARY), переопределив Btn1Up без Shift: Btn1Up: select-end(CLIPBOARD, PRIMARY)\n\ -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha3xu6qv@tochka.ru
