xterm 325

Обычно такое пишут дилетанты, подразумевая что вот то, что они пишут это верная информация.

В тайловом WM поиспользуй, всё встанет на свои места.

Использую в тайловом WM. Хотелось бы всё же услышать хотя бы тезисно, что там не так.

batekman, dober, SpaceRaven, feofan, sergej, может будет интересно (а может чего добавите):
Эмуляторы терминалов: тест скорости, комментарии...

Для Ъ: Eterm - страшный сон, st весьма неплох, второе место urxvt.

И сейчас ты такой показываешь современные альтернативы или балабол.

А теперь сделай пожалуйста «cat /var/log/messages.log | xsel» и потом в каждом «cat > /tmp/somefile» и посчитай количество строк и md5 от результата и сравни с оригиналом.

С чего бы?

Я имел в виду, что не очень то удобно с ним работать в stacking...но может я и не прав.

Именно, так как urxvt её лишен (и пока только он)

Не только. termite не обрезает. st по заверениям разрабов - тоже (не проверял).

начинал рабочий день с того что на pdp11/70 под RSX-oм на терминале Textronix

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

На HiDPI действительно нет смысла в растровых шрифтах

Да иди ты, я использую божественный Terminus на своих 200+ dpi и счастлив.

я использую божественный Terminus на своих 200+ dpi и счастлив.

12x24?

Делать расширения типа такого:

https://github.com/muennich/urxvt-perls/blob/master/keyboard-select

Ты из пещеры вылез? Gnome terminal, konsole и тд.

«Я использую» не контраргумент к «нет смысла».

Ясно. Очередной школьник, дальше своего локалхоста никогда не ходивший.

Доказывай, или балабол. Смотри не обделайся.

А я пользуюсь Sakura

я ставлю urxvt

А что в нём есть такого, чего нет в xterm?

зависимость от perl ;)

Ресайз всё так же плох.

Для уже выведенного текста - да.

Как и у большинства терминалов. А причина проста, и она древнее самого xterm - когда-то [железные] терминалы имели фиксированный размер экрана, а событие «ресайза» появилось уже в эмуляторах. Это событие, как данность, передаётся [эмулятором терминала] терминальному приложению, а сам же шелл - не очень полноценное терминальное приложение, в полном смысле этого слова, - это интерактивная диалоговая система. То есть - шелл что-то написал и забыл про это. Терминал - нарисовал вывод и забыл про него. Пришло событие на ресайз - терминал его передал шеллу - шелл свой $PS1 перерисовал, и на том считает свою миссию выполненной. Да, это не полностью корректное поведение («буфер отмотки» мог бы храниться и в виде дампа строк, а не графического оттиска, но тут возникает проблема с эмуляцией графических терминалов - tek4004, vt260, vt340, vt520), однако так поступает подавляющее большинство относительно универсальных эмуляторов терминала.

Делать расширения

* А теперь то же самое, но без перла? Табы, гриды, работа с клавиатурой, - это всё чудесно и замечательно, но:

- rxvt эмулирует только и исключительно текстовые терминалы

- rxvt для работы со своими «бонусными надстройками» использует perl, который лихо тягает за собой в зависимостях. Для мобильной системы, скажем, каждая зависимость - как серпом по мегабайтам NAND...

С удовольствием рассмотрю аналог этого «плагина» на, скажем, bash. Табы на bash реализованные также посмотрю с большим интересом. В итоге - пересмотрю свою позицию по поводу полной ненужности rxvt в свете существования альтернативных эмуляторов, - того же xterm.

Именно, так как urxvt её лишен (и пока только он)

в принципе, любой эмулятор «text only» терминала может быть лишен этой самой «проблемы ресайза», - достаточно, чтобы он хранил текстовый буфер вывода запущенного приложения. Проблема возникает, когда то же самое нужно сделать для эмуляции графических терминалов.

Я бы не сказал, что это такая уж «страшная» проблема. Хотя, да, иной раз неприятно повторно дёргать команду после ресайза окошка, чтобы нормализовать вывод.

Это серьезная проблема, когда пользуешься тайлом. Очень удобно. а команды дергать - это потерять это удобство. Тайл тогда не нужен.

И да, я неправильно сформулировал мысль.

rxvt эмулирует только и исключительно текстовые терминалы

серпом по мегабайтам NAND

ну если тебе нужны графические escape-последовательности на терминале на мобильном устройстве с нанд, то... rxvt тебе не нужен. Я и не настаиваю)

Это серьезная проблема, когда пользуешься тайлом.

Ну эт ты, брат, перегнул. Проблемой ты называешь штатное поведение 99% терминальных эмуляторов.

Я «пользуюсь тайлом» (dwm), и основным «терминалом» у меня - пресловутый xterm. Потому что он гибкий, совместимый с различными терминальными протоколами, поддерживает всяческие расширения, и прочее, и прочее... НО. Я бы предпочел иметь разные эмуляторы терминала под различные терминальные протоколы. На заре появления иксов появилось несколько терминальных эмуляторов - vt, uvt, xvt, универсальный комбайн xterm. Эти терминальные эмуляторы различались в стиле работы с протоколом - xterm жестко следовал документированным протоколам и их расширениям, и в точности имитировал поведение «железного терминала», в то время как xvt и его семейство - позволял себе ряд вольностей, как указанная тобой «буферизация» и «перерисовка контента» при ресайзе. Так как rxvt - наследник линейки эмуляторов терминала VT10X, он унаследовал также и буферизацию текста, выводимого программой, запущенной в терминале. Обсуждаемый же здесь xterm работает не только с протоколом семейства VT100/VT102/VT200, но и с кучей сторонних расширений, таких как ReGIS, SIXEL, TEK4XXX, и так далее. Эти расширения зачастую предполагают прозрачную обратную совместимость с базовым VT100, однако позволяют «рисовать графику» прямо поверх текста, или смешивать текст и графику. В принципе, можно было бы организовать механизм буферизации и этих данных, и последующую их перерисовку, однако это зничительно увеличит как потребление памяти, так и потребление процессорного времени. Кроме того - это поведение не предусматривается терминальными протоколами - «железные» терминалы имели минимум памяти, на пару-тройку буферных страниц максимум. А некоторые терминалы - так и вобще использовали собственный экран для хранения данных. Да, это дела давно минувших дней, но расскажи об этом тем (e.g. Royal Post), кто до сих пор использует терминальный доступ к мейнфреймам 390-й серии, например. rxvt/urxvt ограничен протоколом vt100, с которым работает, и он реализует собственный механизм хранения полученных данных, большинство же терминалов, работающих с расширениями VT260/etc - используют механизм, заложенный при проектировании тех самых терминалов. Тот же xterm можно было бы переписать, конечно, но на это придётся тратить время и ресурсы. А оно кому-то надо? Автору - точно нет. Мне? Я был бы рад, если бы означенная тобой буферизация появилась бы в xterm, но не в ущерб скорости его работы и совместимости с протоколами, отличными от vt100/vt102.

А означенная тобой «проблема» наблюдается не только в иксовых «тайлах» с любыми терминальными эмуляторами, но и в текстовых - dvtm, tmux, screen - все они грешат совместимостью с «родительским протоколом» VT. Так что - rxvt - исключение, подтверждающее правило.

следовательности на терминале на мобильном устройстве с нанд, то... rxvt тебе не нужен. Я и не настаиваю)

- Я бы предпочел увидеть ответ на вопросы «`как использовать rxvt без perl` и `как писать rxvt расширения на bash/dash/ksh/rc/etc`».

Я на этого потомка xvt не смотрел уже давно, примерно с тех пор, как он «испортился и начал пахнуть устрицами». И мне интересно - неужели никто еще не реализовал костылей для rxvt-модулей в виде простых шелл-скриптов, вместо использования перла?

как использовать rxvt без perl

Скомпилировать с --disable-perl, он вобщем то и без расширений нормально работает вроде.

как писать rxvt расширения на bash/dash/ksh/rc/etc

Хз

Именно. Вот только не помню, но вроде в screen и(или) tmux эту проблему тоже решили.

И это, видимо, ИМХО: у меня быстрее пользоваться тайлом (тот же dwm с meta+Ret - это песня), чем прыгать по буферам в emacs.

как писать rxvt расширения на bash/dash/ksh/rc/etc

Хз

От же блин... Ну и ладно. Тогда действительно - пусть rxvt остаётся тем, кому он нужен, а мне придётся пользоваться xterm, либо самому сделать расширения к st.

А жаль.

у меня быстрее пользоваться тайлом (тот же dwm с meta+Ret - это песня)

Аналогично. Я dwm еще и для тач-скринов приспособил (добавил кнопари управления окнами и тайлом в бар, сейчас продолжаю доводку, но кодинг для него унылый, - придётся, видимо, половину переписать - сделать его reparent'ом, ибо в текущем виде некоторые вещи для тач-скринов не сделать; текущая архитектура не позволяет сделать некоторые эвенты, заголовки или холдеры окон для таскания пальцем-мышкой, и еще ряд вещей - просто нереализуемы в текущей архитектуре dwm).

А емакс... Ну - емакс. Как по мне - так жутко неудобная поделка.

Что касается твоей «проблемы» - есть такой эмулятор, как st, для него, в принципе, можно сделать буфер вывода, и решить граблю с ресайзом в легковесном эмуляторе терминала. Думаю, что это не будет слишком сложно (когда-то я его на SDL1.2 портировал - для работы в линуксовом фреймбуфере, - сделал; начал добавлять в st «слой графических абстракций», но забил - времени нет. - есть большое желание сделать «альтернативу xterm», добавить графические протоколы, сделать расширения-плагины через свой API, in-term тайлы, скролл-буферы и еще ряд вещей - st для этого всего прекрасная заготовка, которая будет работать как в иксах, так и в консоли... Где бы еще найти лишнее время на все эти «хотелки»...).

ЭЭЭэээх. Меня тоже подкупил st в своё время. Особенно высказывание на счёт less и прокрутки. Один сурьёзный дядя задался поработать, всё у него было хорошо, но дико раздражало отсутствие прокрутки. И его волшебные слова: «А чё, после 2 недель использования st и less, привык (и стало ему удобно, да)». Плюс st поддерживает 24bit color. Ну и код его приятно читать. Что же по dwm - он был взят за основу группой сурьёзных парней и они родили, встречайте: XMonad. Вот этот конструктор мне по душе...

Ну а в emacs (jmacs в моём случае от дяди Джо) мне понравилось унификация с консолью кнопок заветных. Я пробовал на виме пожить, но всё время тянуло в режиме редактора перепрыгивать через слова...

Интересно, через сколько лет systemd его по номеру версии переплюнет?

joe - наверное самый адекватный из emacs-подобных. Хотя, лично мне лень патчить его для совместимости кнопок с mcedit, из всех «биндингов» меня устраивал (раньше) только вариант jstar (wordstar-compatible), но и то - не то.

исправлено множество ошибок.

Как же так? Где-то я читал, что там настолько мало кода и он так долго разрабатывается, что там не может быть ошибок.